DEV Community

Cover image for Stop Committing Your API Keys (A Love Letter to .env and Secret Managers)
Ksatria Bintang Samudra
Ksatria Bintang Samudra

Posted on

Stop Committing Your API Keys (A Love Letter to .env and Secret Managers)

I want to tell you about the worst thirty seconds of a developer's week. You push a commit. Your phone buzzes. It is an automated email from your cloud provider: "unusual activity detected." Someone found your key, spun up a fleet of GPU instances to mine crypto, and you now owe thousands of dollars.

I have watched this happen to real people. It is never a movie villain. It is a key that should never have been in the code in the first place.

So let me write the love letter your secrets actually deserve.

Why secrets leak (it is always the same three doors)

Secrets do not escape through some exotic hack. They walk out through doors you left open.

Door one: git history. You committed a key, deleted it in the next commit, and now you think it is gone. It is not. It is sitting in the history forever, and bots scan fresh public pushes within seconds looking for exactly this. Deleting the line does nothing. The history remembers everything.

Door two: the client bundle. Anything in your frontend JavaScript is public. I can open dev tools and read it. That "secret" key baked into your React app? Every visitor can see it. If the browser can read it, it was never a secret.

Door three: the human stuff. A key in a screenshot on a bug report. A token pasted into a Slack channel. A .env file emailed "just this once." Secrets have a talent for ending up exactly where you least expect them.

Green code scrolling down a dark screen

What a leaked key actually costs

People underestimate this because the key feels small. It is not small.

A leaked payment key can drain real money. A leaked cloud key can run up a five-figure bill overnight, and good luck getting that refunded. A leaked database credential can expose every user you have, and now you are not debugging, you are writing a breach disclosure and talking to lawyers.

One string. That is all it takes. The blast radius of a forgotten key is almost never proportional to how careless it felt in the moment.

How to do secrets right

Here is the part I actually love, because the fix is genuinely easy.

Keep secrets in environment variables, loaded from a .env file locally. Then add .env to your .gitignore before you write a single key into it. Commit a .env.example with empty placeholders so your teammates know what to fill in, without ever shipping the real values.

For anything past a side project, graduate to a real secret manager. AWS Secrets Manager, Vault, Doppler, your platform's built-in store, pick one. They give you access control, audit logs and rotation in one place. Your app reads the secret at runtime. It never lives in the repo.

Rotate on a schedule, and rotate immediately the moment a key is exposed. A rotated key is a dead key, and a dead key cannot bill you.

Build a net, not just good intentions

Discipline fails. People are tired, deadlines are real, keys slip through. So automate the safety net.

Add a secret scanner to your pipeline. Tools like gitleaks or trufflehog, plus GitHub's own push protection, will catch a key before it ever lands. Run it as a pre-commit hook so the key gets blocked on your machine, not discovered on someone else's.

And if you do leak one, do not just delete the commit. Rotate the key first, then clean up. The order matters. The exposed key is the emergency, not the tidy git history.

Your secrets are the keys to the whole building. Stop leaving them under the doormat and taping a spare to the front window.

I am Ksatria Bintang Samudra, an AI-native full-stack engineer with a penetration-testing background and a deep interest in digital forensics, open to remote work worldwide. More of what I build at ksatriabintangsamudra.com.

Top comments (0)