Retool is a fast way for engineers to build internal tools. Here’s a 4 minute video demo. We started building the product in 2017, and in about a year got to $1M ARR with 4 people at the company. Today, many customers rely on us to build internal applications, including Amazon, Peloton, Progressive, and NBC.

Since starting Retool, we've always found it challenging to explain how exactly the product works without showing it directly. For example, we could tell an engineer that Retool is a "drag and drop way to build internal front-ends". But engineers have a very negative impression of most drag-and-drop tools! (Not flexible enough, never customizable enough, or tries too hard to be smart, and of course fails.)

Today, the best way of explaining Retool is to first show users the demo video, and then get them to build whatever they wanted, in Retool, in just a few minutes. Nothing quite compares to the magic of being able to drag and drop together a UI on top of a database or API within minutes of getting started. That's the best way we know to get a user to become a paying customer.

But in order to build a useful app for themselves, users typically have to connect their own database. For Retool to access your Postgres database hosted on RDS, for example, users have to add our IP addresses to their allowlist.

For most companies, getting an IP address added to the allowlist in RDS takes time. And it should! These companies store sensitive data in their databases, and they should minimize their security surface area by very rarely (if ever) adding external IP addresses to their allowlist. After all, many companies have lost sensitive user data due to having too broad of an allowlist.


A good amount of potential customers never onboard because they can't connect their data. When we started Retool, we only had a cloud version (which required adding our IP address to users' allowlist). But when we began telling people about Retool, it became clear that a large percentage of potentially interested customers weren't able to use us because they wouldn't be able to get access to the data they needed.

This was especially true for larger companies and companies in regulated industries (such as fintech or healthcare). We were losing them midway through in the funnel, simply because they weren't able to actually try the product in the first place.

We considered a few separate solutions, including allowing users to import data, anonymizing their uploaded data, generating fake data, etc. But when we tested them with customers, it was clear that none of these solutions would've worked. Because a core value prop of Retool was writing back to databases, writing back to fake data just wasn't compelling enough. We had to find a way to allow users to go build applications on their actual data.


That's when we started considering how hard it would be to host Retool on-prem. Allowing customers to host Retool on-prem could guarantee that no data ever left their VPC, and would enable customers to secure their own servers however they wanted (such as putting it behind a VPN, or behind SSO).

But at this point, Retool was two people, and we ourselves deployed Retool via a script that scp'd our frontend build up to a directory served by nginx, and restarted PM2 for our backend. We were quite far off from allowing users to host Retool on their own infrastructure.

We settled on using Docker images as the distribution method for on-prem Retool, given it was so widely adopted. To minimize dependencies, we decided to replace our Nginx with a separate node process that served static assets, and we replaced PM2 with our own implementation of clustering worker processes. To make it easy to deploy Retool, we created a repo with docker-compose.yml to preconfigure the Postgres database that Retool used for storage. We also built a simple licensing endpoint to let on-prem instances check-in with and a Retool app to make it easy to manage license keys. Three days later, Retool was running off a Docker image on an EC2 instance.

We reached out to a few of the customers who had initially shown interest, but were unable to use Retool because they couldn't connect their data.

One of these customers then ended up deploying Retool the same day, connected their data, and ended up building dozens of applications that have had a large impact on their business. Today, they've built hundreds of applications in Retool, are shipping business apps much faster than before, and have saved tens of millions of dollars in engineering time.


In retrospect, building on-prem Retool was critical. Yes, it unlocked specific customers and specific industries. But it also allowed us to confidently answer business continuity concerns and better engage with our customers' security teams.

When we were a smaller company (with no customers and no revenue), our customers would often ask,“what happens if you go out of business?

With cloud-hosted software, there's no right answer. We've had our share of vendors go out of business. But with our self-hosted offering, we could now promise customers that Retool (and the applications they had built) would continue working, regardless of what happened to the company.

Similarly, when we were talking to customers, they'd often ask us to fill out security questionnaires, which were invariably onerous. This slowed down our iteration speed, since it took time to answer security reviews, which delayed us from discovering if a particular customer was or wasn't a good fit. These security reviews were often large Excel spreadsheets filled with hundreds of questions:

https://miro.medium.com/max/1414/1*oMGBenzCqJ7YHeBSoxOxig.png

With self-hosted Retool, most of these concerns and questions no longer applied. We told our customers to block all inbound and network connections from their box, which ensured that no data ever made it out of their VPC—meaning we didn't store any data, worry about retention policies, or deal with storing passwords.

This approach shaved off substantial back-and-forth with security teams, and cut down our average security review timeline from 30 days to 5 days. (In fact, one of our customers—a $100B+ financial services company—recently told us that Retool passed through their security review in a few days, "faster than anything I'd ever seen before".)


Investing in on-premise Retool may sound counterintuitive at first glance.

Over the past few years, all we've heard about is the "cloud", how quickly it's growing, and how it's going to take over all on-prem software. But the meaning of "on-prem" is also evolving! It no longer involves buying a box and plugging it in. Instead, it involves downloading a Docker image, and running it in your own EC2 instance. Yes, it's in the cloud. But it's in your own cloud, not in your vendor's cloud. And that gives you better control over where your data is going, over what datasources it can connect to, as well as the software's uptime.

Surprisingly, many “cloud” companies make most of their revenue from self-hosted deployments. For example, the pioneers of “the cloud” – ServiceNow, MongoDB, UiPath, and others – all make billions of dollars of ARR from self-hosted software. Even Elastic makes more than 70% of their revenue from “on-premise” customers.

https://paper-attachments.dropbox.com/s_7ADDB304B3C8B787266D6D552345E2F5C07CC403EA4AC8585D6871DB682D1D50_1622568356405_Screen+Shot+2021-06-01+at+1.25.52+PM.png

We oftentimes associate on-premise software with larger, enterprise companies, but that’s often not the case. For example, since we made our self-hosted offering available self-serve, we've seen companies self-host for a variety of reasons, including for performance (given you can now locate Retool in the same region as your database), security, or just business continuity.

Should more forms of software be self-hostable? We think, potentially, yes. As deployment tooling gets better, it's possible that many forms of SaaS software will have self-hostable versions, especially those that interact with sensitive data, or require special permissions.

For example, it might not make sense to self-host Salesforce, since it doesn't access sensitive data. But maybe it would make sense to self-host GSuite, since there's critical data, and potentially it could be connecting to internal databases and APIs. If self-hosting software became as easy as signing up for a cloud account, I think there are clear advantages to self-hosting certain classes of software.

That said, there are downsides to supporting on-prem:

  1. It can create divergent products and code bases as companies struggle to make features available on both on-prem and cloud. We can use the special on-prem images that we build to actually run our cloud multi-tenant solution (100% code reuse across on-prem and cloud).
  2. Complex deployments can make it difficult to debug customer issues. Logs are the common denominator for debugging; because of this we emit CPU / memory usage info, have JSON formatted logs to make it easy to parse by other systems, and emit performance metrics.
  3. Sometimes on-prem will have more features than our cloud offering because the threat model for on-prem is simpler (single tenant vs multi-tenant on cloud).
  4. We can't force customers to upgrade, which leads to many versions of Retool being in use at any given amount in time. This increases the cost of providing support to customers.

These are challenges we've surmounted in various ways. If there's interest, we'd be happy to write a blog post about this later.


Today, we’re excited to announce the public beta of a self-hosted deployment option for our Free and Startup plans. That means that more customers than ever before can deploy Retool on your own infrastructure, behind your own VPN, and in your own VPC.

With our new self-hosted plan options, developers who prefer or need a private deployment option can instantly deploy Retool on their own infrastructure and start building apps.