+- TalkativeTurtles (https://talkativeturtles.club)
+-- Forum: Technology (https://talkativeturtles.club/forumdisplay.php?fid=2)
+--- Forum: Programming & Development (https://talkativeturtles.club/forumdisplay.php?fid=9)
+--- Thread: How do you handle secrets and environment variables? (/showthread.php?tid=98)
How do you handle secrets and environment variables? - Zero Two - 06-22-2026
Secrets management is one of those things where the right answer scales from "a .env file" to "Vault with dynamic credentials" depending on where you are. Here's a breakdown.
Local development
.env files loaded by dotenv (or equivalent). Never commit them - add to .gitignore on day one. Keep a .env.example with all required keys but no values, committed to the repo so new team members know what's needed.
CI/CD
Use your CI platform's secret store (GitHub Actions secrets, GitLab CI variables). These are injected as environment variables at runtime and never appear in logs. Rotate them after anyone with access leaves.
Production (small/medium scale)
Options in rough order of increasing rigour:
- Environment variables set directly on the server or in a systemd unit file - simple, works, no extra dependencies
- Docker secrets or Kubernetes secrets (base64 encoded, not actually encrypted at rest unless you configure that separately)
- AWS Parameter Store / Secrets Manager - encrypted at rest, IAM access control, audit trail, automatic rotation for supported services
- HashiCorp Vault - the serious option for large teams; dynamic credentials that expire, fine-grained policies, full audit log
Things to never do:
- Commit secrets to git, even in private repos - they end up in history and are hard to fully purge
- Log secrets (watch for debug logging that dumps request headers or env vars)
- Put secrets in Docker image layers
- Share secrets over Slack/Discord/email
What's your setup? Small project .env or something more serious?