This is the most important step. You must tell Git to ignore this file. Open your .gitignore file and add:
# .gitignore
# Keep secrets safe
.secrets
Pro Tip: If you already committed a .secrets file by mistake, simply adding it to .gitignore won't delete it from history. You must remove it from the cache first:
git rm --cached .secrets
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. .secrets
Your local .secrets file should only contain development credentials (localhost database, mock API keys). Production secrets should require a VPN or a vault token to access.
When a Node.js or Python app crashes, it often creates a core dump or a heap snapshot. These memory dumps contain the exact string values of your .secrets file. If a crash report is sent to a third-party service (Sentry, Bugsnag), your secrets go with it. This is the most important step
GitHub automatically scans public repos for secret formats. But it won't catch a custom .secrets file. You need custom patterns.
Use gitleaks detect --source=. --no-git or trufflehog filesystem . to automatically classify found secrets. Pro Tip: If you already committed a
The .secrets file is a simple, low-tech solution to a high-stakes problem. By establishing a clear boundary between configuration and credentials, you reduce the risk of accidentally exposing your production data.
Start today: Check your projects for hardcoded strings, move them into a .secrets file, and breathe easier knowing your keys are safe.
Have a specific tool or extension named .secrets that you wanted to know about? Let me know in the comments!
| Pitfall | Fix |
|---------|-----|
| Accidentally committing secrets | Use git‑filter‑repo or BFG Repo‑Cleaner to purge them from history. Add a pre‑commit hook that aborts if a file matching *.secret* is staged. |
| Storing secrets in logs | Never log process.env.* or config(...) values. Scrub logs or use a logger that masks known secret keys. |
| Hard‑coding secrets in code | Move any literal "my‑super‑secret" from source files into the .secrets file and reference via environment variables. |
| Leaving default credentials in containers | In Dockerfiles, avoid ENV DB_PASSWORD=123. Instead, use ENV DB_PASSWORD= (empty) and inject at runtime. |
| Relying on a single secret file for all environments | Separate files like .secrets.dev, .secrets.prod and load the appropriate one based on NODE_ENV, DJANGO_SETTINGS_MODULE, etc. |