This is where enter the chat. Modern Workflows: From .secrets to Vaults The .secrets file is rarely the source of truth in a professional setup. It is usually a transient artifact . The source of truth is a Secret Vault . The industry standard is HashiCorp Vault, but alternatives include AWS Secrets Manager, Azure Key Vault, and Doppler.
Look at your project right now. Do you have a .secrets file sitting in your downloads folder? Is there a forgotten branch on GitHub that contains one? Go check your .gitignore . .secrets
# .secrets.template DATABASE_PASSWORD=<your-local-password> API_KEY=<get-from-vault> The developer copies .secrets.template to .secrets and fills in the blanks. The template contains no real secrets, so it is safe in Git. The .secrets file is a bridge technology. It is human-readable, easy to debug, and works everywhere. But the industry is moving toward ephemeral secrets and OIDC (OpenID Connect) . This is where enter the chat
In the future, you won't have a file at all. Your application will ask the cloud provider: "Who am I?" The cloud says: "You are EC2 instance i-1234." The application then gets a short-lived token (valid for 1 hour) from the vault. No static .secrets file exists anywhere. The source of truth is a Secret Vault
Treat it carelessly—commit it to GitHub, email it around, log it to the console—and you are handing the keys to your kingdom to every bot scanning the internet. Treat it professionally—use a vault, rotate keys, ignore it from Git—and it becomes an invisible shield protecting your users' data.
Here is the professional workflow for .secrets : The developer never touches the production .secrets file. Instead, they authenticate with the Vault using their SSO (Single Sign-On). The Vault generates a temporary .secrets file locally for development only , filled with dummy or low-privilege data. 2. The CI/CD Injection In your pipeline (e.g., GitHub Actions), you do not store the .secrets file in the repo. Instead, you store each secret as an encrypted Repository Secret . During the build, the pipeline reads the encrypted variables and dynamically creates a .secrets file inside the ephemeral container.
# .github/workflows/deploy.yml - name: Create .secrets file run: | echo "DATABASE_PASSWORD=$ secrets.DB_PASS " >> .secrets echo "API_KEY=$ secrets.API_KEY " >> .secrets For containers, you never want the .secrets file baked into the Docker image. If someone downloads your image, they get your keys.