Why your .env files are a security risk (and what to do instead)

Selixe — Mon, 16 Mar 2026 17:32:48 +0000

Why your .env files are a security risk (and what to do instead)

If you've been developing for more than a year, you've probably done at least one of these:

Committed a .env file to git by accident
Sent a teammate your database URL over Slack
Had a .env.production file sitting on your laptop with live API keys
Lost track of which machine has the "real" values

None of these feel like a big deal in the moment. Until they are.

The actual problem with .env files

The .env file pattern works fine when you're the only developer and you never
make mistakes. In practice that means it works fine for about five minutes.

The real problems start when:

You have a team. Now you need to share secrets somehow. Slack, email, Notion,
a shared password manager — all of these are worse than you think. Someone leaves
the company and you're not sure what they have. A Slack message with your Stripe
key is sitting in a searchable archive forever.

You have multiple environments. Now you have .env.development, .env.staging,
.env.production, and a 50% chance that at least one of them is out of date on
at least one machine.

You have multiple projects. Now you have a folder of .env files somewhere and
you're manually copying values between them and praying nothing drifts.

You work across machines. The values on your laptop and your desktop are
different and you don't remember which one is right.

The git problem

The most common disaster is the accidental commit. You add a new variable, forget
to check .gitignore, and push. Even if you catch it and remove it in the next
commit, the key is in your git history forever. Anyone who clones that repo has it.

GitHub's secret scanning catches some of this, but only for known patterns like
AWS keys and Stripe keys. Your custom internal secrets are invisible to it.

The standard advice is "just add .env to your .gitignore" but that's not enough.
You also need to make sure every developer on your team has done the same, on every
project, every time. One person forgets and you have a breach.

What actually fixes this

The right solution has a few properties:

Secrets never live on disk in plaintext
Secrets are centralized so there's one source of truth
Access is controlled so people only see what they need
Changes are audited so you know what changed and when
It works with your existing workflow so people actually use it

There are enterprise solutions for this — HashiCorp Vault, AWS Secrets Manager,
Doppler. They're good if you're running infrastructure at scale. They're overkill
if you're a small team trying to ship software without leaking your database
credentials.

What I built

I got frustrated with this problem enough that I built
EnvMaster — a CLI tool that stores your variables
encrypted in the cloud and injects them directly into any process.

The workflow looks like this:

envmaster project my-api
envmaster environment production
envmaster run -- node server.js

That's it. No .env file on disk, no dotenv package in your project, no manual
exports. The right variables are injected into the process and exist only in
memory for the duration of the request.

Everything is encrypted at rest with AES-256-GCM before it hits the database.
Keys are stored separately from the data. Your plaintext values never persist
to disk on our end.

For teams it supports per-project roles so frontend developers never accidentally
see backend secrets, and a full audit log so when something breaks in production
you know instantly whether a variable change was the cause.

There's a free tier and a Pro trial on every new account. No credit card required
to start.

The bottom line

.env files are a fine pattern for a solo developer on a single project. The moment
you add a second person, a second environment, or a second machine, the cracks
start showing.

The fix isn't complicated — centralize your secrets, encrypt them, control who can
see them, and inject them at runtime. Whether you use EnvMaster or something else,
the .env file era is worth leaving behind.

Built EnvMaster to solve this exact problem. Would love feedback from anyone
who's dealt with the same mess.

DEV Community: Selixe

Why your .env files are a security risk (and what to do instead)