Retool for Enterprises Part 1: The Basics

With an ever-expanding portfolio of prominent enterprise clients, Retool has firmly established itself as a powerful platform uniquely suited to meet the complex needs of large organizations looking to accelerate the development of their business software.

Nevertheless, it's remarkable how many large, technical Enterprises today use Retool for their internal tools yet still rely on guidance from dispersed Retool forum threads to manage their instances.

As a Retool-focused development agency, we talk to Enterprise teams each day who are unsure of how to create scalable application infrastructures in Retool. While Retool is an incredible tool that has enabled their teams to build fast and iterate even faster, engineering managers often find their teams losing control of a disorganized web of applications, with no real accountability for maintenance, nor consistent organization.  

Since we’ve worked with dozens of Enterprise companies to manage and improve their Retool app infrastructure, in this series of blog posts we hope to demystify some of the most Retool misunderstandings and paint a clearer picture of how to manage your instance properly, avoiding common anti-patterns we see in large-scale Retool deployments.

To start, we’re going to focus on the basics of Retool for Enterprises, including what solutions Retool provides for Enterprise companies, what pricing plan they might need (hint: it’s not always Enterprise), and whether or not cloud or self-hosting is more suitable for large infrastructures.

Let’s dive in.

How does Retool cater to the needs of enterprise businesses?

Contrary to some expectations, and unlike most no- or low-code tools, Retool is very well-suited to large-scale Enterprise use cases and even mission-critical tools.

Retool has long targeted the needs of large tech companies to ensure their product is suitable for larger-scale deployments with increased security needs. Some of these features include Okta support, SCM provider support, and audit trails.  

But, most importantly, Retool’s core philosophy is to provide a tool that expedites development time for developers, not to provide a low-code tool for business users, an essential consideration for Enterprise teams.

So what can Enterprise companies expect from using Retool?  

A space for engineers to interact with resources quickly and securely

For enterprises, Retool greatly reduces friction when creating and interacting with business resources and integrations.

Retool simplifies connecting to enterprise resources by configuring database and API connections with a single, secure authentication setup, which minimizes the need for manual connection management.

Thanks to Retool’s centralized configuration, developers can quickly access data across different sources without setting up application-specific authentication layers or repeatedly managing credentials across all of their internal tools.

Retool also provides an intuitive interface for managing detailed permissions, making it easy to access resources in a compliant and secure way. Managers can adjust permissions quickly and flexibly as needed across each Retool Space.

An opportunity to reduce SaaS seats and sprawl

A successful approach for many large enterprises using Retool is to leverage the platform to reduce the number of SaaS licenses required across their teams. By consolidating applications, companies can avoid paying for multiple seats on platforms that some employees rarely use directly. Instead of maintaining individual licenses for tools like Airtable, Salesforce, and Zendesk, enterprises can streamline access and control costs.

With Retool, teams can pull data from these external platforms via APIs and present it in custom-built applications tailored to specific job functions. This means that employees who don’t need to work directly within each tool can still access the necessary data to perform their tasks efficiently—all within Retool. This approach not only reduces expenses but also simplifies workflows, enabling better focus on essential operations.

A platform to expedite development speed and cut engineering costs

Instead of relying on traditional development methods, like a Django Admin portal or a custom internal application built with PHP, teams can use Retool to build such apps much faster and maintain them more easily. Retool offers an excellent way to modernize outdated legacy software with more agile, iterative solutions, while also consolidating your tech stack into a single, centralized, and highly manageable system. For enterprises, Retool also significantly lowers the cost of building temporary internal apps for short-term projects.

What’s more, Retool is packed with security features that meet most requirements of Enterprise deployments, including self-hosting, Git source control, custom SSO, testing options, and more.

Now we’ve covered some of the principal benefits of Retool for Enterprise companies, let’s take a closer look at the pricing plans and the considerations for Enterprises with potentially large deployments.

What Retool plan do I need? Business vs Enterprise plans

First things first, ignore the label: Enterprise companies aren’t obliged to pay for an Enterprise plan straight away. For larger companies with higher security concerns, it boils down to a couple of core features that determine whether you’ll need to be on either the Business or Enterprise plan. These features mostly revolve around security, Retool support level and data compliance requirements.

Regardless of your long-term needs, however, we typically suggest to our clients in an early adoption phase with Retool to start on the business plan. The business plan has all of Retool’s core features, and starting on a lower plan will give you a better understanding of how the platform is structured before committing to a larger investment. Retool will always be on hand to help upgrade you to Enterprise when the time comes, so there’s no real loss in gaining a base-level understanding of the platform and ensuring the best product fit before seeking out Enterprise pricing from their sales team.

It’s important to note here that the Business plan has all the in-app permission levels of the Enterprise plan, aside from environment permissioning. This means that even before you make the jump to the Enterprise plan, you can begin implementing these permissions from the offset whilst on the business plan. Starting with this basic structure will put you in the best place to implement more complex permissioning infrastructure if you move to the Enterprise tier (which can be overwhelming at first).

Even if you start using Retool on the business tier, it’s important to be aware of the Enterprise-only features that you may require in the future, to make sure you’re best prepared for an eventual upgrade if needed. Let’s take a closer look at the most commonly required Enterprise features.

Key features that push companies to the Retool Enterprise Plan

In our experience, here are the most common limitations of the business plan that typically force a company to seek out the Enterprise plan in Retool.

100 user limit on Self-Hosted - For on-prem deployments, Retool is limited to a maximum of 100 users on both the Teams and Business plans. If your company requires your deployment to be managed on-prem, you’ll need to consider if and when you’ll hit that 100 user limit. We’ll dig more into Cloud vs Self-hosted in the next section.

Custom SSO - If your company needs to integrate with Okta or any other SAML SSO provider, you will have to upgrade to a Retool Enterprise plan.

Source Control through your SCM Provider - Retool offers native versioning, which you can read more about here. But, you do have to be on Enterprise to manage your versioning through Github or your company's SCM provider.

Resource environment permissions - A common development pattern for high-security deployments is to give certain developers access only to a secure staging environment, thereby not exposing any PII or production data whilst they are developing. On the business plan, it’s possible to configure different resource environments, but you can’t manage permissions on an environment level.To do this kind of environment permissioning on the business plan, you would need a multi-instance deployment.

Retool Spaces - Retool recently released Retool Spaces as a way of segmenting your teams into separate instances, whilst still managing them through a single, overarching admin instance. It’s still possible to create a similar effect on other plans through proper permission management, but Spaces makes these full team separations straightforward and easier to manage.

Now that we’ve run through the essentials, what are some additional features on the Retool Enterprise plan that may be beneficial to companies?

Nice-to-have Enterprise Retool features

We wouldn’t really consider these features necessities that should dictate your upgrade to an Enterprise plan, but they can certainly be useful additions if you are already on the plan.

We call these features the ‘Nice-to-haves’:

Analytics & audit Logs - Retool has created a usage analytics page where admins can see app saves and views. This is useful for tracking adoption of apps across teams. Nevertheless, at this time we find this page to be quite limited. You can actually create your own analytics and audit log pages on-prem by querying the audit trail events table. We’ll be writing about this in another article in the series.

Access to a Retool Technical Account Manager (TAM)- With the Enterprise plan you typically get a shared Retool slack channel or portal to report bugs. While these features may be a nice-to-have, we find that most of these support channels aren’t worth upgrading to Enterprise for. A Retool TAM is often assigned to 20+ companies and is unlikely to have the capacity to actively manage your environment.

As self-hosted plans with 100+ users are the most common feature that pushes Enterprises into the Enterprise plan, let’s dive a little deeper into the pros and cons of each.

Full Retool API Access- Retool API is a way to programmatically manage different parts of your Retool environment. It’s technically in Beta as of November 2024, but several of our enterprise clients have been using it for the past six months. Through the API, the individual responsible for the deployment can manage themes, source control, spaces, as well as user permissions through an API endpoint. This can be extremely useful for having full operational control over your environment. But we’ve noted that since you can still interact with all of these environment level features without API access, this is more of a nice-to-have.

Cloud vs Self Hosted Deployment of Retool: Migration challenges

Enterprises typically know from the outset whether they’ll need to host their Retool deployment on the cloud or on-prem. The real question is often whether they need to start with on prem immediately, and making the right choice here is crucial.

If at any point, Retool is likely to become a large deployment and a high level of security is essential to you, we would highly suggest starting with the self-hosted version of Retool from the beginning. Starting with Retool already On-prem (even before upgrading to Enterprise) prevents you from facing a long and complicated migration period from Cloud to Self-hosted when the time does come.

We ourselves have helped Enterprises manage large-scale migrations from Retool Cloud to Self-hosted deployments, and these projects often transpire into months of complication.   Starting with self-hosted Retool from the offset is a great way to reduce complexities and tech-debt if you are certain that you will need it in the future.

Retool provides set-up documentation for deploying within your VPC or whatever format that abides to your company’s standard. If you start with this from the offset, it will save you the struggle of matching versioning, recreating permission sets, and migrating between the instances.

As of 2024, Retool introduced Retool ‘Stable Releases’ to self-hosted. Stable releases are quarterly releases that trail behind their cloud deployments by a couple of versions and promote application stability since they have been more thoroughly tested on the cloud’s most recent release. For mission-critical workloads, having a stable release on self-hosted provides more peace of mind that a new release won’t break your application, and for such usecases we would suggest an on-prem deployment. On Cloud versions of Retool you don’t have the choice to upgrade your environment as this is done automatically, which can cause problems if bugs occur.

So there were some of the basics of Retool for Enterprise. In the rest of the series we’ll be discussing topics like:

• Advanced, scalable permissions
• Resource handling
• Complex deployment handling
• Source control
• Multipage apps
• Environment variables
  

And more. Keep an eye on our blog for more info or sign up to our newsletter to be the first to know.