Development, staging and production, three times over
The same eight variable names with different values in each environment, and one file that decides which is which.
- The setup
- A team running three environments per service across several services.
- In play
- Three environmentsSeveral servicesPer-environment provider keys
Every environment needs the same variable names with different values. That symmetry is what makes the mistake possible: a production value in a staging file looks completely correct.
The usual arrangement is .env.development, .env.staging and .env.production side by side in the repository directory, distinguished by a filename and nothing else.
What breaks
The files are interchangeable at a glance
Same keys, same shape, different values. Nothing in the file says which environment it is for, so copying the wrong one is a plausible, quiet mistake.
Testing against production is one filename away
A test suite pointed at a production key does real work against real data and bills real money, and the only thing that prevented it was picking the right file.
Three files to update per rotation
Rotation work triples, so the deferred-rotation problem triples with it — and it is usually the staging one that gets forgotten.
Production values sit on laptops
If .env.production is in the repository directory, it is on the machine of everyone who checked the project out, whether or not they ever needed it.
How it works here
Environments as separate projects
Each environment is its own project with its own keys. Selecting the wrong one is a deliberate selection, not a filename typo.
Production access is separately granted
With sharing, the production project is shared with the people who need it. It does not arrive automatically with a repository checkout.
Generate for one environment at a time
You produce the file for the environment you are working in. There is no drawer of near-identical files to pick the wrong one from.
Targets that match the deployment
Local work gets .env, containers get a Docker env file, CI gets GitHub Actions secret commands, and cloud deployments get gcloud or Kubernetes output — each correctly escaped for its own format.
Closest to your setup?
Install the extension, import an existing .env, and check the fit against your own projects. It works offline and nothing is uploaded unless you sign in.