Store server secrets outside code

A secret committed with the application travels through every clone, build, and backup of that repository.

Keep credentials out of the code, out of the shell history, and out of process listings. Deliver them to the service through protected configuration instead.

A root-controlled environment file

Use the deployment platform or a root-controlled configuration file with narrow permissions:

sudo install -m 640 -o root -g blog /dev/null /etc/blog/env
sudoedit /etc/blog/env

# /etc/blog/env
DATABASE_URL=postgres://blog:9sK2mfA81vTq@localhost/blog

Root owns the file, the blog group can read it, and mode 640 keeps everyone else out. Using sudoedit matters: typing the value into an echo command would leave it in your shell history. The systemd unit then loads it:

[Service]
EnvironmentFile=/etc/blog/env

Avoid command-line arguments that appear in process listings. Anything passed as an argument is visible in ps output to every user on the machine for as long as the process runs.

Verify the boundary

sudo -u www-data cat /etc/blog/env
# cat: /etc/blog/env: Permission denied

Separate production and development values and document rotation without printing the value. A rotation note should say where the credential lives and who ran the change, never what it was.

Rotation is part of the move

Moving a password from Git into a world-readable environment file does not solve exposure. The old value also remains valid until you rotate it. Check backups and deployment logs for older copies. Rotation ends the credential’s authority, while removing residual plaintext reduces future accidental disclosure and investigation noise.

Move one credential to root-controlled configuration and record its mode, owner, and readers without printing it. Prove the service starts, an unrelated user cannot read it, and the rotated old value no longer authenticates.