Vault

HashiCorp Vault, honestly reviewed. What it actually does, what the license change means for self-hosters, and who should actually run it.

TL;DR

• What it is: A centralized secrets management platform — stores, generates, encrypts, and controls access to credentials, API keys, database passwords, TLS certificates, and more [1][2].
• Who it’s for: Engineering teams and DevOps engineers managing infrastructure secrets at scale. Not a password manager for individuals. Not a “non-technical founder spins it up in a weekend” tool [1][2].
• License reality: HashiCorp changed Vault’s license from the open-source Mozilla Public License (MPL 2.0) to the Business Source License (BSL 1.1) in August 2023. Self-hosting for internal use is still free. Building a competing hosted service with it is not. This is no longer OSI-certified open source.
• Key strength: Dynamic secrets — Vault generates short-lived, auto-expiring credentials on demand for AWS, databases, and more. An application asks for a database password, gets one that expires in an hour, and Vault revokes it automatically [1][2]. No other self-hosted tool does this as cleanly.
• Key weakness: Setup complexity and operational overhead. Production Vault requires an unseal process, HA configuration, backup strategy, and policy management. It’s a piece of infrastructure that needs its own ops attention. If you forget to configure auto-unseal, a server reboot locks everyone out [1][2].
• Cost savings: Compared to AWS Secrets Manager ($0.40/secret/month + $0.05 per 10K API calls) or Doppler ($24–$60/mo for teams), self-hosted Vault on a $10/mo VPS costs nothing in software licensing for internal use — but the operational cost is real.

---

What is Vault

Vault is a secrets management platform built by HashiCorp. It answers a specific problem: modern applications access dozens of sensitive credentials — database passwords, AWS keypairs, Stripe keys, internal service tokens — and those secrets tend to spread across environment files, CI/CD configs, engineers’ laptops, and Slack threads. Vault replaces that sprawl with a single, audited, access-controlled store.

The README defines it plainly: “a tool for securely accessing secrets.” That undersells it. Vault doesn’t just store secrets — it generates them on demand, rotates them automatically, encrypts arbitrary data without storing it, and maintains a complete audit log of every read, write, and access attempt [1].

The product has 35,227 GitHub stars and is backed by HashiCorp, now a subsidiary of IBM following the 2024 acquisition. It’s mature infrastructure software — first released in 2015, now deeply embedded in how enterprise DevOps teams manage credentials.

The license situation requires attention. In August 2023, HashiCorp switched Vault from MPL 2.0 (a genuine open-source license) to the Business Source License 1.1. Under BSL 1.1, you can self-host Vault freely for your own internal operations. You cannot build a competing commercial hosted service. Four years after each release, the code converts back to MPL 2.0. This is not OSI-certified open source, and it matters for anyone who planned to embed Vault in a product they sell. The community responded by forking Vault as OpenBao under the Linux Foundation, which continues development under MPL 2.0. If the licensing restriction concerns you, OpenBao is the answer.

---

Why people choose it

The reviews and guides we synthesized land in the same place: Vault wins on security architecture depth and dynamic credential generation, and loses on complexity and operational overhead.

The core problem it solves. Both the Medium [1] and dev.to [2] guides open with the same scenario: credentials scattered across codebases, developers sharing passwords over chat, no audit trail of who accessed what. Vault centralizes everything. As one guide puts it: “You’ve got passwords and API keys scattered throughout your code.” [2] Vault doesn’t just lock these down — it tells you exactly who read what, when, from which IP.

Dynamic secrets change the security model. This is the feature that makes Vault different from “a secure key-value store.” When your application needs to read from a PostgreSQL database, instead of storing a long-lived password in an env file, Vault creates a temporary database user with the right permissions, hands the credentials to your application, and revokes them when the lease expires [1]. The attacker who exfiltrates your database credentials gets credentials that are already dead. No other self-hosted tool in this category does this as a first-class feature.

Transit encryption without storing data. Vault can encrypt and decrypt arbitrary data without ever storing it — “encryption as a service.” A development team stores encrypted user records in their own database. Vault handles the encryption logic, key management, and key rotation without having to hold the plaintext [1]. This is meaningful for compliance scenarios where you need to prove you controlled who could decrypt data.

Seal/unseal is the operational gotcha everyone hits. Vault uses Shamir’s Secret Sharing to distribute the unseal key — by default, 5 key shares where any 3 can reconstruct the master key. This means no single person can unlock the vault unilaterally, which is a real security property [2]. It also means that when your server reboots, Vault starts sealed and locked until someone manually unseals it. The production fix is auto-unseal using AWS KMS, Azure Key Vault, or GCP Cloud KMS — which requires additional cloud configuration. First-time deployers who skip this step get paged at 3am [2].

GetApp reviewers confirm enterprise value. Among the 9 reviews on GetApp (4.8/5 overall), one reviewer with 2+ years of production experience describes their use as covering “setup a Vault solution and storage and consume between system and user, integrate with clouds for OIDC SSO.” [5] The rating for ease of use is 4.7/5 — high for a product this complex, which probably reflects self-selection: the people reviewing it are engineers who chose it deliberately.

---

Features

Core secrets engines:

• Key/Value Secrets Engine — stores arbitrary key/value pairs, fully encrypted at rest. Supports versioning so you can roll back to previous secret values [1][website].
• Dynamic Secrets — generates on-demand, time-limited credentials for AWS, Azure, GCP, databases (MySQL, PostgreSQL, MongoDB, Oracle, MSSQL), SSH, and more. Credentials auto-expire and are auto-revoked [1][2].
• Database Secrets Engine — manages database credential lifecycle: creates users, rotates passwords, revokes on expiry. Works across MySQL, PostgreSQL, MongoDB, Oracle, MSSQL [1][website].
• Transit Secrets Engine — encryption as a service. Encrypt/decrypt data without Vault storing it. Handles key rotation transparently [1][website].
• Transform Secrets Engine — Enterprise-only. Tokenizes highly sensitive data (credit card numbers, SSNs) into cryptographically safe tokens [website].
• PKI Secrets Engine — generates TLS certificates on demand. Useful for internal service mesh mTLS and certificate rotation.
• SSH Secrets Engine — generates signed SSH certificates or one-time passwords for server access.

Authentication methods: Vault supports a wide authentication surface: username/password, GitHub tokens, AWS IAM, Azure AD, GCP service accounts, Kubernetes service accounts, LDAP, Active Directory, OIDC, and more [2][5]. The intent is that every service authenticates with its native identity — a Kubernetes pod uses its service account, an AWS Lambda uses its IAM role.

Access control: Policy-based permissions. Operators write policies in HCL that grant specific paths specific operations. Every access is logged to the audit log [1][2].

Leasing and revocation: Every secret has a TTL. Vault can revoke a single secret, all secrets from a specific user, or all secrets of a specific type. Useful for key rolling after a suspected compromise [1][README].

Enterprise / HCP features (commercial-gated): DR replication, performance replication, namespaces, Sentinel policies, HSM support, automated snapshots, and the Transform secrets engine are Enterprise-only [5][website]. The self-hosted community edition is full-featured for most teams; Enterprise is aimed at large organizations with compliance requirements.

---

Pricing: SaaS vs self-hosted math

Vault self-hosted (Community Edition):

• Software license: $0 for internal use (BSL 1.1)
• Infrastructure: $10–20/mo VPS (needs at least 2GB RAM, preferably 4GB for production)
• Operational cost: someone has to maintain it — patches, backups, unsealing, policy management

Vault Enterprise (self-managed):

• Commercial pricing, requires contacting HashiCorp/IBM sales. The GetApp listing shows a starting price of $1.00/month, but this almost certainly reflects minimum per-user or per-node pricing that scales significantly [5]. Enterprise is not for solo founders.

HCP Vault Dedicated:

• HashiCorp’s managed cloud version. You don’t manage the infrastructure; they run Vault clusters for you. Pricing is not publicly listed — contact sales. This is the “I want Vault without the ops” option.

HCP Secrets:

• Multi-tenant secrets storage, simpler than full Vault. More like Doppler than full Vault. Listed pricing starts free with usage-based scaling.

Comparison against alternatives:

Option	Monthly cost	Dynamic secrets	Audit log	Managed ops
Vault self-hosted	~$10–20 VPS	Yes	Yes	No — you run it
AWS Secrets Manager	$0.40/secret + API calls	Yes (for AWS)	Via CloudTrail	Yes — fully managed
Doppler (Teams)	$24–60/mo	No	Yes	Yes — SaaS
Infisical (cloud)	$0–18/mo/user	No	Yes	Yes — SaaS

For a team that’s already paying $40–100/mo for a managed secrets service and wants to self-host, the math works. For a team that has never managed a secrets backend before, the managed-vs-self-hosted comparison needs to include the engineer-hours cost of operating Vault, which is real and ongoing.

---

Deployment reality check

Vault’s deployment is not a Docker Compose + done situation. It’s closer to running a database — something you deploy, configure carefully, and continue to operate.

What you need:

• A Linux server with at least 2GB RAM (4GB for production with multiple auth methods active)
• A storage backend: Consul, Integrated Raft (built-in, recommended for new deployments), or external databases
• TLS certificates — Vault requires HTTPS in production and will refuse to run without it
• An unseal strategy — either manual Shamir shares or auto-unseal using a cloud KMS
• A backup strategy — the encrypted storage needs to be backed up, and restoring Vault from backup requires the unseal keys
• A policy design — you’ll need to write policies before Vault is useful

What the guides say about setup: The Medium guide [1] walks through installation on macOS, Linux, and Windows, then covers development mode (single-node, in-memory, no persistence — fine for testing, not for production). The dev.to guide [2] explicitly recommends: “Start small and test in development first; implement backup and version control procedures; plan access control strategically; use auto-unseal in production environments.”

The unseal gotcha in production: Every Vault restart — whether from a server reboot, a crash, or a Docker restart — begins in sealed mode. Until unsealed, no secrets can be read or written. In development mode, Vault auto-unseals with a root token. In production, you either distribute unseal keys to multiple operators (requires manual coordination on restart) or configure auto-unseal with a cloud KMS. The cloud KMS approach is the right answer but adds an external dependency. If AWS KMS goes down, your Vault cluster won’t unseal [2].

The audit log is non-optional: Vault’s audit log records every operation — what was requested, who requested it, when. This is one of its major selling points. But audit logs need to go somewhere persistent (file, syslog, or a socket), and if the audit log backend becomes unavailable, Vault stops responding to requests. That’s intentional — “fail secure” — but it means your audit logging infrastructure has to be as reliable as Vault itself [1].

Realistic time for a DevOps engineer who’s done this before: 2–4 hours for a working production-ready single-node deployment. For HA (highly available) production Vault with Raft integrated storage: half a day to a full day. For a non-technical founder who’s never managed infrastructure: this requires hiring someone, not following a tutorial.

---

Pros and cons

Pros

• Dynamic secrets are a genuine security upgrade. Credentials that expire automatically, that are created on demand, that are revoked when the lease ends — this is a fundamentally better security model than storing long-lived passwords anywhere [1][2].
• Encryption as a service. Transit engine lets teams encrypt data without designing their own cryptography, with key rotation handled transparently [1][website].
• Comprehensive audit trail. Every secret access is logged. For regulated industries, this matters [1][5].
• Wide authentication support. Kubernetes, AWS IAM, Azure AD, LDAP, GitHub — if your services have identities, Vault can authenticate them natively [2][5].
• 35,000+ GitHub stars, 10 years of production use. Not a new tool making promises. Used at scale across enterprise infrastructure [merged profile].
• GetApp reviewers rate it 4.8/5. The engineers who’ve deployed it and live with it are largely satisfied [5].
• Revocation is first-class. Single secret, all secrets from a user, or all secrets of a type — revocation is granular and built in [1][README].

Cons

• License is no longer open source. BSL 1.1 means internal self-hosting is free, but commercial redistribution is not. This is a real change from the MPL 2.0 era. If this matters to you, use OpenBao [merged profile context].
• Operational complexity is high. Vault requires ongoing attention — unseal management, storage backend maintenance, policy updates, version upgrades. It’s not “deploy and forget” [1][2].
• Unsealing is a production risk if you don’t configure auto-unseal from day one. A rebooted server becomes a locked-out team until someone runs through the unseal ceremony [2].
• Enterprise features are commercial-only. DR replication, namespaces, Sentinel policies, Transform engine — all gated. Community edition is solid but missing features that larger teams need [5][website].
• Not a developer-experience tool. There’s a UI, but it’s an operator console, not something a developer or non-technical user interacts with daily. Vault is infrastructure, not an app [1][2].
• No dynamic secrets for most SaaS APIs. Dynamic secrets work for AWS, GCP, Azure, and major databases. For Stripe, Twilio, or other SaaS APIs, you’re back to storing static secrets with manual rotation [1].
• HCP Vault pricing is opaque. If you want managed Vault, you have to contact sales. No self-serve pricing page [website].

---

Who should use this / who shouldn’t

Use Vault if:

• You’re an engineering team running infrastructure — Kubernetes clusters, cloud workloads, multiple databases — and you need a central, auditable secrets store with dynamic credential generation.
• You work in a regulated industry (healthcare, finance, legal) where audit trails and access controls on secrets are a compliance requirement.
• You have a DevOps engineer or platform team who can operate it and keep it running.
• You want encryption-as-a-service without rolling your own key management.
• The BSL license terms (internal use, no competing hosted service) fit your use case.

Use OpenBao instead if:

• You want all of Vault’s capabilities under a genuine open-source license (MPL 2.0). OpenBao is the community-maintained fork, compatible with Vault’s API surface.

Use Infisical or Doppler instead if:

• You want developer-friendly secrets management — environment variables, secret syncing to CI/CD, team sharing — without the infrastructure complexity. These are SaaS-first tools with a much gentler onboarding curve.

Use AWS Secrets Manager / Azure Key Vault instead if:

• Your infrastructure already lives in a single cloud provider. Native integration is simpler than running and operating your own Vault cluster.

Skip it (you don’t need it) if:

• You’re a solo founder managing a handful of API keys. A well-configured .env with restricted file permissions and a secrets manager like 1Password or Bitwarden for team sharing is proportionate. Vault is infrastructure for infrastructure problems.
• You have no one who can operate it. A misconfigured or neglected Vault cluster is worse than not running one.
• You’re building a consumer app, not managing servers. Vault is a backend infrastructure tool, not an application feature.

---

Alternatives worth considering

• OpenBao — Community fork of Vault under MPL 2.0, maintained by the Linux Foundation. API-compatible with Vault. The right choice if the BSL license is a dealbreaker.
• Infisical — MIT-licensed, developer-focused secrets management. Syncs to CI/CD, has a clean web UI, supports dynamic secrets for databases (newer feature). Much simpler to operate than Vault. A strong choice for teams who want Vault-like functionality without the operational weight.
• Doppler — SaaS-only secrets management. No self-hosting. Clean DX, integrates with everything, not free for teams ($7/user/month+). Zero ops overhead.
• AWS Secrets Manager — Managed, deeply integrated with AWS IAM and Lambda. If you’re AWS-native, this is often the path of least resistance. Costs money per secret and per API call.
• Bitwarden Secrets Manager — Open-source, self-hostable, targeted at developer credentials. Simpler than Vault, no dynamic secrets. Good for small teams who want open-source credential storage without infrastructure complexity.
• SOPS + age/GPG — Not a server, just encrypted files checked into version control. No audit log, no dynamic secrets, no access control — but also no server to operate. Appropriate for very small teams with low compliance requirements.

---

Bottom line

Vault is the right answer to a specific problem: centralized, audited, policy-controlled secrets management across complex infrastructure, with dynamic credential generation as the headline feature. If you’re running Kubernetes workloads, multiple databases, and cloud accounts, and you need to know exactly who accessed which credential when, Vault solves that problem better than anything else you can self-host.

But it comes with real costs: operational complexity, the BSL license change, and an enterprise feature tier that gates replication and advanced policies behind a sales call. The 2023 license change means it’s no longer truly open source — OpenBao is the fork that maintained the MPL 2.0 commitment if that matters. For teams without a platform engineer or DevOps capacity, Infisical or Doppler will get you 80% of the value with 20% of the ops burden. For teams already embedded in AWS, Secrets Manager is the simpler path. Vault is for teams who have the engineering capacity to operate it and the scale to justify it — which is exactly the audience that already runs it and rates it 4.8/5 [5].

If you’re a founder who’s heard “you should use Vault” and wants someone to deploy and configure it so you don’t have to think about it, that’s precisely the kind of one-time infrastructure setup upready.dev handles.

---

Sources

1. William Warley, Medium — “How to with Hashicorp Vault, a comprehensive guide” (May 23, 2024). https://medium.com/@williamwarley/how-to-with-hashicorp-vault-a-comprehensive-guide-1e15c0afb37e
2. Haripriya Veluchamy, dev.to — “HashiCorp Vault: Your Friendly Guide to Secret Management” (April 22, 2025). https://dev.to/techwithhari/hashicorp-vault-your-friendly-guide-to-secret-management-4p74
3. GetApp NZ — “Vault Reviews, Pricing & Ratings” (9 verified reviews, 4.8/5). https://www.getapp.co.nz/software/133735/vault

Primary sources:

• GitHub repository: https://github.com/hashicorp/vault (35,227 stars, BSL 1.1 license)
• Official documentation: https://developer.hashicorp.com/vault/docs
• Official website: https://www.vaultproject.io
• Feature overview: https://developer.hashicorp.com/vault