Somewhere to be wrong first.
"Staging environment" is a line on the rate card at $12/mo, and Static Pro's spec sheet lists staging as one of its bullets. Neither says what it actually is. This page does: the address, who can reach it, what's in it, how a change gets out of it, and how you go back if it's wrong.
Three environments, not one
Production is what a visitor gets. The other two exist so nothing new reaches it untested.
Production
- What it is
- The live version. What a visitor gets when they type your domain in.
- Who can reach it
- The public, and any search engine that goes looking.
- What's in it
- Real data — whatever your app or site actually holds today.
- What it's for
- Serving traffic. Nothing runs here that hasn't already been reviewed and merged.
Staging
- What it is
- A second, standing copy of the same stack, built from the same infrastructure definition as production.
- Who can reach it
- You and whoever you invite — not the public, not a search engine.
- What's in it
- Depends on the tier — see the data section below. Not a full copy of production unless a check genuinely needs one.
- What it's for
- Checking a change before it ships: click through it, confirm it, then promote it.
Migration standing copy
- What it is
- A temporary rehearsal environment stood up only while a move is underway.
- Who can reach it
- You, during the migration — torn down once the cutover is confirmed and live.
- What's in it
- A copy of whatever is being moved in, provisioned ahead of the actual switch.
- What it's for
- Rehearsing the cutover itself, not ongoing iteration — see the move in full on Migrations.
A staging environment, specified
Not a vague "test copy somewhere" — a real address, with the same guarantees production gets.
Its own address
A subdomain pointed at the platform the same way any other subdomain is — the CNAME case is already on the Domains record sheet.
Private by default
Not linked from anywhere on your live site, not submitted to a search engine, and left out of the sitemap. Reaching it is a matter of knowing the address and being allowed in — access is controlled, not just unlisted.
Its own certificate
Issued and renewed on the same schedule as production's — see the certificate lifecycle on Domains for how that renewal actually works.
The same infrastructure definition as production
Not a lookalike built by hand and left to drift — the same code that defines production, deployed a second time. What you click through here is what goes live.
What data staging holds
The question a "staging environment" line item never answers on its own.
| Tier | Holds | Detail |
|---|---|---|
| Static | Nothing to speak of | A static site or SPA has no database — staging is just the same build, deployed a second time. |
| Dedicated with a database | A recent backup, or seeded data | Pulled in on request from a recent backup, or seeded with placeholder data if a real copy isn't needed for the check being done. |
| A full copy of production data | Real customer data, and treated as such | If a check genuinely needs the real thing, that copy is still real customer data the moment it lands in staging — same handling, same privacy commitment as production. See Privacy for what that means in practice. |
See Privacy for how a real copy of production data is handled once it's somewhere new.
Briefed change to production, in six steps
A pull request is reviewable if you read code. A URL is reviewable either way — this is the step The Loop doesn't spell out on its own.
- 1
Brief the change You
Describe it in plain language, the same way as any other change under the Agentic iteration — CodeHerder add-on.
- 2
Agent opens the pull request CodeHerder
Reads the live codebase and makes the change on its own branch — a real diff, not a description of one.
- 3
CI builds it CustomHosted
The same build and checks that gate every other change on this platform run against this one too.
- 4
It stands on staging CustomHosted
The branch deploys to the standing staging environment automatically — a real URL, not a diff on a screen.
- 5
You click the real thing You
No diff-reading required — load the page, use the feature, decide if it's right.
- 6
Merge ships production You
Approving the pull request merges it, and the same pipeline that just built staging redeploys production.
Read how a change gets briefed in the first place on Brief a change, and why this ships through one pipeline rather than two on The Loop.
If it's wrong
Two of these are ordinary. The third is a different procedure, on purpose.
Revert the merge
The same pipeline that shipped the change redeploys the last known-good version. No data touched, because none was.
Promote the previous deploy
On static hosting, the last deploy is always one click away — a straight promotion, not a rebuild.
A data problem is a restore, not a rollback
If the thing that's wrong is data rather than code, that's the other procedure entirely — see Recovery for the backup and point-in-time paths, and where that boundary actually sits.
What it costs
Nothing here is typed in twice — every figure below is read straight off the rate card.
Static Pro
Included — multiple sites & environments · staging · redirects/headers.
Any other plan
Staging environment, +$12/mo — a second environment to test changes before they ship.
A dedicated app whose staging copy needs its own instance
A custom quote, sized the same way the main instance was.
The honest limits
Not buried in a footnote — the same discipline as every other honesty band on this site.
A copy can't reproduce real traffic
Load, concurrency, and the exact mix of requests production sees don't show up in a check run by one or two people clicking through.
Third-party integrations rarely behave the same way twice
A payment gateway or a customer-messaging tool usually needs its own sandbox mode, or isn't wired into staging at all — check per integration rather than assuming.
A copy goes stale
Seeded or backed-up data reflects the moment it was taken, not this morning. Re-pull it before trusting it for anything time-sensitive.
One standing environment per site, unless quoted otherwise
There's no unlimited fleet of per-branch preview URLs on dedicated compute by default — a second standing copy beyond the one is a custom quote, same as any other non-standard shape.
Outbound mail and messaging are pointed at a sink or disabled
The classic staging mistake is a test run that emails or texts real customers. Anything a staging copy would otherwise send outward is caught or turned off, not delivered. See Email for what a real sending path looks like once mail leaves this sink.
The uptime commitment covers the live service
The 99.9% monthly uptime target on the SLA is measured on production. Staging has no separate availability commitment.
Environment questions
The anxiety questions, verbatim — the ones a rate-card line item never answers on its own.
01Can Google find my staging site?
No. It carries no link from your live site, is left out of the sitemap, and isn't submitted to any search engine. Reaching it takes knowing the address and being allowed in.
02Can my client see it without a login?
Staging is private by default — access is controlled, not just unlisted. If a client needs to look at a change, invite them rather than treating the address as public.
03Does staging have real data in it?
Depends on the tier — a static site has none to speak of, a database tier gets a recent backup or seeded data on request, and a full copy of production data is treated exactly like production data, because that's what it is. See the data section above.
04How do I see a change before it goes live if I can't read code?
That's the point of the promotion path above: a briefed change comes back as a working URL on staging, not just a diff — click it, use it, then merge when you're happy.
05How do I undo a deploy, and how long does it take?
Revert the merge and the same pipeline redeploys the last known-good version — no data touched, because none was. See the rollback paths above for the static-deploy case and where a data problem is a different procedure entirely.
06Do I get one per site or one per client?
One standing staging environment per site by default. Running several client sites on one account gets each of them their own — that's the shape the Static Pro tier is built for.
07What does it cost?
Static Pro includes it. On any other plan it's staging environment, +$12/mo — a second environment to test changes before they ship. A dedicated app that needs its own separate instance for staging is a custom quote instead.
08Who'd be doing this if I ran it myself?
You would. The hours ledger prices "keeping the deploy pipeline working" at around 1 hour, as the stack changes — here, that row is included in every plan.
What environments connects to
- The Loop
"One pipeline, not two" and "no environment drift" — the claims this page expands.
- Brief a change
Where a change starts, before it ever reaches the staging URL this page describes.
- Static
The per-deploy preview and rollback this page's "promote the previous deploy" path relies on.
- Patching
The standing window that applies an update to a staging copy first, before it touches anything live.
- Recovery
Where the revert-vs-restore boundary this page quotes is actually backed, in full.
- Migrations
The migration standing copy in the inventory above, followed through the cutover it exists for.
- Glossary: Shipping & iteration
Plain-English definitions for every term on this page.
- Scaling
The compute and database ladder a staging copy shares with production, and what outgrowing a tier looks like.
Want to see a change before it merges?
Write in through the quote channel — we'll walk you through what stands up on staging and what it costs on your plan.