There is no universally safe secret location. For a small Linux deployment, prefer a mechanism that keeps credentials out of source control and images, limits file or process access, avoids backup leakage, and gives the owner a practical rotation path.
How do the common choices compare?
- Environment variables: convenient, but can leak through process inspection, diagnostics, crash reports, or accidental logging depending on the runtime.
- Compose files: readable and deployable, but dangerous when committed, copied into backups, or broadly permissioned.
- systemd credentials or protected files: can improve separation and permissions, but require service-specific design and verification.
- External secret manager: strongest separation when operated well, but adds availability, identity, and recovery dependencies.
What should the minimum design include?
Give every secret a purpose, owner, source, access boundary, rotation date, and revocation procedure. Keep .env files out of repositories and backups where appropriate; do not assume a file is safe because its name is hidden.
For systemd services, distinguish environment configuration from credential delivery and review the unit’s readable paths. For Compose, prefer the documented secrets mechanism where it fits, while checking how the chosen application actually reads the value.
What should never be claimed without testing?
Do not promise that a mechanism hides a secret from every process, log, crash dump, container, or backup. The exact visibility depends on the host, runtime, service, permissions, and diagnostics tooling. Verify the stated threat model before publishing an operational guarantee.
Read the site’s Docker socket boundary and server security checklist alongside this decision guide.