How should I manage secrets for Docker Compose files stored in Git?

SOPS is a popular option when you want encrypted secrets to remain version controlled. The secret file is encrypted in Git and decrypted only during deployment, using a key stored outside the repository. Ansible Vault provides a similar workflow. This works well when you have two or more hosts and want the encrypted configuration backed up without exposing the contents.

Another common pattern is to have CI/CD create the .env file during deployment. The pipeline retrieves values from a secrets store, writes them on the target host or into a container secret, and removes or restricts access to the temporary file afterward. For a small personal setup, locally stored secrets plus encrypted backups may be simpler than operating a full Vault instance.

A straightforward setup is to keep Compose files, scripts, and configuration templates in Git, while storing real secrets separately on each host, such as under /etc/secrets/docker/. Commit an example file containing the required variable names and comments, but never the actual values. This keeps credentials out of Git, makes rotation easier, and lets you use different secrets per server. Back up the secret directory separately from application data and the repository.

For a larger or more centralized setup, use a secrets manager such as Vault, OpenBao, or a password manager with a command-line integration. Your deployment process authenticates to the service and injects the values into the Compose environment or mounted secret files at runtime. That avoids storing plaintext .env files on the server, although the deployment credentials and encryption keys still need their own secure backup.