How to Manage Multiple Environments in Retool

Go to Settings (top-right user menu) → Environments. By default, Retool provides a 'Production' environment. Click 'Add Environment' to create a staging environment. Give it a name like 'Staging' or 'Development'. You can create multiple environments (e.g., Dev, QA, Staging, Production). The order of environments in the list matters — the topmost is the default for new apps. Drag environments to reorder them. Mark one as the 'Default' environment (usually Production for safety).

The key benefit of environments is per-environment resource configuration. Go to Settings → Resources → select a resource (e.g., your PostgreSQL database) → Edit. In the resource editor, you'll see credential fields. Look for an Environment selector at the top — switch between environments to set different credentials for each. For your staging database, enter staging credentials. Switch to Production and enter production credentials. Save each environment's configuration separately.

1// Concept illustration (not code — done in UI):
2// Resource: PostgreSQL - Main DB
3// 
4// Staging environment:
5//   Host: staging-db.yourcompany.com
6//   Database: app_staging
7//   Username: retool_staging
8//   Password: [staging password]
9//
10// Production environment:
11//   Host: prod-db.yourcompany.com  
12//   Database: app_production
13//   Username: retool_prod
14//   Password: [production password]
15//
16// Same resource name, completely different connections.
17// Queries in the app use the same resource name; Retool routes
18// to the right backend based on the active environment.

In the Retool editor toolbar, look for the Environment selector — it's typically a dropdown showing the current environment name (e.g., 'Staging' or 'Production'). Click it to switch between environments. When you switch to Staging, all queries in the app execute against staging resources. Run your queries in Preview mode to verify they return staging data. Switch to Production to test against production resources (be careful — queries that write data will affect real production). The environment selector state is per-editor-session, not saved with the app. Users who open the app URL always run in the environment that matches their organization's default (usually Production).

Read the current environment name in any `{{ }}` expression or JS query using `retoolContext.environment`. This returns the environment name string (e.g., 'staging', 'production', or whatever you named your environment). Common uses: showing an environment banner, disabling destructive actions in production without testing, and conditional query logic.

1// Show environment banner when NOT in production:
2// Text component content:
3{{ retoolContext.environment !== 'production' 
4   ? '⚠️ ' + retoolContext.environment.toUpperCase() + ' ENVIRONMENT — Not production data'
5   : '' }}
6
7// Text component Hidden property (hide banner in production):
8{{ retoolContext.environment === 'production' }}
9
10// Disable a destructive button in production:
11// Button Disabled property:
12{{ retoolContext.environment === 'production' }}
13
14// JS Query: behave differently by environment:
15const isProd = retoolContext.environment === 'production';
16const limit = isProd ? 1000 : 50;
17
18return await fetchOrders.trigger({
19  additionalScope: { limit }
20});

For settings that differ between environments (API base URLs, feature flags, rate limits), use Configuration Variables (configVars) with per-environment values. This is separate from resource credentials — configVars handle non-connection configuration. Go to Settings → Configuration Variables → Create Variable. Assign different values to the Staging and Production environments for the same variable name. The app accesses them via `{{ retoolContext.configVars.VARIABLE_NAME }}` and automatically gets the environment-appropriate value.

1// Config var: API_BASE_URL
2// Staging:    https://api.staging.yourcompany.com
3// Production: https://api.yourcompany.com
4
5// Config var: MAX_BATCH_SIZE  
6// Staging:    10
7// Production: 500
8
9// In app queries:
10const apiBase = retoolContext.configVars.API_BASE_URL;
11const batchSize = parseInt(retoolContext.configVars.MAX_BATCH_SIZE) || 100;
12
13console.log(`Running in ${retoolContext.environment}: ${apiBase}`);
14
15// SQL with environment-aware limit:
16SELECT * FROM orders 
17WHERE status = 'pending'
18LIMIT {{ parseInt(retoolContext.configVars.MAX_BATCH_SIZE) || 100 }}

The best practice workflow for environment management: 1. Build and test the app in the editor with Staging environment selected 2. Preview the app (Preview button) in Staging — verify queries work, data loads, UI functions correctly 3. Switch the editor to Production environment — do a read-only review (don't submit forms or trigger writes) 4. Create a release (Manage Releases → Create Release) — releases are environment-agnostic 5. Have a colleague test the production app URL (not the editor) before announcing the update 6. If issues found: fix in editor in staging, re-verify, publish a new release This workflow catches environment-specific bugs before real users encounter them.