.secrets -
You set up a nightly backup script for your home directory. It captures /home/user/projects/. It captures the .secrets file. The backup goes to an unencrypted S3 bucket. The bucket gets misconfigured. You lose everything.
Before we discuss tooling, let’s look at what a healthy .secrets file looks like. It follows a strict naming convention and strict access rules.
# .secrets - NEVER COMMIT THIS FILE
| Technique | How to apply |
|-----------|--------------|
| File system permissions | chmod 600 .secrets (owner read/write only). On Windows, set the file to “Read‑only” for the user and remove “Everyone” access. |
| Encrypt the file | Use gpg or age to encrypt the file for team members: gpg -c .secrets → creates .secrets.gpg. Decrypt at runtime (e.g., in CI) and pipe into environment variables. |
| Secret‑management services (recommended for production) | • AWS Secrets Manager – retrieve via SDK/CLI. • HashiCorp Vault – dynamic secrets, lease/renewal. • Azure Key Vault, Google Secret Manager – similar capabilities. |
| CI/CD integration | Store secrets as protected variables (GitHub Actions Secrets, GitLab CI variables, CircleCI contexts). In the pipeline, write them to a temporary .secrets file with strict permissions, run the build, then delete the file. | .secrets
Run this command in your terminal to find every .secrets file on your machine (including deleted Git commits):
find . -name ".secrets" -type f 2>/dev/null
Then, to check Git history:
git log --all --full-history -- "*/.secrets"
Given the risks, how does a mature engineering organization use .secrets files safely?
Production secrets belong in a secrets manager: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, or even Kubernetes Secrets (with encryption at rest). The .secrets file is for local development only. You set up a nightly backup script for your home directory
| Reason | What it solves |
|--------|----------------|
| Avoid accidental commits | By keeping secrets out of source code you prevent them from being pushed to public repos. |
| Centralized management | All secret values live in one place, making rotation and audit easier. |
| Environment‑specific values | You can have separate secret files for development, staging, production, etc. |
| Tooling support | Many libraries (dotenv, python‑decouple, etc.) can automatically load a hidden file. |
Rule of thumb: Never let a secret ever touch source control. Keep it in a hidden, ignored file (or a managed vault), give it the strictest file permissions, load it once at startup, and rotate it regularly. Run this command in your terminal to find every