How to Deploy a Retool App to Production

Before deploying, understand how Retool's release system works. The current app you see when editing is the draft version. Users who open the app URL always run the most recent published release — they never see your draft edits in progress. To see which version users are running: open the app → three-dot menu (top-right) → Manage Releases. You'll see a list of all published releases with timestamps and the currently active version marked. Any release can be made active with one click — this is your rollback mechanism.

Before publishing, verify these items in the app: 1. Test all queries in Preview mode — not just in the editor canvas 2. Confirm queries use the correct production resource (not a dev/staging database) 3. Check user permissions: Settings → Permissions → verify which groups can view/edit the app 4. Remove any test data, console.log() statements in JS queries, and debug-only components 5. Verify error handling: queries should have On Error handlers, not just silent failures 6. Check the app URL — ensure it doesn't expose query results in the URL via `{{ currentUrl }}` leakage 7. If using environment variables, confirm production values are set correctly

1// JS Query pre-release cleanup: remove console.log
2// BEFORE (dev/debug):
3console.log('Debug:', query1.data);
4const result = processData(query1.data);
5return result;
6
7// AFTER (production-ready):
8const result = processData(query1.data);
9return result;
10
11// Also ensure error handling is in place on queries:
12// Inspector → Interaction → On Failure → Show notification
13// 'Query failed: {{ error.message }}'

If your app has queries that connect to different databases depending on the environment, configure the environment before releasing. In the Retool editor, look for the Environment selector in the toolbar (it shows 'Staging' or 'Production' depending on your setup). Switch to Production and verify that all queries execute against the production resource. For apps using `{{ retoolContext.environment }}` in query logic, also confirm that production-specific behavior (stricter rate limits, real API keys, real payment processing) is tested.

1// Query logic that behaves differently by environment:
2// SQL query with environment-conditional behavior:
3-- This query runs in both environments
4-- Retool selects the resource based on the environment switcher
5SELECT * FROM orders WHERE status = 'pending'
6LIMIT {{ retoolContext.environment === 'production' ? 100 : 10 }}
7
8// JS Query environment check:
9if (retoolContext.environment === 'production') {
10  // Use real payment processor
11  return await processRealPayment.trigger();
12} else {
13  // Use test mode
14  return await processTestPayment.trigger();
15}

When the app is ready, publish it: 1. Open the three-dot menu (⋮) in the top-right of the editor, OR click the 'Deploy' button 2. Select 'Manage Releases' (or the release dialog opens directly) 3. Click 'Create Release' (or 'Publish' depending on your Retool version) 4. Enter a release note describing what changed (e.g., 'Add export to CSV button', 'Fix: pagination bug on orders table') 5. Optionally, specify a version tag 6. Click Publish The release is immediately active. Users opening the app URL will now run this version. Previous releases remain accessible in the Release Manager.

Who can access the app URL? Configure this in Settings → Permissions → App Access. By default, only Retool users in your organization can access the app. For apps accessed by external users (e.g., customer portal, partner tool), configure public access or restricted email domains. Key permission levels: - Use: can run the app, cannot edit - Edit: can modify the app (editor access) - Own: can delete the app and manage permissions Set the app's Access Level to All users (all org members) or specific Groups.

1// Conditional UI based on user permissions:
2// Show admin controls only to users in the 'Admin' group:
3// Button component → Hidden property:
4{{ !current_user.groups.includes('Admin') }}
5
6// Show user's own records only:
7// SQL query WHERE clause:
8WHERE created_by = {{ current_user.email }}
9
10// Check environment and permissions in one expression:
11{{ retoolContext.environment === 'production' && current_user.groups.includes('Admin') }}

If a deployed release causes issues (a query breaks, the UI is broken for certain users, a critical bug slipped through), roll back instantly: 1. Open the three-dot menu → Manage Releases 2. Find the last known-good release in the list 3. Click 'Activate' or 'Set as Current' 4. The previous release becomes active immediately — no cache clearing or deployment pipeline needed The broken release remains in the release history and is not deleted. You can investigate and fix the issue in the draft, then publish a new release when ready.

On Retool Enterprise plans, Protected Apps adds a required code review step before any release can be published to users. This is analogous to a pull request process for app changes. Enable Protected Apps: Settings → Permissions → Protected Apps toggle. Once enabled, editors submit releases for approval, and designated reviewers must approve before the release goes live. This is valuable for apps handling financial transactions, medical data, or sensitive operations.