Secrets in Self-Hosted Docker: Stop Committing .env Files

The .env file problem

Almost every project starts the same way. You put your database URL and API keys in a .env file, add it to .gitignore, and move on. It works, until it does not. Someone commits the file by accident. A new teammate needs the values and they get passed around in a chat. The production copy drifts from the one on your laptop, and nobody is sure which secret is current. The file has no history, no access control, and no record of who read it.

Environment variables are the right shape for configuration. A flat, unversioned file on disk is the wrong way to store the sensitive ones.

What a real secrets store adds

Moving secrets into a managed store changes a few things that matter:

• Encryption at rest. InfraPilot stores secrets with AES-256-GCM and a per-organization key, so the values are not sitting in plaintext on the filesystem.
• Versioning. Every change is a new version. If a rotation breaks something, you can see the previous value and what changed.
• Container binding. A secret is attached to the containers that need it and injected at runtime, rather than copied into an image or a compose file where it can leak.
• An audit trail. You can see when a secret was created, updated, and bound, instead of guessing.

Getting off .env

Migration is not dramatic. For each service, take the keys out of the .env file, add them as secrets, and bind them to the container. The application still reads them as environment variables, so no code changes are needed. Once the container is running from bound secrets, delete the file. The habit to build is simple: a secret goes into the store first, and never into a file that lives next to your code.

Rotation without downtime

Rotation is where the versioning pays off. When you update a secret, you create a new version and the bound containers pick it up on their next restart. If the new value is wrong, the previous version is right there to restore. Because rotation is a normal, low-risk operation rather than a scary one, you are far more likely to actually do it on a schedule.

Who can see what

Secrets should not be readable by everyone with a login. Keep secret access tied to roles, so a viewer can confirm a service is healthy without being able to read its database password. Combined with the audit log, that gives you a defensible answer to the question every security review eventually asks: who can access production secrets, and how would you know if they did.