Staging
Test a change on a fresh copy of your production data before you deploy it
A staging is a copy of your app that runs for 24 hours on a fresh copy of your production data. The copy is taken the moment you create it. The staging runs the latest commit of a branch (the app's main branch unless you pick another) with production's environment variables and settings.
Use it to try a change on real data, with flows that run all the way through, before you deploy to production.
How it differs from a preview
A preview is for showing work to people. It runs on whichever data branch it's routed to, which on a new app is production's own data. See Environments. Previews also refuse to send, so a flow that sends an email stops at that email.
A staging takes a new copy of production every time, and it lets flows finish. The email step "succeeds", the next step runs, and you read the email afterwards instead of anyone receiving it.
What is captured
Nothing on a staging reaches a real person or real money. These are captured instead of sent, and your app gets a normal success response:
- Email and invitation emails
- LINE, Facebook and Instagram messages
- Slack messages
- SMS, including sign-in claim codes
- Google Calendar invites
- Google Sheets writes
- Assistant replies
Open the staging's Captured messages panel to read them. Agents can read them too.
What still happens
- Payments always use the payment playground, with test cards, whatever your playground settings say.
- Printing and cash drawers only go to the virtual printer. If the app has none, printing fails on the staging. Turn on the virtual printer in the app's Edge settings. See Set up printers and cash drawers.
- Your own code calling a third party directly. If the app calls a service with its own API key and not through Stardeck, that call is real. A staging has production's keys, so it can charge, send or delete there.
- Calls to other Stardeck apps (cross-app) are refused on a staging.
- Customers and sign-ups. Identities created on a staging go into your real customer directory, marked as created by that staging. See Identities.
- Files. A staging can read your production files and upload its own. It can't change or delete files production uploaded.
- Schedules run on a staging until it expires. What they send is captured.
- Settings shared with the live app can't be changed from a staging. That covers team members and invite links, sheet syncs, support tickets, the inbox, people's Google connections, row policies and file stores. Change them from production or the dashboard.
Who can open it
Only your team. The staging URL is always internal, whatever the app's visibility is.
Your coding agent can open a staging in its own browser tool, as you or as a role, through your Stardeck connection. It picks the app's only staging unless told otherwise, and never falls back to production. What it does there follows the list above: sends are captured and payments use the playground, but your code's direct calls to a third party are real.
Create a staging
Ask your coding agent. Claude Code, Cursor and other MCP clients set up with stardeck setup use
the deploy_app tool with environment: "staging". See
Connect Your AI Tool. Starcat can create one from chat too.
From your terminal, run npx @stardeckai/cli deploy --env staging inside the app's clone. See
Deploy from Your Terminal.
In the dashboard, open the app and go to Settings → Deployments → Staging, then click Create staging.
Agents don't need your approval to create, read or delete a staging. The MCP tools for stagings
are list_app_stagings, delete_app_staging, list_app_staging_captured_sends and
get_app_staging_captured_send. When a redeploy of a staging fails, list_app_stagings gives the
newest build (latestRevisionId) and the one still serving (activeRevisionId). Read the build
with get_project_deployment_logs, and the running staging's logs with get_worker_logs; both
take environment: "staging" and the staging's stagingDeploymentId. A staging whose first build
fails is removed at once, because it holds a copy of production's data and has nothing running to
keep. The failed build's error, logs and summary stay readable with the deployment tools and the
deploymentId the deploy returned, with every secret the build printed already removed; nothing
else of that staging is kept. Build output recorded before secrets were removed as it was stored
is not shown. The log of a build that is still running is stored when it ends, not before; a build
that prints more than about 2 MB keeps only its newest output.
The Staging tab
Each staging shows its URL, the commit it runs, when the data was copied, a countdown to expiry, its captured messages and a Delete button.
Schema changes
If the commit changes the database schema, the changes are applied to the data copy first. A staging is therefore a rehearsal of the production migration. If the changes fail on real data, the staging deploy fails, and you find out before production does.
Limits
- 3 stagings at a time per app.
- Free.
- 24 hours. You can't extend one.
When the 24 hours are up, the staging stops counting as active. It is removed at the next 03:00 Bangkok time (20:00 UTC), together with its data copy and captured messages. Until then the tab shows Expired · removed at 03:00. Read anything you need from the captured messages before that.
To remove a staging earlier, click Delete on the Staging tab.
After testing
Staging doesn't promote a tested build to production yet. When you're happy with it, deploy to production as usual. See Publishing & Deployment.