Is it safe to store secrets in .env files?
Short answer: a .env file is usually plaintext on disk. It can be fine for low-stakes local dev if you control Git, backups, and sync — and it is a bad canonical store for high-value, long-lived secrets on a laptop because it travels like any other file.
Long answer: read the table below and pick mitigations that match your threat model.
1. What a .env file actually is
A .env file is typically:
- Unencrypted at the application level (unless you add extra tooling).
- Readable by any process running as your user (and often by backups indexing the folder).
- Easy to duplicate —
cp, zip,rsync, IDE “export project.”
It is not “unsafe by default” in the sense that everything in computing is a trade-off. It is unsafe as a long-term vault next to source code.
2. Decision table
| Question | If “yes” | Implication |
|---|---|---|
| Will the file ever be committed or forked? | High risk | Use templates only; see keep secrets out of Git |
| Is the repo under Dropbox/iCloud/OneDrive? | High risk | Move secrets out or exclude paths |
| Is this a production secret on a laptop? | High risk | Prefer break-glass + cloud secret manager |
| Is this a scoped dev key with low blast radius? | Lower risk | Still rotate after leaks |
| Do you need OS-enforced access control? | .env is weak | Prefer Keychain or vault |
3. When .env is reasonable
- Local-only development with test credentials.
- File is gitignored, verified with
git check-ignore. - You accept plaintext-at-rest risk on a FileVault-enabled Mac with good physical security.
- Secrets are short-lived or easily rotated.
4. When .env is a bad primary store
- Production keys on developer machines “for convenience.”
- Shared secrets emailed around as
.envattachments. - Monorepos where people maintain five variants (
env.staging.final2). - Anything you would regret seeing in a screenshot or screen share —
.envencourages “open whole file.”
5. Safer architecture (without abandoning env vars)
Runtime still uses environment variables; storage changes:
- Keep master values in PassStore or Keychain-backed tooling (download, security).
- Inject into the process environment for the session:
# Illustrative: load names from a script you control — do not log values
set -a
source .env # optional: generated from vault export for this session only
set +a
npm run dev
- Close the terminal when done.
6. Compliance and “encrypt at rest”
Regulated environments often expect audited access and encryption. Plain .env files usually fail those bars unless wrapped (e.g. SOPS with KMS — advanced; see open source secret managers compared).
7. Soft CTA
If you want encrypted-at-rest developer secrets on macOS with workspace organization and Keychain options, use PassStore. For leak scenarios, start with why .env leaks and .env leaked — what to do.