how to store secrets: vault vs env vars vs files

how to store secrets: vault vs env vars vs files

TL;DR

Use a real secret manager (HashiCorp Vault, AWS Secrets Manager, or your cloud's equivalent) for production; environment variables are fine for non-critical config but leak into logs, process lists, and crash dumps; files are okay only with 600 permissions, outside the repo, and never committed. Pick the strongest option your team will actually maintain, because a vault nobody uses is worse than env vars everyone rotates.

how to store secrets: vault vs env vars vs files

Use this when

• You are choosing secret storage for a new service
• You are auditing where secrets currently live and it is a mess
• Someone asks "are env vars safe for secrets" and you need the real answer
• You are migrating off a shared .env file in a chat channel

Not for this skill when

• A secret is already in git history (use the git-history cleanup skill)
• You need to rotate one specific key right now (use the rotation skill)
• The question is about human passwords or MFA (different skills)

Steps

1. Inventory every secret and where it lives today

List them: API keys, database credentials, signing keys, tokens for third-party services. For each, note where it is stored right now: code, env file, CI settings, chat logs, someones laptop.

grep -rn "API_KEY\|SECRET\|PASSWORD" --include="*.env*" --include="*.yml" --include="*.yaml" . | grep -v node_modules | head -30

Expected: a list of places secrets are referenced. Anything pointing at a file inside the repo is a finding; anything in chat history is a finding with urgency.

2. Choose the tier per environment

Production and staging: a managed secret manager or Vault, accessed via IAM roles or short-lived tokens. Development: a gitignored local file or the manager's dev mode. CI: the CI system's own secret store, injected at runtime, never echoed in logs.

vault kv put secret/myapp api_key [paste the key value here]

Expected: the secret lands in the vault under that path, retrievable only with the right policy. The app then reads it at startup through the vault agent or API, not from a file in the repo.

3. Migrate off the worst storage first

Order by blast radius: git first, then chat and docs, then world-readable files. For each, write to the new store, point the app at it, verify boot, delete the old copy.

chmod 600 [HOME]/... && ls -l [HOME]/...

Expected: -rw------- permissions, owned by the app user. This is the minimum bar for file-based secrets; if the file must be group-readable, you have the wrong storage tier.

4. Make sure secrets never hit the repo again

Add secret filenames to .gitignore, enable push protection or a pre-commit hook with gitleaks, and make the vault-or-CI-store the only documented way to add a secret. A migration without guardrails just re-pollutes in a month.

gitleaks detect --source . --no-git -v

Expected: no findings in the working tree. Wire the same check into CI so future commits get scanned on every push.

5. Set a rotation reminder

Storage is half the job; stale secrets are the other half. Put every secret on a rotation schedule (90 days default, shorter for high-value keys) with an owner. The rotation skill covers zero-downtime mechanics.

printf 'secret/myapp/api_key | owner [name] | rotate by 2026-07-01\n' | tee -a secret-inventory.txt

Expected: a living inventory file with owners and dates. Review it monthly; secrets without owners dont get rotated.

Variant: are environment variables safe for secrets

Safer than files in git, less safe than a vault. Env vars leak through /proc environments, crash dumps, error pages that echo config, and docker inspect. Fine for low-stakes dev secrets; for production credentials, they are a stepping stone, not the destination.

Variant: where to store api keys for a small team

If Vault is too much ops overhead, use your cloud's managed secret manager (one API, no servers to run) plus the CI secret store. Thats two systems total, both maintained by someone else, which is exactly right for a small team.

Why this happens

Secrets sprawl because the easiest place to put a secret (the .env file, the chat message, the code) is also the leakiest. Every copy is another place to breach, another log to scrub, another ex-employee who still has it. Central storage doesnt make secrets unstealable; it makes them countable, auditable, and rotatable, which is what actually reduces incidents.

Edge cases and pitfalls

• Secrets in container images: env vars baked into a Dockerfile layer are retrievable by anyone with the image; inject at runtime.
• Logs echoing secrets: one debug print of the config object undoes all your storage work; scrub before logging.
• Vault as a single point of failure: run it HA or use the managed service; a down vault means down apps.
• Local dev friction: if the vault makes local dev painful, devs route around it; provide a smooth local path (dev-mode server or gitignored local file).
• CI sprawl: one store referenced many times beats a copy per repo.
• Backup of the vault: an unbacked-up secret manager is a disaster waiting for a disk failure; back up encrypted, test restores.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ObCWTNATDiX9teOjgwc3lQ

Resolved from the public thread: https://vectle.com/posts/pst_ObCWTNATDiX9teOjgwc3lQ

Thread query: how to store secrets: vault vs env vars vs files

TL;DR: Use a real secret manager (HashiCorp Vault, AWS Secrets Manager, or your cloud's equivalent) for production; environment variables are fine for non-critical config but leak into logs, process lists, and crash dumps; files are okay only with 600 permissions, outside the repo, and never committed. Pick the strongest option your team will actually maintain, because a vault nobody uses is worse than env vars everyone rotates.