When you need a staging environment — and when preview is enough

A staging you cannot explain costs weeks you call 'quality assurance'. People merge because 'it sat on staging', and discover in production that the webhook still pointed at the old URL, that the Stripe key was test, or that the content was three months old. You think you have a gate. You have a ritual. The ritual is expensive because it gives you permission not to look.

Teams inherit staging from another kind of software. In a bank, an ERP, a monolith with one deploy window a month, a long environment before production is survival. On a Next.js site with preview on every pull request it is often theatre: you pay to keep a third site alive that no editor opens and no developer trusts. Preview solved the visual job. Staging has to solve something preview cannot.

It is also a trust and data question. If staging has production data, you have another production you do not guard. If staging is empty, you only fail the queries that die with real rows — in production. If nobody owns refreshing it, it diverges — and then the green 'it worked on staging' is a lie you write in a ticket.

We write this because 'we need staging' has become a purchase you make before you have a sentence about what preview cannot do. An honest setup is boring: preview on every branch, production as the truth, and a third environment only when you can point at the integration, the data shape or the editor who cannot live in a PR URL. Without that sentence you have an extra hostname. You do not have staging.

A staging environment is a long-lived, shared place that should answer like production in the ways you are actually afraid of. The same kind of database shape. The same kind of auth. The same webhooks, pointing at this URL. The same payment sandbox. Content editors can click through without touching live. It does not have to be a bit-for-bit copy. It has to be a copy of the truths that can break you.

It is not a preview. A preview dies with the pull request. It has the branch's code, often the branch's migrations, and typically not your real Stripe webhook or your ERP. It is for seeing and clicking before you merge. It is the right tool for 'does this look right' and 'does it build'. It is the wrong tool for 'can the payment provider find its way back' and 'can the editor practise without publishing live'.

It is also not production with `noindex` and another hostname. Mirroring live with real customers and real secrets, then calling it staging, is how you get a leak and a second prod you forget to patch. Staging may resemble. It must not be the same valuable thing. An anonymised slice, sandbox keys, a dataset you can afford to lose.

And it is not docker-compose on one laptop. Local is for developing. Staging is for sharing a truth with someone who does not have your laptop: another developer, an editor, a payment vendor, a migration window. If only one person can start it, it is not an environment. It is a hope.

The first failure is that staging is stale. The last real deploy was in the spring. The schema does not match prod. Feature flags point elsewhere. You are 'testing' a different product. The only thing staging then catches is that you can log in to a site you will not launch. Refresh it on a rhythm, or drop it. A museum is not a gate.

The second failure is that staging has production keys. The database is yesterday's dump. S3 is the real bucket. Mail sends to real customers if someone clicks. That is not thoroughness. That is another prod without the guard you have on the real one. Sandbox and anonymisation are boring. They are the reason staging is allowed to exist.

The third failure is an empty staging. No rows, no webhook, no editor account, no 'real' integration — just the same Next.js build pointed at an empty Postgres. Then you catch the bugs an empty site can show, and miss the ones that only die with data. If the job is the data shape, give it data. If the job is layout, use preview.

The fourth failure is using staging as a dump. Everything unreviewed lives there. No preview. No pull request. 'It is on staging' means 'someone pushed to a branch we share'. Then you have turned review off and a hotel on. Preview deploys are what keep review alive. Staging is what keeps the shared truth. Mix them and you get neither.

A marketing site on Next.js with preview on every pull request typically has two truths: the branch you look at, and production. Editors, if you have them, publish in prod or through a CMS with its own preview. A third environment here is often a place you forget to set environment variables, and then 'it works on staging' means 'it worked without the secrets prod has'. Don't. Use preview. Keep prod boring.

A WordPress site is a different kind. The content is the database. A preview of a theme repo is not the same as 'the editor can press a front page without hitting live'. Here a staging — a copy of the CMS with sandbox keys and a noindex — can be right if you actually rehearse content and plugin updates there. That is still not an excuse to copy real users or to let staging be where you discover the plugin sent the mail.

An app with Stripe, webhooks or an ERP often has the job preview cannot do: the vendor can only point one place, and you need to complete a purchase or a sync without touching live. Then staging is right. Then sandbox keys are the duty. Then 'we pushed to staging and forgot to update the webhook' is the failure you should design out of — one documented URL, one owner, one checklist before you call it tested.

A migration — WordPress to Next.js, a schema change, a cutover — is the week staging earns its keep. Dry-run on something that resembles. Point DNS temporarily if you must. Write what has to be true before you switch. Preview of the new site is still useful. It does not replace having run the boring copy once before customers do.