How to Set Up Dev, Staging, and Production in Retool

Why Editing Live Retool Apps Is a Risk You Can't Keep Taking

Most teams start the same way. One developer builds the first Retool app, shares it with the team, and everyone loves it. Then a second developer gets access and starts tweaking it. Then a third. Nobody talks to each other. A query gets changed. A button gets rewired. Something breaks in production and nobody knows what changed or when.

Consider what's actually at stake when you edit a live Retool app:

• In-progress edits are immediately visible to users. Retool doesn't autosave to a draft. When you're editing, users interacting with the app may see a partially-broken UI or fire queries against changed logic.
• There's no built-in rollback on the free tier. Without Source Control or Releases, if you break something you're hunting through Retool's limited version history hoping you can find the last working state.
• Test queries run against whatever resource the app is pointed at. If that's your production database, every click during development is a live mutation.
• Multiple developers editing simultaneously creates invisible conflicts. Retool doesn't have real-time collaborative locking. Two developers editing the same app will overwrite each other.

Understanding Retool's Environment Model

Retool's environment model is built around two mechanisms: Resource Environments and App Releases.

Resource Environments

Resources in Retool can have multiple environment configurations. Retool ships with three default environment slots: production, staging, and development. Each slot holds its own connection credentials. When a user opens a Retool app, the environment they're running in determines which version of each resource their queries hit. Same app, same query names, completely different backends.

App Releases

Retool's Releases feature lets you explicitly version and promote apps between environments. Instead of a single live app that anyone can edit at any time, you get a current draft (where development work happens), a staging release (a locked snapshot for testing), and a production release (the version your end users see). Releases are snapshots. Promoting to production pushes a specific, tested, named version. You can roll back to a previous release in a few clicks.

Source Control

On top of Releases, Retool offers Source Control integration with GitHub, GitLab, and Bitbucket. Source Control lets you commit app state to a Git repository, enabling code review workflows, pull requests before promotion, and a full audit trail outside of Retool's own history.

Configuring Resource Environments: Databases, APIs, and Secrets

Step 1: Create the Resource Once, Configure It Three Times

Navigate to Resources → New Resource and create your resource. After it's created, open it. You'll see an environment selector at the top — Production, Staging, and Development. Each one is independently configurable. For a Postgres or Supabase resource, this means three different connection strings pointing to three different databases.

Don't create three separate Retool resources named my_db_dev, my_db_staging, and my_db_prod. That's the wrong pattern. Use one resource, three environment configs.

Step 2: Scope Your API Keys and Credentials by Environment

For external APIs, create separate API keys per environment if the service supports it. Don't use your production API key in development. If a developer makes a bad call against a test key, the worst case is a failed test transaction. The same call against your live Stripe key means issuing refunds and writing incident reports.

Step 3: Use Retool's Secret Manager for Credentials

Retool's Secret Manager lets you store credentials centrally and reference them across resources without hardcoding values. Individual developers don't need to know the production database password. They access resources through Retool, Retool holds the secret, and permissions control what they can actually do.

Step 4: Configure Environment-Specific API Base URLs

Your queries should be environment-agnostic — GET /orders/{{orderId}} — not GET {{env === 'prod' ? 'https://api.prod.com' : 'https://api.staging.com'}}/orders/{{orderId}}. The latter is a maintenance nightmare. Use Retool's environment configurations to set base URLs explicitly.

Recommended Supabase and Postgres Setup Across Environments

Three Projects, Not Three Schemas

The most common mistake is using a single Supabase project with three schemas: dev, staging, and prod. Don't do this. Schemas within a single project share compute, share connection limits, share backups, and share billing. A runaway query in dev can degrade production.

The correct approach is three separate Supabase projects — one per environment. Each project has its own compute, its own connection pooler, its own API keys, and its own backup schedule. They're completely isolated. A developer can nuke the dev project and it doesn't touch staging or production.

Schema Management with Migrations

Use Supabase CLI migrations. Every schema change — new table, new column, new index, new RLS policy — gets written as a migration file. That migration gets applied to dev first, tested, then applied to staging, tested again, then applied to production as part of your promotion workflow. Never apply migrations directly to production from your local machine.

Data Seeding and Anonymization

Your staging database should have realistic data — realistic volume, realistic structure, realistic edge cases. But it should not have real user data. If you're copying production data to staging for testing, you need to anonymize it first. Fake names, scrambled emails, nulled phone numbers. Dev can run on minimal seed data — just enough to exercise your Retool app logic.

Row-Level Security Across Environments

Keep your migration files as the source of truth for RLS policies. If a policy needs to change, it changes in a migration file, it goes through dev and staging, and it lands in production the same way every other schema change does. No ad-hoc policy editing in the Supabase dashboard for production tables.

A Practical Release Flow from Dev to Production

The Flow at a Glance

Developers work in the Retool editor draft against the development resource environment. When a feature is ready, a staging release is created and the app is tested against the staging resource environment. After sign-off, the staging release is promoted to production, which flips end users to the new version running against the production resource environment.

Step 1: Lock Down Who Can Edit Production Apps

In Retool's permission settings, restrict edit access to apps. Only developers should be able to edit. Ops leads and stakeholders get viewer access. Nobody gets to click into an app and start changing queries in production.

Step 2: Set Default Environments for User Groups

Set your developer group to run in the development environment by default. Set your end users to run in production. This means developers testing their own work naturally hit the development database without having to think about it, and users are always on the production resource.

Step 3: Use Source Control for Change Reviews

If you're on a plan with Source Control, connect your Retool organization to a GitHub repository. When a developer finishes work on a Retool app, they commit the current state and open a pull request. A second developer reviews the diff. Retool's JSON diffs aren't the prettiest reading, but they make change reviews possible.

Step 4: Create a Staging Release and Run UAT

When development is complete and the code review is done, create a staging release in Retool. Go to the app, click Releases, and create a new release targeting the staging environment. Name it something meaningful — v1.4-order-status-column beats release-2024-03-15. Your tester opens the app in the staging environment, tests against staging data, and exercises every workflow the change touches. If something breaks, the developer fixes it in the draft and cuts a new staging release. You don't promote to production until staging passes.