Hello @appbuildernyc,
- Yes, with one critical condition: the
ENCRYPTION_KEY must match exactly between instances.
Before you connect a new instance to a restored database, ensure that the ENCRYPTION_KEY and USE_GCM_ENCRYPTION environment variables are set to the same value as in your existing Retool instance.
Self Hosted best practices docs here.
If these don't match, encrypted data (including credentials and user sessions) will be unreadable and logins will fail.
As long as those env vars are consistent, users should be able to log in normally on the second instance pointing to the restored DB.
- For Enterprise account users, you can use the same licensing the key as many instances simultaneously as you want.
For self-serve accounts, you cannot. What is recommended is to have Kubernetes nodes on your single instance that will serve as the fail safe backup in case of any outages with the primary nodes.
- Retool doesn't have native built-in failover support, but the architecture supports it if you externalize the database. The key insight from the docs is:
Retool recommends seeding a temporary instance with your current apps by copying your existing instance's PostgreSQL database. It's important to use a copy — don't connect directly to your existing Retool database, as upgrades often include database migrations which may alter it.
Update deployment docs here.
For a true hot standby, the cleanest architecture is:
- Externalize your Postgres to a managed provider (RDS, Cloud SQL, etc.) with read replicas or point-in-time recovery enabled
- Run a second Retool instance pointed at a restored copy of that DB
- Use a load balancer or DNS failover to cut traffic over when needed
The two instances should not share the same live database simultaneously in normal operation, as concurrent writes could cause conflicts.
- Back up your Retool PostgreSQL database. If your PostgreSQL database is managed outside of Retool and has point-in-time recovery enabled, you already have backups. Otherwise, you can enable point-in-time recovery, or take a snapshot of the database. Copy and store your
ENCRYPTION_KEY environment variable, along with any environment variables specific to your instance, in a safe place. Retool
Your backup checklist should always include: Postgres snapshot/dump, ENCRYPTION_KEY, USE_GCM_ENCRYPTION, and any other custom env vars.
Validating restore integrity:
After installation, Retool recommends manually testing the deployment to verify it was successful. Depending on how you're using Retool, you might want to verify your apps, queries, and workflows work as expected. Retool Building a written restore runbook with a checklist of critical apps and queries to validate is the recommended approach.
Workflows-specific warning — critical for your setup:
Ensure that the temporary instance is configured with these environment variables to prevent disruptions to Retool Workflows on the existing instance: set TEMPORAL_TASKQUEUE_WORKFLOW=sandbox-test on containers where SERVICE_TYPE includes MAIN_BACKEND, WORKFLOW_BACKEND, or WORKFLOW_TEMPORAL_WORKER. Failure to apply these environment variables may cause both the existing and temporary instances to be unable to run Workflows. Retool
This is the most commonly missed gotcha when spinning up a second instance — if you don't isolate the Temporal task queue, your standby instance can interfere with workflows running on production.
DNS/load balancer failover:
Retool doesn't prescribe a specific method here, but the standard approach is a low-TTL DNS record pointing to your primary instance, with a health check that flips to the standby IP automatically. Since Retool is stateless at the application layer (all state lives in Postgres), switching traffic is clean as long as the standby DB is current.
If you are looking to take advantage of all the great self-hosted deployment features that our self-hosted plan as to offer, let me know and I can put you in contact with our sales team, who can help assist you in achieving your deployment needs and goals 