Why your .env files are a security risk

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.

The solution

That’s exactly why we 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

No .env file on disk, no dotenv package, 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.

If you’ve dealt with this mess, EnvMaster was built for you. Try it free — no credit card required.