HashiCorp Vault

Last reviewed Aug 26, 2026 · 812 words

HashiCorp Vault sits in the password managers category here because that is where people look for it, but it is not one. It stores secrets for machines: database credentials an app fetches at start, TLS certificates it issues on demand, API keys with a 1-hour lifetime. If you want to store your own logins, close this tab and read about Vaultwarden. If you have 5 or more services passing passwords around in .env files and want that to stop, keep going.

What a self-hoster actually keeps in it

Three things, in order of how often I see them at home. First, a key-value store (secret/ mounted as KV version 2) holding the Postgres passwords, SMTP credentials, and API tokens that scripts, Ansible playbooks, and CI jobs need. Second, the PKI engine acting as an internal certificate authority, so every service on the LAN gets a real short-lived certificate without touching Let's Encrypt. Third, dynamic database credentials: Vault creates a Postgres user with a 24-hour TTL when a service asks, and drops it when the lease ends, so no long-lived database password exists anywhere.

Those three are why the tool is the standard answer to AWS Secrets Manager on your own hardware. Encryption as a service (the transit engine) and detailed audit logs are bonuses you will appreciate later.

Dev mode lies to you

vault server -dev starts in seconds, stores everything in memory, is already unsealed, and prints a root token. It is superb for learning the CLI and useless for anything that must survive a restart. A real server needs a config file with a storage backend, and integrated Raft storage is the right choice for one node or three:

storage "raft" {
  path    = "/vault/data"
  node_id = "vault-1"
}
listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 1   # only behind a TLS-terminating proxy on a trusted network
}
api_addr     = "https://vault.example.com"
cluster_addr = "https://vault-1:8201"
ui           = true

Run vault operator init once. It returns 5 unseal key shares (3 needed by default) and a root token. Print the shares and put them somewhere that is not the Vault server. Then vault operator unseal three times, log in with the root token, and immediately create a less privileged admin policy so the root token can be revoked.

From then on, access is by policy. A service authenticates with AppRole (a role ID baked into its config plus a secret ID delivered at deploy time), receives a token limited to a policy that allows reading one path, and can do nothing else. Writing and reviewing those policies is most of the ongoing work, and it is the part that makes the whole exercise worthwhile: a compromised container can read its own secrets and no one else's.

The unseal problem is the operational cost

Every restart, whether from a kernel update or a power cut, leaves Vault sealed and every dependent service unable to fetch its secrets. Someone has to enter 3 key shares. That is by design, and at home it is a nuisance you must plan around. The options are auto-unseal against a cloud KMS (which reintroduces a cloud dependency), a small script that unseals from shares stored on a separate machine (which weakens the model but keeps things running), or accepting that after a reboot you spend 2 minutes on it. Pick one deliberately. The 256 MB memory figure is accurate for the server itself; the cost is in attention, not RAM.

The license changed, and the fork is worth knowing about

Since 2023 Vault ships under the Business Source License, which forbids offering it as a competing service and is not an OSI-approved open-source license. For a homelab that restriction changes nothing in practice, but it prompted the Linux Foundation to fork the last MPL release as OpenBao, which is API-compatible, accepts the same configuration, and is where a growing share of community energy went. If licensing matters to you, or you simply prefer the community-governed branch, start there; the knowledge transfers both ways. Infisical is the other candidate, with a friendlier web UI aimed at developer secrets rather than infrastructure automation.

What I'd do

If the goal is "stop keeping passwords in compose files", a homelab with fewer than 10 services is better served by Docker secrets or SOPS-encrypted env files; Vault's operational weight is not repaid. Past that point, or the moment you want an internal CA or dynamic database credentials, run a single-node Raft install of OpenBao (or Vault, if you have no licensing concern) on its own VM, with TLS from a real certificate, an unseal routine written down, and the init output on paper in a drawer. Human passwords still go in Vaultwarden.