Cloud Parts

HashiCorp Vault

A secrets server that can mint short-lived database and cloud credentials on demand, not just store passwords.

What it is
Secrets management
Type
Commercial product
Made by
HashiCorp, an IBM company
License
Business Source License 1.1 (source-available, not OSI open source); MPL 2.0 before the August 2023 change
Facts checked
5 October 2026
Website Source code

What it is

Vault is a server that apps talk to over an HTTP API. It starts sealed: everything it keeps is encrypted, and it can’t read its own data until it is unsealed, either by operators entering shares of a key split with Shamir’s Secret Sharing or automatically with a cloud KMS key. Data is written encrypted to a storage backend, usually its Integrated Storage, which replicates across the cluster’s nodes with Raft. A client logs in through an auth method (a Kubernetes service account, an AWS IAM role, OIDC, AppRole) and gets a token whose policies list the paths it may read or write.

What sets Vault apart is dynamic secrets. Instead of storing one shared database password, the database secrets engine creates a new PostgreSQL user for each request, with a lease such as one hour, and drops that user when the lease expires or is revoked. The same idea covers AWS credentials, and other engines issue TLS certificates (PKI) or encrypt data for apps without handing out the key (Transit). In August 2023 HashiCorp moved Vault from MPL 2.0 to the Business Source License 1.1, and IBM completed its purchase of HashiCorp in February 2025. OpenBao, a community fork of the last MPL-licensed code run by the Linux Foundation’s OpenSSF, keeps an open-source line with a Vault-compatible API.

Why teams pick it

  • Dynamic, leased credentials: every app instance gets its own database user that expires on its own
  • One identity-based system for secrets, certificates and encryption across clouds, Kubernetes and on-premises
  • Many auth methods, so workloads log in with an identity they already have instead of a stored password
  • Every request can be written to an audit log

Watch out for

  • Running it is real work: unsealing after restarts, a Raft cluster, backups and upgrades; if Vault is down, apps can’t fetch or renew their secrets
  • No longer OSI open source; OpenBao is the open-source alternative
  • Namespaces for multi-tenancy need Vault Enterprise or HCP Vault Dedicated
  • Apps must renew leases and handle rotated credentials, or you add Vault Agent or an operator to do it for them
  • Only protects secrets that are put into it; finding ones already leaked into code, wikis or chat is HCP Vault Radar, a separate paid service, and matching those leaks against Vault needs Vault Enterprise or HCP Vault Dedicated

Alternatives

What all secrets management have in common →
Cloudflare Secrets StoreBetaCommercialAccount-level secrets that are written once, can never be read back, and are bound by reference into any Worker or AI Gateway that needs them.DopplerCommercialA hosted secrets manager built for developers: one place for every app’s config and secrets per environment, injected with `doppler run` and synced out to clouds and CI.HCP Vault RadarCommercialA hosted scanner that finds leaked secrets and personal data in code, wikis, tickets and chat, checks which ones still work, and helps move them into Vault.

How it fits with other technologies

Hand out one-hour PostgreSQL users with the database secrets engine · bash

vault secrets enable database

vault write database/config/orders-db \
    plugin_name=postgresql-database-plugin \
    allowed_roles=app \
    connection_url="postgresql://{{username}}:{{password}}@db.internal:5432/orders" \
    username=vault password="$VAULT_DB_PASSWORD"

vault write database/roles/app db_name=orders-db default_ttl=1h max_ttl=24h \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";"

vault read database/creds/app   # a new username and password, leased for 1 hour

See it in a real stack

No architecture uses HashiCorp Vault yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2015–2026

By the mid-2010s a typical system needed a multitude of secrets: database credentials, API keys for outside services, credentials for services to talk to each other. HashiCorp co-founder Armon Dadgar later described what most companies had as “a sprawl of secret material”, spread across application source code, configuration management, config files and plain text. Knowing who read which secret was hard, and adding key rotation, secure storage and detailed audit logs was almost impossible without building your own tool.

HashiCorp started Vault to be one central place for secrets, with encryption, access control and auditing. Mitchell Hashimoto announced it on April 28, 2015. The idea that set it apart was dynamic secrets: rather than storing a long-lived database password, Vault creates a fresh credential for each client, with a lease, and revokes it when the lease ends. If one application instance is compromised, only its own credential needs revoking.

Vault reached 1.0 in December 2018, the result of nearly four years of work. In 2023 HashiCorp moved it to the Business Source License, and the community forked the last open-source version as OpenBao, now run by the Linux Foundation’s OpenSSF. In April 2026, with HashiCorp part of IBM, Vault 2.0 became its first new major version since 1.0.

Why it’s built this way

Generate credentials on demand instead of storing them
A credential that exists for an hour and belongs to one client is worth little if it leaks, and can be revoked on its own. This “moving attack surface” was the main reason to build Vault rather than an encrypted password store.
Every secret has a lease
Clients must renew leases, so Vault always knows who is still using what, can refuse a renewal, and can revoke a single secret or everything one user ever read.
Treat the storage backend as untrusted
Vault encrypts everything before it leaves the process, so whoever can read the disk or database underneath still sees only ciphertext. Storage only has to be durable, not trusted.
Seal the master key with Shamir’s Secret Sharing
The key that decrypts everything is split into shares held by different people, and a threshold of them (three by default) must come together to unseal Vault, so no single person can decrypt the data.

Timeline

  1. 2015

    Announced by HashiCorp in April, with dynamic secrets from day one

  2. 2018

    Vault 1.0 in December; cloud auto-unseal becomes open source

  3. 2023

    Moves to the Business Source License; the community forks it as OpenBao

  4. 2025

    IBM completes its acquisition of HashiCorp

  5. 2026

    Vault 2.0 released in April, adopting IBM’s support lifecycle

Sources22 · facts checked 5 October 2026

Improve this page on GitHub