What is a .env file?
Corbin Brown
2 min read
Part of the Vibe Coding Fundamentals video series on YouTube.
Your app has secrets: the API keys that let it charge cards and call AI models, the password to its database, the signing keys behind login. A .env file (“dot-env”) is where those secrets live — a plain text file of NAME=value lines sitting next to your code but deliberately not part of it. The code says “use the key named STRIPE_SECRET_KEY”; the .env file is where the actual key waits.
Why secrets can't live in the code
Code gets shared — pushed to GitHub, pasted into chats, sent to AI agents. Secrets must not travel with it. Bots scan public GitHub around the clock for exactly this mistake, and a leaked payment or AI key becomes someone else's spending money within minutes — real people have woken up to thousands of dollars in charges from a key that was public for an hour. The .env file is the separation that prevents it: code travels, secrets stay home. Every project ships with a .gitignore entry that tells Git to pretend .env doesn't exist, and that entry is the whole security model.
The three rules
- Never commit .env. If it ever lands on GitHub — even briefly, even in a private repo you later open — treat every key inside as burned and regenerate them all. Deleting the file afterward does not unleak it; Git remembers.
- Your deployed app doesn't get the file. Hosting platforms have an “environment variables” dashboard where you paste each secret — that's the production .env. It's also why an app that works locally breaks on the live URL: the code traveled, the secrets didn't.
- Watch what your agent touches. AI agents edit .env files, overwrite them, and occasionally print their contents into chat logs. Ours got protective about this for a reason.
FAQ
What's .env.example then?
The safe-to-share template: same variable names, values blanked out. It travels with the code so the next person (or the next agent) knows which secrets the app expects without seeing yours.
I think I leaked a key. What now, in order?
Regenerate the key at the provider first — that kills the leaked one instantly. Then check the provider's usage dashboard for charges you don't recognize. Then fix the leak itself (add .env to .gitignore, scrub it from Git history — your agent can do both). Rotating first matters; cleanup doesn't stop a key that's already harvested.