Skip to main content

Multi-instance deployment

Learn about deploying Self-hosted Retool to multiple instances.

If running one instance of Self-hosted Retool with multiple environments doesn't meet your requirements, you can run multiple instances of Retool each with its own database. Multiple instances are sometimes used to meet certain security, compliance, and networking requirements.

Diagram of multi-instance deployment

Each separate instance of Retool can be treated as an “environment” in the typical programming context. Developers typically build in development and staging, and end-users often access apps only in production. It is also possible to spin up more instances to represent Quality Assurance (QA) or User Acceptance Testing (UAT) environments.

There is no limit to the number of separately deployed instances of Retool you can spin up in your organization with a single license key. Users are also de-duplicated in your organization by email address, so additional instances do not affect your user count.

When to use a single Retool instance​

In general, you should only deploy the instances you need. If you’re starting out with a small, defined set of use cases for one team, or if you don’t need to isolate Retool instances by VPC, you can start with a single instance.

Retool allows you to define multiple environments within a single instance so that you can safely build, run, and test apps for your end-users.

When to deploy multiple instances​

You might have development endpoints where editors can safely build and test apps on non-production data. If so, it's recommended to mirror a typical Software Development Life Cycle (SDLC):

  • Deploy a development instance of Retool in the development VPC.
  • Deploy a production instance of Retool in the production VPC.

This ensures your development Retool instance can only point to development endpoints and helps organize different user types across your organization.

Our Source Control feature lets you safely promote application changes between instances via a Git-based workflow. You can only have one Git repository associated with an instance—all pull requests must go through a single group of reviewers.

Isolate team development workflows​

Retool recommends you split out instances for each team if:

  • You operate under a full-stack or Spotify model and have many autonomous teams building tooling on their own.
  • You don't have shared resources or endpoints across teams, but teams want to manage their own development workflows independently.

If you are launching or operate into a market that requires network traffic to be isolated to specific regions, you may need to isolate your Retool instance as well. In other cases, a production instance might need to be locked down to be read-only (i.e., no editors can build apps).

Testing new features and upgrades​

If you want to safely test out a new beta feature or instance-wide setting (e.g., a new SSO configuration), you can spin up a separate Retool instance for this purpose. See upgrade deployments for more information.