Guides / Prompting and shipping

How to Set Up a Staging Environment for Your App

Set up a staging environment: a second copy of your app with its own database, test keys and URL, where you check changes before real users see them.

Mythex Team · 2026-09-29 · 6 min read

To set up a staging environment, deploy a second copy of your app to its own private URL, give it its own database and test API keys, and make it match production's setup as closely as possible. Then release every significant change to staging first, run through the important flows, and only publish to production when staging looks right.

If you're new to the idea, what a staging environment is explains the concept. This guide is the practical setup, written for people building with AI tools rather than running a DevOps team.

Dev, staging and production

Most small apps need three places, even if the first one is just your builder's preview:

The point of staging is that it behaves like production — same code, same stack, same kind of settings — but a mistake there hurts nobody.

Step 1: Decide what staging must match

Staging is only useful if problems show up there before they show up in production. Match:

• The same code, released the same way.
• The same stack and versions — framework, runtime, database type.
• The same kind of configuration — the same environment variable names, with test values.
• The same services — if production has a web app and an API, staging has both.

It can differ in size (a smaller machine is fine) and in data.

Step 2: Create the copy

The simplest approach: a second deployment of the same project, at a different URL such as staging.yourapp.com or yourapp-staging.example.com.

How you do that depends on your host:

• Hosts with built-in preview or staging deployments can create one automatically for a Git branch.
• Hosts without it: create a second app or project from the same code, and deploy it separately.
• Code in Git: keep a staging or main branch that deploys to staging, and deploy to production from a release. See how to use Git with an AI-built app.

Step 3: Give staging its own database

This is the step that protects you. If staging and production share a database, a test that deletes records deletes real records.

• Create a separate database for staging.
• Fill it with seed data — realistic fake records the AI can generate for you.
• If you need a copy of production data, remove or scramble names, emails and anything personal first.

Write a seed script that fills an empty database with realistic test data: 20 customers, 50 orders in different states, and two admin users. Use obviously fake names and example.com email addresses.

Before you trust the setup, confirm which database each copy connects to. Ask directly:

Which database does this app connect to, and where does that setting come from? Show me the variable name, not the password.

Step 4: Use test keys and separate settings

Everything that talks to an outside service should use test credentials in staging:

• Payments in test mode (Stripe test keys, for example), so no real card is charged.
• Email sent to a sandbox or only to your own address, so customers never get a test message.
• AI and other paid APIs with a separate key and a low spending cap.
• Webhooks pointed at the staging URL, not production.

Keep the variable names the same in both environments and only change the values. That way the code doesn't need to know where it's running. For more on this, see how to keep API keys safe.

Step 5: Keep staging private

Staging shouldn't be public:

• Put it behind a login, a password, or an allow-list of team emails.
• Stop search engines indexing it with a noindex meta tag or X-Robots-Tag header.
• Don't link to it from your public site.
• Make it look different — a coloured "STAGING" banner prevents testing in the wrong tab.

Add a bright yellow banner at the top of every page that says "STAGING — test data only" when the APP_ENV environment variable is "staging". Also add a noindex meta tag in that case.

Step 6: Make a release routine

Staging only helps if you use it every time. A simple routine:

1. Make the change in development and check it in the preview.
2. Release it to staging.
3. Run through your key flows: sign up, log in, the main feature, payments, anything the change touched.
4. If something breaks, fix it and release to staging again.
5. Publish the same version to production.
6. Check production quickly — the same flows, briefly.

Write the key flows down as a short test script. See how to test your app before launch for what to include.

Step 7: Handle database changes carefully

Changes to the database structure — adding a column, renaming a table — are where staging earns its keep.

• Run every structural change on staging first.
• Check existing data survived, not just that new features work.
• Take a backup of production before running the same change there. See how to back up your app database.
• Prefer changes that add rather than rename or delete, so the old version still works if you roll back.

Example prompts

Explain what would happen to existing data if we ran this database change on production. Is anything deleted or renamed?

Make all environment-specific settings — API URLs, keys, email sender, the site's own URL — come from environment variables with the same names in staging and production. List them.

Write a short checklist of the flows I should test on staging before each release, based on what this app does.

Common mistakes

• Shared database. The most damaging mistake. Staging always gets its own.
• Live keys in staging. Real charges, real emails to real customers.
• Staging drifts from production. Different versions or settings mean staging stops catching problems.
• A public, indexed staging site that shows up in search results next to your real one.
• Skipping staging for "small" changes. Small changes break things too.
• Testing in the wrong tab. A visible banner fixes it.

Checklist

• Staging runs the same code, stack and services as production.
• Staging has its own database with test or scrubbed data.
• Payments, email and paid APIs use test keys in staging.
• Variable names match across environments; only values differ.
• Staging is behind a login or password and not indexed.
• A banner shows when you're on staging.
• Every release goes to staging first, with a written list of flows to check.
• Database changes run on staging first, with a production backup before release.

Staging on Mythex

Mythex's Publish gives you one live URL per app; there's no separate staging toggle. In practice you have two options:

• Preview as your pre-release check. Every project runs in a private cloud workspace with a live Preview. /test has the agent click through it like a user, and a Share link lets a client or teammate review the preview without publishing. See Preview and Code. This is enough for many solo projects.
• A second project as staging. On Pro, export the project and import it into a new project, give that project its own database and test-key secrets, and publish it at its own slug. Release to it before you publish the production project.

Either way, ask the agent which database the preview and the published app use before testing anything destructive, and use checkpoints to roll back a bad change. For taking an app live more broadly, see how to take an AI prototype to production.