Hey there!
About four years ago I published Do you really need a Staging environment? — the first article of mine to really go viral. Front page of Hacker News, more than 2,000 likes on Linkedin, and hundreds of comments across social media.
Many of such comments were just... angry! In fact, even if the title was framed as a question, I argued that, in most cases, staging environments did more harm than good. And many people didn’t like that.
Fast forward to today a lot of things have changed. Teams ship more code, faster, and more often. Does this make staging (and/or equivalent intermediate envs) more or less valuable? I see you saying “it depends” — so it depends on what?
So today I want to revisit the original thesis, figure out what still holds, vs what needs to change.
Here is what we will cover:
⬅️ What I argued in 2022 — a short callback to refresh our memory.
✅ What still holds — parity, batching, and when shared staging still pays off.
🤖 What AI changes — more throughput, worse env lies, safety net in prod.
🛡️ Guardrails for dev — guides, gates, and guards upstream of merge.
🚢 Ephemeral preview envs — review on isolated, prod-shaped envs.
🔬 Observability and controls — recover fast when something slips.
🎯 Final checklist — what “good” looks like now, without the sermon.
Let’s dive in!
Disclaimer: I am thankful to Upsun for partnering on this piece and for pushing me to revisit this topic properly in 2026. I am a fan of what they build around Git-native environments, and you should check them out.
However, as always I will only write my honest opinion on the practices and tools covered, Upsun included.
⬅️ What I argued in 2022 (briefly)
The original piece tried to get clear about when a shared staging / pre-prod environment helps, vs when it mostly adds cost and delay.
The two problems I saw (and still see) the most often are:
Staging is often unreliable — because keeping it at parity with prod (i.e. data and infra) is hard and expensive. So most teams cut corners: a fraction of the database, different instance sizes, and just some of the services.
It makes releases many times slower — an extra release level means waiting for the env, batching several features “because we are releasing anyway,” deploys that become morning-only (or only “at the start of the week”), and the classic “whose change broke staging?” moments.
The way out already existed in 2022: small diffs, strong automated tests, feature flags, canary / progressive delivery, and real investment in observability in production. This way problems in prod are smaller, and you are fast at catching them anyway, even without staging.
On top of this, bonus points if you setup two of my favorite things:
Preview links for QA — envs that spawn on the fly for features that need dedicated product review.
Remote dev environments — that live in the cloud and can inherently be closer to prod than a developer laptop.
This is the gist of what I wrote back then — if you want the longer version (including when staging still earns its keep), here is the original:
