HashiCorp Vault for the rest of usWhen to use it. When to skip it.

Everyone eventually gets told to "just use Vault." The advice is not wrong. Vault is, in fact, the most complete secret management system available, and if your threat model includes credential sprawl at scale, audit requirements, or multi-cloud identity federation, it belongs on your shortlist.

But "most complete" and "right for you" are different things. Vault is a distributed system with a non-trivial unseal ceremony, a license that changed in August 2023, and operational requirements that surprise teams who installed it on a Friday afternoon expecting a secrets API.

This is the assessment nobody wrote when you first heard the recommendation.

What to know in 60 seconds

• Vault's dynamic secrets feature is genuinely unmatched. Short-lived, automatically revoked DB credentials are a real category improvement over static passwords.
• The rest of Vault (transit engine, audit log, identity-aware auth) is also good and also overkill for most solo stacks.
• HashiCorp Vault switched to the Business Source License (BUSL 1.1) in August 2023. Production use by a competing service provider requires a commercial license. Most solo teams are unaffected, but you should read the terms rather than assume.
• OpenBao is the community fork started in late 2023 after the BUSL switch. It is API-compatible, actively maintained, and licensed under MPL 2.0. If the license concerns you, that is where to look.
• Running Vault correctly means running at least three nodes for HA, managing an unseal key set, and having someone available when Vault seals itself after a crash. That someone is often you, at 2am.

What Vault gets right

Dynamic secrets change the game

The best argument for Vault is the database secrets engine. Instead of creating a Postgres user with a static password and pasting it into sixteen .env files, you configure Vault with a root DB credential and let it generate short-lived credentials per request. A cron job gets a username and password that expire in 15 minutes. If the cron job is compromised, the window for lateral movement is the TTL, not until someone notices and manually rotates.

This is a real security property. It eliminates credential sprawl at the source rather than trying to clean it up later. GitGuardian's 2026 State of Secrets Sprawl found that AI-assisted commits leak credentials at twice the baseline rate. Dynamic credentials mean the thing that leaks expires before a bot can use it.

The Vault database secrets engine supports Postgres, MySQL, MongoDB, Oracle, and several others. The auth methods that generate those credentials (AppRole, Kubernetes, AWS IAM) are well-documented and production-tested.

Lease-based revocation is underrated

Every credential Vault issues has a lease. You can revoke a lease at any time. If you discover that a particular service account was compromised, you do not need to know which credentials it had. You revoke the entity, and every lease associated with it disappears.

This matters for AI coding agents specifically. An agent session that spawned credentials via Vault is easy to clean up: revoke the token the agent used, and every downstream secret it touched is gone. Compare that to the alternative, where the agent inherited four long-lived env vars and you have no log of what it did with them.

Transit engine and audit log

Vault's transit secrets engine is a hardware security module in software. Your application encrypts and decrypts through an API call rather than holding the key. The key lives in Vault's encrypted storage, and your application code never sees it.

The audit log is HMAC-chained, append-only, and logs every operation with the requesting entity's identity. "Did anything touch the production DB credential between 3pm and 4pm?" is a three-second query rather than a week of log archaeology.

These are good features. They are also features you need a running Vault cluster to use.

What Vault costs you

The unseal ceremony is not optional

When a Vault server starts or restarts, it begins in a sealed state. It cannot read secrets or serve requests until unsealed. You unseal it by providing enough key shares to reconstruct the master key (default: 3 of 5 Shamir shares, or a cloud KMS auto-unseal with a paid service).

Auto-unseal with AWS KMS, GCP KMS, or Azure Key Vault removes the manual ceremony, but adds a dependency: if the KMS is unreachable when Vault restarts, Vault stays sealed. You've traded one failure mode for another.

For a solo project or a small team with no on-call rotation, a sealed Vault at 2am is a production incident that requires a human who knows where the key shares are.

HA math is unfavorable for small teams

A single-node Vault is a reliability risk. If it crashes, everything that depends on Vault cannot authenticate until you bring it back. The standard answer is a three-node Raft cluster with automatic leader election.

Three nodes means three machines to patch, three certificates to rotate, three storage volumes to monitor. It means your secret management system is now a distributed database that requires the same operational attention as the services it protects.

For a team of three engineers focused on shipping product, the carrying cost of a self-hosted HA Vault cluster is significant. Managed Vault via HCP Vault drops the cluster maintenance, but starts at around $0.03 per client request, which adds up quickly under any meaningful load, and requires a HashiCorp account in your trust chain.

The license changed, and you should read it

HashiCorp's BUSL 1.1 switch in August 2023 restricts use of Vault in products that compete with HashiCorp's own offerings. Most internal infrastructure tools do not compete with HashiCorp. A SaaS product that sells "managed Vault" does.

The ambiguity lives in the edges: if you build a developer platform that includes secret management as a feature, you may need a commercial license. The terms are worth 20 minutes of your time before you build on Vault.

OpenBao, the MPL 2.0 fork maintained by the Linux Foundation, removes the license question entirely. It tracks Vault's API closely and has active contributors from several organizations that migrated after the BUSL switch. The operational complexity is identical to self-hosted Vault.

Vault is great. You probably don't need it.

Here is the gap the recommendation glosses over: Vault is designed for teams that have an infrastructure engineer, or at least a senior DevOps person on call. Solo devs and small product teams rarely have that.

The value proposition is real but assumes operational capacity that most small teams have allocated elsewhere. The unseal ceremony, the HA cluster, the BUSL licensing analysis, the auth method configuration for each of your services: each of those is a project in itself.

More importantly, Vault does not solve the secret-zero problem. Every service that wants credentials from Vault needs a way to authenticate to Vault first. That initial credential (an AppRole secret-id, a Kubernetes service account token, an IAM role binding) still has to come from somewhere. If it ends up in a .env file or an environment variable that your AI coding agent inherits, Vault added complexity without closing the original gap.

The February 2026 Knostic disclosure about Claude Code's settings.local.json capturing environment variables is instructive here. A team running Vault would still have the Vault token in their shell environment. The agent would still capture it. The credentials the token could generate are shorter-lived, which helps, but the auth token itself is not.

Vault is a sledgehammer for a population of problems. If you have those problems, use the sledgehammer. The clearest signal that you need Vault is database credential rotation at scale: many services, many DB users, short TTLs, automated revocation. That is Vault's strongest argument and the case where the operational cost pays for itself fastest.

If your problem is "I have an OpenAI key and a Stripe key and I don't want them leaking," Vault is the wrong tool. An encrypted local store that scopes secrets to individual processes at runtime does the same job with none of the cluster overhead.

Decide with a checklist

## Do I actually need Vault?

- [ ] I have multiple services that each need separate DB credentials
- [ ] I need those credentials to expire automatically (TTL < 1 hour)
- [ ] I need to revoke all credentials for a compromised entity instantly
- [ ] I have someone who will manage the Vault cluster (or budget for HCP Vault)
- [ ] I have read the BUSL 1.1 terms and confirmed my use case is in scope
- [ ] I have a plan for the unseal ceremony after unexpected restarts
- [ ] My team can absorb 3-5 hours/week of Vault cluster maintenance

If < 3 boxes are checked: you do not need Vault yet.
If 3-5 boxes: consider HCP Vault or OpenBao before self-hosting.
If 6-7 boxes: self-hosted Vault is probably the right call.

What this means for your stack

Most solo teams and small product teams need secret management that is simpler than Vault but more rigorous than env vars in .zshrc. The category is a local credential store that holds secrets in an encrypted vault, injects them into specific processes at exec time, and keeps an audit log of every grant. The agent session (or the cron job, or the CI runner) gets the value for the duration of that process and nothing longer. No cluster to babysit. No unseal ceremony at 2am.

hasp is one working implementation. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, hand the next session a reference instead of a key. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

The principle applies regardless of what you run: keep secrets out of long-lived environment variables, scope access to individual process invocations, and maintain an append-only log of who touched what. Vault enforces those properties at enterprise scale. For most small teams, a lighter tool enforcing the same properties is enough.