Tom Hundley
🤖 Ghostwritten by Claude Opus 4.6 · Fact-checked & edited by GPT 5.4
A secrets manager stores API keys, database passwords, and tokens in an encrypted vault and delivers them to applications when needed. For most teams and solo developers, that is safer than leaving credentials in .env files, notes apps, screenshots, chat threads, or copied config files across multiple machines. The practical benefit is simple: fewer places for secrets to leak, and a much faster recovery path if a key is exposed.
That said, a secrets manager is not a magic shield. If malware or a malicious dependency is already running on your machine, it may still be able to access secrets available to your current session. What a secrets manager does well is reduce long-lived plaintext sprawl, centralize access control, and make rotation manageable. For non-developers, side-project builders, and small teams, that is usually reason enough to adopt one.
TL;DR: Secrets managers reduce credential sprawl, which lowers the odds of accidental exposure and makes incident response much faster.
Most credential leaks are mundane. A .env file gets committed by mistake. A production token is pasted into Slack. A screenshot captures an API key. A contractor keeps an old copy of a config file on a laptop that is never wiped. None of these failures require a sophisticated attacker; they just require secrets to exist in too many places.
Centralizing secrets does not eliminate software supply-chain risk, phishing, or malware. It does, however, remove one of the most common failure modes: plaintext credentials scattered across disks, repos, and collaboration tools. In practice, that means fewer places to audit, fewer copies to forget about, and fewer keys to rotate by hand.
TL;DR: A secrets manager gives you a controlled source of truth for credentials and supplies them to apps without relying on ad hoc file storage.
A secrets manager typically does three jobs:
That last point matters more than it sounds. Security failures are often made worse by slow cleanup. If a token is leaked and it exists in six repos, three laptops, and two CI systems, rotation becomes a scavenger hunt. A secrets manager turns that into an inventory problem instead of a memory test.
Without a secrets manager, the pattern often looks like this:
.env fileWith a secrets manager, the goal is to keep the secret in one managed location and deliver it only where it is needed. That does not guarantee zero exposure, but it sharply reduces duplication and confusion.
TL;DR: 1Password, Doppler, and Infisical are approachable for individuals and small teams; HashiCorp Vault is better suited to more complex environments.
| Feature | 1Password | Doppler | Infisical | HashiCorp Vault |
|---|---|---|---|---|
| Best for | Individuals and small teams already using 1Password | Teams managing multiple app environments | Teams that prefer an open-source-first option | Larger or more complex infrastructure |
| Learning curve | Low | Low | Low to medium | High |
| CLI injection | op run |
doppler run |
infisical run |
Varies by workflow |
| Open source | No | No | Yes | Yes |
1Password's developer tooling lets users store secrets and inject them into local processes with the op CLI. For people already using 1Password, this can be the lowest-friction starting point because it extends an existing tool rather than adding a new platform.
Doppler is built specifically for application secrets and environment management. Its project-and-environment model is easy to understand, and doppler run is straightforward for local development workflows.
Infisical is an open-source option with hosted and self-hosted paths. It supports CLI-based workflows and is often attractive to teams that want more control over deployment and data residency.
Vault is powerful and widely used, but it is not the easiest place to start. It supports advanced patterns such as dynamic secrets, short-lived credentials, and detailed policy controls. Those features are valuable in larger systems, but they come with more operational overhead.
TL;DR: Choose one tool, migrate active secrets into it, update how apps receive them, then rotate anything that may already have leaked.
Start with the option that fits your current setup. If you already use 1Password, begin there. If you want a dedicated secrets platform, Doppler or Infisical may be a better fit. The first goal is not perfection; it is getting secrets out of scattered files.
Review your current storage locations:
.env and .env.* filesAdd only the secrets you still use. Stale credentials should be disabled or deleted rather than migrated blindly.
Many teams keep the application code the same and change only the delivery method. For example, code can still read process.env.STRIPE_KEY, while the value is supplied by a secrets tool instead of a local file.
## Examples of CLI-based injection
doppler run -- node server.js
op run -- node server.js
infisical run -- node server.jsThe exact workflow varies by platform. In hosted environments such as Vercel, Netlify, GitHub Actions, or cloud runtimes, the secrets manager may sync values into the platform's own environment variable system rather than wrapping a local command.
Delete obsolete local files where possible. If a secret was ever committed to Git, pasted into chat, or shared in a document, treat it as exposed and rotate it. Adding a file to .gitignore does not remove it from repository history, backups, or anyone else's clone.
TL;DR: An AI assistant can help you find likely secrets, but a human still needs to verify what is real, active, and safe to remove.
You can use an AI coding assistant to create a migration checklist. Keep the prompt focused on discovery, not on printing secret values back to you.
Audit this project for secrets, credentials, API keys, tokens, and other
sensitive configuration. Check:
- .env, .env.*, and .env.local files
- Hardcoded strings that look like credentials
- Config files such as config.js, settings.py, and application.yml
- Docker and compose files
- CI/CD workflow files
- Infrastructure templates
- README and docs that may contain real examples
For each finding, produce:
1. File path and line number
2. Variable or secret name
3. Likely service owner
4. Whether it appears to be a live value or a placeholder
5. Recommended action
Do not print full secret values in the output. Mask them.That last instruction matters. An audit prompt should reduce exposure, not create a fresh copy of every credential in a chat transcript.
No. If malicious code is already running with access to your session, it may still be able to read secrets available to that process. A secrets manager mainly reduces plaintext sprawl and improves control, auditing, and rotation.
Usually not. The setup cost is modest for modern tools, and the operational benefit is real even for one person. Solo developers are especially prone to copying secrets between laptops, side projects, and hosting dashboards.
Environment variables are one way to deliver configuration to an application. A secrets manager is the system that stores, controls, and often audits those values. They are complementary, not competing ideas.
No. .gitignore only prevents future commits. It does not erase repository history, forks, cached copies, or local clones. Rotate the affected secrets and then clean up the history if needed.
Yes. Many hosting platforms provide their own secret or environment-variable settings, and several secrets managers integrate with them. The right pattern depends on whether you want one central source of truth or platform-specific storage for each deployment target.
Secrets management is less about advanced security theory than about removing avoidable chaos. When credentials live in too many files, tools, and devices, small mistakes become expensive incidents. A good secrets manager will not solve every security problem, but it will give teams a cleaner operating model: one source of truth, fewer plaintext copies, and a faster path from exposure to recovery.
Discover more content: