Skip to content

Reference

Scope

Look-up facts for HashiCorp Vault: releases and support windows, editions, auth methods, secrets engines, storage and seal options, token types, key configuration parameters, ports, metrics, sizing, and a hardening checklist. For how the pieces work, see Explanation. For step-by-step tasks, see How-to Guides.

Release and Support Matrix

Release dates come from the upstream CHANGELOG.md and the Vault 2.x release notes. Checked 2026-09-25.

Line GA Latest patch (date) Community (CE) patches Enterprise support
2.1.x 2026-09-01 2.1.1 (2026-09-16) Yes (current line) IBM Support Cycle-2
2.0.x 2026-04-14 2.0.4 (2026-08-04) Ended when 2.1 shipped IBM Support Cycle-2
1.21.x 2025-10-22 1.21.11 Ent (2026-09-16) Last CE patch 1.21.4 (2026-03-05) Standard maintenance
1.20.x 2025-06-25 1.20.16 Ent (2026-09-16) Last CE patch 1.20.4 (2025-09-24) Standard maintenance
1.19.x (LTS) 2025-03-05 Enterprise only Ended LTS, extended maintenance to Apr 2027
1.16.x (LTS) Apr 2024 Enterprise only Ended LTS, extended maintenance ended Apr 2026

Community Edition patch policy

The changelog shows that CE patch releases stop once the next minor or major line ships. Later patches on the older line are Enterprise-only (for example, 1.21.5 Enterprise onward). Community users must stay on the newest line to receive security fixes.

IBM Support Cycle-2 (Vault Enterprise 2.x onward)

From the April 2026 (2.x) release, Vault Enterprise follows IBM Support Cycle-2 ("2 + 1 + 3") instead of HashiCorp LTS (Vault Enterprise support).

Phase Duration New features Non-critical fixes Critical fixes Security patches Support cases
Base support 2 years Yes Yes Yes Yes Yes
Extended support 1 year No No Yes Limited Yes
Sustained support 3 years No No No No Yes

Editions and Offerings

Offering Delivery License Status (2026-09)
Vault Community Edition Self-managed binary, packages, container hashicorp/vault BSL 1.1 (Vault 1.15.0 and later) Active
Vault Enterprise Self-managed, license key (HashiCorp or IBM Passport Advantage since 2.0) Commercial Active
HCP Vault Dedicated Managed Vault Enterprise on AWS or Azure Commercial, pay-as-you-go or contract Active; tiers Development, Essentials, Standard
HCP Vault Dedicated Starter Managed Commercial Retired 2025-08-15
HCP Vault Secrets Managed SaaS secrets store (not Vault clusters) Commercial End of sale 2025-06-30; end of life by 2026-07-01

HCP Vault Dedicated Tiers

Source: HCP Vault Dedicated tiers and features.

Feature Development Essentials Standard
Nodes / SLA Single node, no SLA, 25-client limit HA, 99.9% SLA, Silver support HA, Gold support
Enterprise namespaces Yes Yes Yes
Audit log and metric streaming No Yes Yes
Cross-region disaster recovery No Yes Yes
Performance replication No No Yes
Secrets sync, secrets import No No Yes
Sentinel, control groups, ADP No No Yes
Root namespace access No No No (reserved for the platform)

Billing: an hourly cluster base cost plus, on Essentials and Standard, a per-client charge. Check the pricing page for current numbers.

Enterprise-Only Capabilities

Capability Purpose
Namespaces Multi-tenant isolation with delegated administration
DR replication Warm standby cluster with tokens and leases, promotable on failure
Performance replication Secondary clusters that serve reads locally and forward writes
Performance standby nodes Standbys in one cluster that serve read-only requests
Sentinel policies (EGP/RGP) Policy-as-code with conditional logic
Control groups Require one or more approvers before a request succeeds
HSM support, seal wrap, entropy augmentation, FIPS builds Hardware-backed keys and compliance
Seal HA More than one auto-unseal provider at once
Automated upgrades, redundancy zones Autopilot-driven upgrades and zone-aware voter placement
Lease count quotas Default global quota of max_leases = 300000 on new 1.16+ installs
Secrets sync, secrets import Push secrets to cloud secret managers; import from AWS SM or Azure KV
KMIP, Transform, Key Management engines Advanced Data Protection (ADP)
SCIM 2.0 provisioning (2.0), SPIFFE auth (1.21), PKI External CA (2.0) Identity and certificate automation
Agent registry and OAuth resource server ("Agentic IAM", GA in 2.1.0) Authorize AI agents with OAuth 2.0 JWTs and Rich Authorization Requests

Auth Methods

Method Default path Typical use
Token token/ Built in, cannot be disabled; root, service, and batch tokens
AppRole approle/ Machine-to-machine: role_id plus secret_id
Kubernetes kubernetes/ Pods log in with a ServiceAccount JWT; Vault validates it with the TokenReview API
JWT / OIDC jwt/, oidc/ Federated identity (Okta, Entra ID, Auth0, CI systems such as GitHub Actions OIDC)
LDAP ldap/ Corporate directory users and groups
TLS certificates cert/ Mutual TLS client certificates
Userpass userpass/ Username and password, mainly for operators and testing
GitHub github/ GitHub personal access tokens mapped to org and team
AWS / Azure / GCP aws/, azure/, gcp/ Cloud workload identity (IAM, managed identity, service accounts)
Kerberos, RADIUS, Okta, Cloud Foundry various Other identity sources
SAML, SPIFFE saml/, spiffe/ Enterprise only

Secrets Engines

Engine Type Description
KV v1 / KV v2 Static Key-value storage; v2 adds versions (default max_versions 10), check-and-set, and metadata under data/ and metadata/ paths
Cubbyhole Static Per-token private storage; used by response wrapping
Transit Encryption as a service Encrypt, decrypt, sign, HMAC, and data key generation; keys stay in Vault unless marked exportable
Database Dynamic Short-lived users for PostgreSQL, MySQL/MariaDB, MSSQL, Oracle, MongoDB, Snowflake, Redis and others; static roles rotate existing accounts
PKI Dynamic Root and intermediate CAs, issuance, CRL/OCSP, ACME; EST, SCEP, and CMPv2 in Enterprise
AWS / Azure / GCP Dynamic Cloud IAM credentials, STS tokens, service principals, service account keys
Kubernetes Dynamic ServiceAccount tokens and roles
LDAP (OpenLDAP / AD) Dynamic and static Rotate directory passwords, check out service accounts
SSH Dynamic Signed SSH certificates or one-time passwords
TOTP Dynamic Time-based one-time passwords
RabbitMQ, Consul, Nomad, HCP Terraform Dynamic Product-specific credentials
Identity Internal Entities, aliases, groups, OIDC identity tokens
KMIP, Transform, Key Management Enterprise (ADP) KMIP server, tokenization and format-preserving encryption, cloud KMS key lifecycle
Local accounts (OS), SPIFFE JWT-SVID, PKI External CA Enterprise (2.0) Rotate Linux local accounts, issue JWT-SVIDs, obtain certificates from public ACME CAs

Storage Backends

Backend HashiCorp support HA Notes
Integrated Storage (Raft) Yes, recommended Yes Available since Vault 1.4; BoltDB state machine; optional raft-wal log store (experimental)
Consul Yes Yes Recommended before 1.4; use a dedicated Consul cluster
Other external backends (PostgreSQL, DynamoDB, etcd, S3, and others) Limited or community support Varies Some support ha_enabled; extra network hop and extra system to run
Filesystem Yes No Single node only
In-memory Yes No Dev mode and tests; data lost on restart

Source: Storage configuration.

Seal Types

Seal Edition Mechanism
Shamir (default) All Unseal key split into shares; default -key-shares=5 -key-threshold=3
awskms All AWS KMS encrypts the root key
gcpckms All Google Cloud KMS
azurekeyvault All Azure Key Vault
ocikms, alicloudkms All Oracle Cloud KMS, Alibaba Cloud KMS
transit All Transit engine of another Vault cluster
pkcs11 Enterprise HSM through PKCS#11

Seal wrapping (extra encryption of critical values with the seal key) and Seal HA (several seals at once) require Vault Enterprise (Seal configuration).

With an auto-unseal seal, vault operator init returns recovery keys. Recovery keys authorize operations such as generate-root and rekey but cannot decrypt the root key (Seal concepts).

Token Types

Type Prefix Persisted Renewable Use case
Service hvs. Yes Yes Default for most logins
Periodic service hvs. Yes Yes, no max TTL while renewed Long-running services
Batch hvb. No (encrypted blob) No High-volume, short-lived work; lighter on storage
Recovery hvr. No No Recovery mode only
Root hvs. Yes Never expires Initial setup and break-glass only

Default system default_lease_ttl and max_lease_ttl are both 768h (32 days) unless tuned.

Key Server Configuration Parameters

Parameter Default Notes
api_addr none Address clients are redirected to; needed for HA
cluster_addr none Server-to-server address (port 8201)
disable_mlock Required with Integrated Storage (1.20+) Must be set explicitly with Raft; HashiCorp recommends true with Raft (see Explanation)
ui false Enables the web UI
enable_unauthenticated_access unset 2.0+: re-allows unauthenticated rekey, generate-root, generate-operation-token
listener "tcp" max_token_header_size 8 KB 2.0+: caps X-Vault-Token and Authorization: Bearer sizes; -1 disables
listener "tcp" tls_min_version tls12 Set tls13 where clients allow
listener "tcp" tls_disable false Never true outside dev
license_entitlement unset 2.0+: needed to use an IBM Passport Advantage license
default_lease_ttl, max_lease_ttl 768h Global lease TTLs

Ports

Port Purpose
8200/tcp API and UI (listener "tcp")
8201/tcp Cluster traffic: request forwarding, Raft replication, Enterprise replication

Metrics to Watch

Metric names come from the telemetry reference. With the Prometheus sink, dots become underscores.

Metric Type Why it matters
vault.core.unsealed Gauge 0 means the node is sealed
vault.core.active Gauge Which node is active
vault.core.handle_request, vault.core.handle_login_request Summary Request and login latency
vault.token.creation Counter Token creation rate by auth method
vault.expire.num_leases Gauge Lease growth (lease explosions degrade performance)
vault.expire.num_irrevocable_leases Gauge Leases Vault could not revoke
vault.audit.log_request_failure Counter Audit device failures (Vault blocks requests if no device can log)
vault.barrier.put, vault.barrier.get Summary Storage latency through the barrier
vault.autopilot.healthy Gauge Raft autopilot health
vault.runtime.alloc_bytes Gauge Memory usage

Hardware Sizing (Integrated Storage)

HashiCorp reference architecture for Vault with Integrated Storage (Raft reference architecture):

Size CPU Memory Disk Disk IOPS Disk throughput
Small (dev, test, staging) 2-4 cores 8-16 GB 100+ GB 3000+ 75+ MB/s
Large (production) 4-8 cores 32-64 GB 200+ GB 10000+ 250+ MB/s

Avoid burstable CPU and burstable IOPS cloud instances. Integrated Storage is disk-bound and optimized for SSDs.

Cluster Size and Fault Tolerance

Voting nodes Quorum Failures tolerated
1 1 0
3 2 1
5 3 2

HashiCorp recommends 3 or 5 voters (5 across 3 zones for production). Extra nodes beyond 5 add replication cost; Enterprise redundancy zones add non-voters instead.

Indicative Throughput (Unsourced)

Unsourced performance data

These numbers were estimated from vendor material, community benchmarks, and engineering judgment. They are not controlled benchmarks with recorded hardware, versions, or methodology. Run your own vault-benchmark tests before capacity planning.

Operation Single node 3-node HA (Raft) Notes
KV read 5,000-10,000 req/s 5,000-8,000 req/s CE standbys forward reads to the active node
KV write 2,000-5,000 req/s 1,500-3,000 req/s Raft consensus overhead
PKI sign 500-1,000 req/s 400-800 req/s CPU-bound
Transit encrypt 3,000-7,000 req/s 2,500-5,000 req/s AES-GCM
Token create 2,000-5,000 req/s 1,500-3,000 req/s Storage write
Dimension Guidance Notes
Active secrets 1M+ Storage-dependent
Mounts Hundreds to 1,000+ Large mount tables slow startup and unseal
Leases 300,000 default quota (Enterprise, 1.16+) CE has no default quota; monitor vault.expire.num_leases

Hardening Checklist

  • TLS on every listener, tls_min_version at least tls12; never tls_disable in production.
  • Auto-unseal with a cloud KMS or HSM; restrict the KMS key to Vault instances and log every decrypt call.
  • Unseal or recovery key shares held by separate people (PGP-encrypt them with -pgp-keys).
  • Root token revoked after bootstrap; regenerate with vault operator generate-root only for break-glass.
  • At least two audit devices (for example, file plus syslog or socket) shipping to a SIEM; log_raw=false.
  • Swap disabled on Vault hosts (required when disable_mlock = true, as recommended with Raft).
  • Vault runs as a non-root user; single-tenant hosts or dedicated nodes; no other workloads.
  • Least-privilege ACL policies; no sudo or * on sys/ paths for application roles.
  • Short token TTLs, token_bound_cidrs where possible, batch tokens for high-volume jobs.
  • Response wrapping (-wrap-ttl) for secret-zero delivery such as AppRole secret_id.
  • Raft snapshots taken on a schedule and restore tested.
  • Upgrade on the newest CE line, or an Enterprise line in base support.
  • Review 2.0 breaking changes before upgrading: authenticated sys/rekey and sys/generate-root, max_token_header_size, removed IPC_LOCK in official containers.

Vault and OpenBao at a Glance

Attribute HashiCorp Vault OpenBao
Latest version 2.1.1 (2026-09-16) 2.7.0 (2026-09-23)
License BSL 1.1 (converts to MPL 2.0 four years after each release) MPL 2.0
Owner / governance IBM (HashiCorp) Linux Foundation, OpenSSF sandbox project (since May 2025; previously LF Edge)
CLI / binary vault bao
Namespaces Enterprise Yes (since 2.3.1, API-compatible)
Replication Enterprise DR and performance replication Not available; horizontal read scaling on Raft and PostgreSQL (2.7)
Storage Raft, Consul, others Raft, PostgreSQL, PebbleDB (non-HA, 2.7)
Container image hashicorp/vault openbao/openbao (plus openbao-distroless since 2.6)

Sources