Environment Variable Security: What Never to Commit | Envly

You shipped your first feature, the deploy worked, and then a teammate pings you: your .env file is in the repo. It has been there for two weeks. That is the moment most developers start thinking seriously about environment variable security, and it usually arrives right after a close call rather than before it. The good news: the fix is smaller than it looks. A few habits cover most of the risk, and one tool covers the rest once your team outgrows a single developer. Here is what never belongs in a commit, how to keep local variables safe, and when to move to an encrypted secrets manager. ## Git keeps the secret you deleted Deleting a leaked .env file does not undo the leak. Git stores the full history, so anyone who clones the repo can read the old value back with a single log command. Rotate the credential first, then clean up history if you want. A revoked key in an old commit is a dead string; a live key is an open door. ## What never belongs in a commit If you remember one rule, make it this: real values never get committed. Keep a .env.example with the variable names and placeholder values, and keep the real .env out of version control entirely. Never commit API keys and tokens, database credentials, private keys and certificates, session and JWT signing secrets, or the filled-in .env itself. Each of these is a bearer credential: whoever holds the string holds the access. ## Simple habits that keep local variables safe Ignore .env on day one, before you write the first variable. Commit a .env.example instead, so new teammates copy the shape of the config without the values. Log the keys, never the values, because printing a config object on boot dumps secrets into your console and your log pipeline. Run a pre-commit scanner such as gitleaks or detect-secrets so a credential never reaches the remote at all. And treat every value as disposable: anything you cannot rotate quickly is a liability. ## When local files stop being enough Local .env files work for one developer and start to hurt at the second or third. Someone needs the staging password and sends it over Slack. A contractor needs read-only access to one project, and your only options are all-in or all-out. A laptop is lost. None of this is a discipline problem; it is a file-based system being asked to control who sees what, which it cannot do. ## What team-grade security looks like An encrypted secrets manager gives you one source of truth, encrypted at rest, with role-based access and a CLI that fits how you already work. Variables are split by environment, so a new engineer sees the shape of the config without holding a production secret. Staging is open, production is limited to the people who deploy, and revoking someone is a click rather than a password reset across five services. You pull the right variables with one command instead of pasting them into a thread, and you can export a .env when existing tooling needs one. ## The bottom line Environment variable security starts as a habit and ends as a system. Ignore the file, keep a template, scan your commits, and rotate anything that ever leaked. When sharing secrets across a team starts to feel like a liability, move the source of truth into something encrypted with real access control. Your secrets belong in a vault, not in a chat thread.