Environments: how many do you actually need?

The point is confidence, not ceremony

Environments exist to let you find problems before customers do. One that differs from production in ways nobody has documented does the opposite: it produces false confidence and lets a class of bug through.

Local: fast and disposable

The one developers use constantly, so it must be quick to reset and possible to set up from written instructions — a requirement that overlaps exactly with what a handover should include.

Staging: production-shaped or pointless

Its only job is to resemble production closely enough that passing there means something. Different data volumes, missing integrations, or a different runtime version each remove a category of bug it could have caught.

A staging environment that differs from production in undocumented ways is a machine for generating false confidence.

The data problem

Real customer data in staging is a breach waiting to happen; wholly synthetic data misses the edge cases that cause real failures. Anonymised production-shaped data is the workable middle, and generating it is a genuine piece of work.

You may not need a third one

Adding environments multiplies configuration, cost, and drift. Often the better investment is flags and staged rollout in production, which tests against reality rather than an approximation.

Configuration is where the incidents come from

Most environment-specific outages are a setting that differed: a key pointing at the wrong service, a flag left on, a limit set for staging. Keeping configuration explicit and comparable across environments prevents more incidents than adding another environment ever will.