Every project starts the same way. You need a database URL, an API key, and a couple of feature flags, so you create a .env file, add it to .gitignore, and move on. It works. It is simple, local, and free.
Then the team grows. Staging needs different values than production. A new engineer needs access on day one. A contractor needs read-only access to two keys. Someone pastes a production token into a chat thread at 11pm. Suddenly the question is not "how do I store a variable?" but "how do I store a variable safely, repeatedly, for a whole team?" That is where the .env file vs secrets manager decision stops being academic.
This article breaks down what each approach actually does, where plain files hold up, where they fall apart, and how to decide which one your team should be using right now.
What a .env file actually does well
A .env file is a flat text file of KEY=value pairs that your runtime loads into the process environment. Its strengths are real, and they are worth naming honestly:
- Zero setup. No dashboard, no account, no SDK. You create the file and your framework reads it.
- Local by default. It lives on your laptop, ignored by Git. For solo work, the security surface is exactly one machine.
- Framework-native. Nearly every stack, from Node with
dotenvto Django, Rails, and Next.js, expects environment variables and reads.envwithout ceremony. - Fast to debug. It is plain text you can open and read. When a value is wrong, you see it immediately.
For a solo builder, a prototype, or a project that will never leave your machine, a .env file is often the correct answer. The trouble starts when the file has to travel.
Where plain .env files break down at team scale
The problems with .env files at scale are not really about the file format. They are about how the file gets copied, shared, and trusted.
Secrets end up in places they shouldn't
Once more than one person needs the values, the file gets transmitted. Slack, email, a shared drive, a screenshot in a ticket. Every copy is a full copy with no expiry and no record of who has it. You cannot un-share a .env file, and you often cannot tell who has one.
Nothing is encrypted at rest
A .env file sits in plaintext on every machine that has a copy, and in plaintext on every server you deploy it to. If a laptop is lost or a build log accidentally echoes the environment, every secret in that file is exposed at once.
Access is all-or-nothing
.env files have no concept of roles. Either you have the file or you do not. That makes least-privilege access impossible: a frontend engineer who needs one public key gets the production database password too. Onboarding and offboarding both become manual, error-prone rituals.
Drift between environments is invisible
With a file-per-environment model, it is easy for staging to be missing a key that production has, or for a rotated credential to be updated in one place and forgotten in another. There is no single source of truth, so nobody can say with confidence what the "correct" set of variables is.
Rotation is a fire drill
When a secret leaks, you need to rotate it everywhere it lives. With flat files, "everywhere" is a list you have to reconstruct from memory and Slack history. That is the moment most teams decide they want a system, not a folder of copies.
What a dedicated secrets manager adds
A secrets manager keeps the same KEY=value idea but wraps it in the guarantees a team needs. The core capabilities are consistent across tools:
- Encryption at rest. Values are stored encrypted, not as readable text, so a stolen backup or a compromised disk is not an instant breach.
- Role-based access. You grant access per person, per role, per project, and per environment. A contractor can read two staging keys and nothing else.
- Environment separation. Development, staging, and production are distinct scopes, so production values never leak into a local run by accident.
- Auditability and rotation. You can see who accessed what and change a value once, centrally, when it needs rotating.
- A single source of truth. One dashboard and one CLI replace a dozen drifting files.
Envly was built around exactly this model: store encrypted configuration by project and environment, share access by role, and export ready-to-use .env files from one dashboard or the official CLI. The point is not to ban the .env format. It is to stop treating a plaintext file as the source of truth.
The trade-off you are actually making
The honest framing is not "files are bad, managers are good." It is a trade between setup friction and operational safety.
.env files optimize for speed today: nothing to configure, nothing to learn. That is the right trade when the blast radius of a leak is one person and one laptop.
A secrets manager optimizes for safety over time: a bit more setup, a bit more process, in exchange for encryption, granular access, and a clear answer to "who has this secret and how do I change it?" That is the right trade the moment more than one person, or more than one environment, depends on the values.
Neither approach is a moral choice. It is a question of scale and consequence.
Decision checklist: which should your team use?
Run through these questions. The more you answer "yes" to the middle and later ones, the more a manager earns its place.
- Is it just you, on one machine? Stay with
.envfiles. Keep them out of Git and you are fine. - Do secrets need to reach a second person or a CI pipeline? Start caring about how the file travels.
- Do you run more than one environment? You need separation and a single source of truth, which flat files cannot give you.
- Do different people need different levels of access? Role-based access is the answer; a shared file cannot express it.
- Have you ever rotated a leaked secret? If the process was painful, that is your signal.
- Do you have compliance or audit obligations? Encrypted storage and access logs are table stakes.
- Would a single leaked file expose your whole system? If yes, encryption at rest is not optional.
A common pattern is a hybrid: keep a .env file locally for convenience, but never treat it as the source of truth. Instead, pull values from a manager and export them into the format your runtime expects. You keep the developer workflow you like and remove the plaintext copies that cause incidents.
The bottom line
.env files are not the problem. Treating a flat, unencrypted file as the system of record for a team's secrets is. Start with .env when you are solo; move to a secrets manager when sharing, multiple environments, and least-privilege access become real requirements, which is usually sooner than teams expect.
If you are weighing the switch, the question to ask is simple: if this file leaked tomorrow, how bad would it be, and how long would it take to fix? Your answer tells you which side of the .env file vs secrets manager decision you are on.