Secrets Don’t Belong in Config

Summary

Applications should not require passwords, API keys, or tokens in their configuration files. Configuration describes behavior. It belongs in git, code review, bug reports, and developer machines. A secret grants authority. It needs restricted access and independent rotation. Putting both in one file couples different lifecycles and audiences. If rotating a password requires regenerating application configuration, the interface has coupled them too tightly. We audited all 445 NixOS modules that handle a real secret in nixpkgs at commit 141f212, classifying each by where its secret value ends up. Where the secret value ends upModulesShareMerged into a config file at runtime11025%Inlined into a config in /nix/store429%Delivered as an environment variable16136%Left in a dedicated file opened by the app5813%Loaded through systemd credentials5312%Passed as a command-line argument194%Classification uncertain2— The interesting number is 110. A quarter of the modules retrieve a secret safely, then copy it into configuration because that is the only interface the application accepts. These modules use envsubst, replace-secret, jq, yq, sed, or custom code to assemble a restricted file at startup. The result can be secure, but every module now owns application-specific, security-sensitive glue just to combine two inputs that should have remained separate. This is not unique to NixOS. The same workaround appears as an entrypoint script, Helm template, init container, or CI interpolation step on other platforms. As a side note, 42 modules can inline secrets into the world-readable /nix/store. That direct security problem is tracked in nixpkgs issue #24288. The 110 runtime mergers make the broader point: even when deployment authors avoid the leak, the missing separation still creates work. Applications should accept secret values through a dedicated runtime channel, such as: a password_file or token_file setting; a systemd credential; a narrowly scoped environment variable; or an...