.env files vs. a secrets vault: what actually belongs in each

.env files are everywhere, and for good reason: most frameworks read them natively, they are simple text, and every developer already knows the pattern. The trouble starts when a .env file stops being a convenient local artifact and quietly becomes the permanent, only copy of a team’s credentials.

What .env files are actually good at

An .env file is a fast way to inject configuration into a running process without touching code. That is a genuinely useful, narrow job: local runtime configuration for whichever service is starting up on your machine right now.

It is not designed to be:

  • A backup of your credentials.
  • A way to share secrets with a teammate.
  • A permanent record of what a production service actually uses.

Used for its actual job — local runtime config — a .env file is fine. Used as a substitute for real credential management, it becomes the single point of failure for a project’s secrets.

The core problem: .env files have no history and no ownership

A vault entry has a name, a project, an environment, and — in a good tool — a last-modified timestamp and an owner. A .env file on someone’s laptop has none of that. If it goes missing, nobody necessarily notices. If it is copied to a new laptop during a migration, there is no record of that copy existing. If it ends up attached to a support ticket or pasted into a chat “just to unblock someone,” it is now outside anyone’s control with no way to know it happened.

This is not a hypothetical: .env files are one of the most common ways credentials end up committed to git by accident, because they look like ordinary text files and are easy to git add . without noticing.

A better mental model: the vault is the source of truth, the .env file is an export

The fix is not to abandon .env files — frameworks expect them, and rewriting every tool’s config loading is not realistic. The fix is to change what a .env file is: not a place where secrets live, but a disposable file generated on demand from wherever the secrets actually live.

In practice that looks like:

  1. Every credential is stored once, in a vault, organised by project and environment.
  2. When a developer needs to run the project locally, they export a .env file from the vault for that project’s local environment.
  3. The exported file is treated as disposable — regenerate it any time, and never worry about losing it, because the vault is the real copy.
  4. .env stays in .gitignore, as it always should, but now that is a formality rather than the only thing standing between a secret and a public repository.

Why this matters more for production values

The risk scales with the sensitivity of what is in the file. A local .env with development-only, low-stakes values is a minor risk if mishandled. A .env file containing production database credentials or a live payment provider key, sitting on a laptop with no record of who has a copy, is a real incident waiting for an opportunity.

Production credentials in particular should almost never touch a plain .env file that gets copied between machines. If a deployment process needs them, they should come from the platform’s own secret injection (environment variables set in the hosting provider, a secrets manager, or CI/CD secret storage) — sourced from the same vault, not a file someone emailed themselves at 11pm to fix an outage.

A quick self-check

If you can answer yes to any of these, it is worth changing the workflow:

  • Do you have a .env file older than the project’s last credential rotation?
  • Has a .env file ever been shared over Slack, email, or a shared drive “temporarily”?
  • If your laptop was lost tomorrow, could you list every credential that was sitting in a .env file on it?

If the answer to the last one is “no,” that is the actual problem .env files create: not that they exist, but that nobody can account for where their copies have ended up.

Bottom line

.env files are a fine local convenience and a poor permanent record. Keep the vault as the single source of truth for every credential, generate .env files from it on demand, and treat every exported file as disposable rather than precious. The moment a .env file becomes something you would be upset to lose, it has already become the wrong place for that credential to live.