Tooling

Secrets management tools for developers

• VersionDude
• Tooling
• 6 min read

API keys, tokens and .env files should never sit in plain text or in your git history. Here is how teams keep application secrets safe.

Application secrets — database passwords, API keys, signing tokens, OAuth credentials — are a recurring source of breaches, and the failures are usually mundane rather than sophisticated. The most common mistakes are hard-coding a secret directly in source, committing a .env file by accident, or pasting a credential into a chat message or ticket. The goal of secrets management is to keep these values encrypted, access-controlled, and firmly out of version control.

At the project level, the basics go a long way and cost almost nothing. Add .env to .gitignore from the very first commit, and commit a redacted .env.example that documents which variables exist without revealing their values. This gives new contributors a template to fill in while keeping real credentials off the server entirely. Establishing this convention early avoids the much harder job of scrubbing a leaked secret from history later.

Prevention is better than cleanup, and tooling can enforce it automatically. Tools like git-secrets or a pre-commit hook can scan staged changes and block a commit that looks like it contains a credential before it ever reaches the remote. Integrating such a check into CI as well means that even if a local hook is bypassed, the pipeline catches the mistake. Automated guardrails are far more reliable than asking every developer to remember every time.

• Keep .env out of git; commit a redacted .env.example instead
• Use git-secrets or a pre-commit hook to block accidental commits
• Rotate any leaked key immediately — deleting the commit is not enough
• Vault, AWS Secrets Manager or Infisical for runtime application secrets
• An encrypted password manager (e.g. Proton Pass) for personal credentials

When a key does leak, the only safe response is to rotate it, not to hope no one noticed. Rotate any key that has ever touched a public repository, a shared log, or an untrusted machine, and assume it is compromised the moment it is exposed. Deleting the offending commit is not enough, because copies and caches may already exist; issuing a new credential and revoking the old one is the action that actually closes the hole.

For teams and production systems, dedicated tools centralise secrets behind authentication and audit logging instead of scattering them across config files. HashiCorp Vault is a widely used option that stores secrets centrally and can issue short-lived, dynamic credentials on demand. Cloud-native services such as AWS Secrets Manager integrate tightly with a provider's identity system, and open-source projects like Infisical offer a self-hostable way to manage and inject secrets across environments.

The common thread among these tools is that applications fetch secrets at runtime rather than storing them on disk. Instead of a long-lived password baked into a config file, a service authenticates to the secrets store and receives the value it needs in memory, ideally for a limited time. This shrinks the window of exposure and makes rotation a configuration change rather than a deployment-wide scramble. It also gives you an audit trail of which service accessed which secret and when.

A frequent pitfall is over-engineering the solution for the scale of the problem. A solo developer with a handful of side projects does not need a clustered Vault deployment, and a large organisation should not be sharing secrets in a spreadsheet. Match the tooling to the team: environment files plus a pre-commit hook for small projects, a managed cloud secrets service or Vault as the team and compliance requirements grow.

For the personal secrets a developer accumulates — recovery codes, service logins, license keys, the occasional one-off token — an encrypted password manager is the right home rather than a plain-text notes file. Proton Pass, with its end-to-end encryption and secure-note support, keeps those values out of unprotected files and synced safely across your machines. It cleanly separates the credentials a human uses from the secrets an application consumes, which are two different problems with two different tools.

The overall takeaway is that secrets management is a layered discipline, not a single product. Keep secrets out of git, automate the checks that enforce it, rotate anything that leaks without hesitation, use a runtime secrets store for production, and use an encrypted manager for personal credentials. None of these steps is difficult in isolation; the security comes from applying them consistently rather than waiting for a breach to make the case for you.