Every developer knows the drill.
Create a .env file. Add your keys. Add .env to .gitignore. Done, you're secure.
Except you're not. Not really.
.env files are a good first step but they're nowhere near enough on their own. And the false sense of security they create is actually part of the problem.
What .env Files Actually Do
A .env file is just a plain text file that stores key value pairs. When your app starts up it reads those values and makes them available as environment variables in your code.
That's it. There's no encryption. No access control. No audit trail. No expiry. It's a text file sitting on your filesystem.
The only protection a .env file gives you is keeping your keys out of your source code. That's valuable. But it's one layer of protection in a world where you need several.
The Ways .env Files Fail You
Someone accidentally commits it
This is the most common one. You're moving fast, you do a git add . and suddenly your .env file is in version control. Even if you catch it and remove it in the next commit, the key is now in your git history forever. Anyone who clones the repo has it.
GitHub has bots scanning for this constantly. Your key can be grabbed within seconds of being pushed to a public repo.
Your machine gets compromised
If someone gets access to your laptop, your VM, or your development server, every .env file on that machine is immediately readable. Plain text, no encryption, no password required.
One phishing attack, one malicious npm package, one insecure public wifi session. That's all it takes.
Sharing keys across a team becomes a mess
How do you share .env files with teammates? Most developers end up sending them over Slack, email, or storing them in a shared Notion doc. Now your keys are living in places that were never designed to store secrets.
Every person you share the file with is a new potential exposure point. And when someone leaves the team, do you actually rotate every key they had access to? Almost nobody does.
No visibility into who has what
With .env files scattered across developer machines, staging servers, and CI environments, you have no central view of where your keys live. You can't see who has access. You can't audit usage. You can't tell if a key has been leaked until something breaks or you get an unexpected bill.
Keys live forever
.env files never remind you to rotate keys. Most developers set up their .env once and never touch it again. That key might be years old with no record of when it was created or who has seen it.
What Developers Do That Makes It Worse
Using the same key in development and production is extremely common. It feels convenient until your dev environment gets compromised and takes down production with it.
Keeping a master .env file in a shared folder or cloud storage so the team can access it. Dropbox, Google Drive, iCloud. None of these are built for secrets management and all of them have had breaches.
Hardcoding keys directly when .env feels like too much friction. Especially in scripts, quick tools, and one-off projects that end up running in production forever.
Not having any process for what to do when a key gets exposed. So when it happens you're scrambling, trying to remember where every key is used while the clock is ticking.
What You Actually Need
Encryption at rest
Your keys should be encrypted when stored, not sitting in plain text. If someone gets access to the storage, they should see encrypted data that's useless without the decryption key.
Access control
You should be able to control exactly who can see which keys. New developer joins the team? You grant them access to only what they need. Someone leaves? You revoke their access immediately without having to rotate every key.
Audit trail
You should know when a key was created, when it was last accessed, and by whom. This visibility is what lets you respond quickly when something goes wrong.
One central place
Every key your team uses should live in one organized place. Not scattered across machines, Slack messages, and Notion docs. Centralized storage means you can actually manage your keys instead of just hoping nothing goes wrong.
Key rotation reminders
You should be reminded to rotate keys regularly, not just when you remember or when something breaks.
The Right Way to Think About .env Files
Don't stop using .env files. They're still useful for local development. But treat them as a convenience layer, not a security solution.
Your actual security comes from what's behind the .env file. Where did those values come from? Who has access to them? How are they shared and managed?
.env is the last mile, not the whole journey.
A proper secrets manager handles the storage, encryption, access control, and sharing. Your .env file just pulls the values from there into your local environment.
This is exactly the problem I kept running into across multiple projects, keys scattered everywhere with no real control over who had access to what. That's why I built Keydock, a zero knowledge API key manager that encrypts your keys client side before they ever hit a server.
You get one organized secure place for all your keys, with access control and the ability to share with teammates without ever exposing the raw values.
Try it free at keydock.cloud
Top comments (1)
Use varlock.dev with an existing vault (1pass, aws, etc)