● DEVOPS 01.05 Jun 24, 2026 5 min

Why we need a staging environment

Does keeping a replica of the production environment really matter? What does it get you?

Illustration of a stage in black and white
FIG.1 · staging environment

It’s common, out there in the wild, to find companies that dig their heels in when the topic is creating a proper staging environment, claiming savings on infrastructure costs. Those same companies eventually run into critical production incidents that, almost as a rule, end up costing way more than the staging environment would have. Today we’ll go over what a staging environment really is, what purposes it serves, and strategies to mitigate the infrastructure cost of keeping one.

The concept

The name “staging” refers to the final test before production; it comes from “stage testing”, the final tweaks in the most realistic scenario on stage, right before the show. This implies that the staging environment has to always be as close to production as possible, and when we say “as close as possible” we really mean in its entirety: not just the application’s features, but the network topology, security rules, scaling, databases, compute, error handling, observability alerts, authentication, capacity, and everything else you can think of. If it’s going to exist in production, it has to exist in staging too.

The cost of risk

Knowing what a staging environment actually is (or should be), it becomes much easier to understand which consequences and risks we’re accepting when we choose not to keep a staging environment in our delivery flow. We accept that we’re exposed to any and all potential failures that aren’t application-level (and this is assuming the application’s features were at least tested beforehand). It’s accepting that an observability alert might not fire. It’s accepting that the database might blow past its active connection capacity during a traffic spike. It’s accepting that your server might not handle some heavy operation in your application. It’s accepting that there could be a security hole in some layer that wasn’t tested and checked beforehand, and now what’s exposed is your users. It’s always cheaper to skip the staging environment, right up until one of those bombs goes off.

Beyond just having a staging environment, it has to fully serve its purpose. It’s not enough to have a “glorified QA environment”, an environment with reduced compute, data far from reality, an altered network topology, or without production’s traffic volume. Want a few examples of how much a well-oiled staging environment is missed?

How to minimize infra costs?

Even showing that it’s much cheaper to keep a staging environment than to run the risks of the alternative, for many companies it can still be an expensive investment that eats into margin. It’s desirable, but not always possible.

To work around this, we have a few strategies that mainly involve ephemerality and on-demand servers and services. This depends a lot on the reality and maturity of each development team, but considering delivery flows every sprint (usually two weeks), does it really make sense to keep environments idle and racking up costs? Most cloud services today offer ways to partially shut services down and cut costs. Pulling a few examples from AWS, Amazon Aurora recently started accepting minCapacity 0, which halts compute costs when it stops receiving connections. EC2 has start/stop, ECS has desiredCount, S3 has Glacier. The rule here is to provision only on demand, to cut idle costs as much as possible. Using IaC, most of these things can even be torn down completely and brought back as needed, if a cold start of a few hours (depending on scale) is acceptable for your team’s flow.

← back to /blog END · 01.05