The Case Against Storing Secrets in Environment Variables

An opinion piece pushes back against the common practice of passing secrets via environment variables, arguing that pulling them directly into application code from structured config is often the better approach.

The author's first argument is consistency: mixing ini/yaml/json config files with separate environment variables (as often happens in Docker setups, split between compose files and .env files) creates a fragmented, error-prone setup.

Second, handling secret loading inside the application avoids injection quirks tied to specific platforms. The author recalls a previous job where secrets were pulled at runtime from S3 while running on AWS ECS, because setting them as environment variables there risked leaking them through the ECS console.

Third, the author isn't worried about storing secrets on disk, since they always use full disk encryption, layer on encfs/gocryptfs when that's insufficient, and note that if an attacker gets past both, the whole machine is already compromised anyway — environment variables wouldn't be any safer.

Finally, for applications with deep, complex data structures, the author finds JSON/YAML far more manageable to work with than flat environment variables.