Skip to main content
Vault’s storage backend determines where and how your data is persisted. Open source users can choose from a variety of backends—such as S3 or DynamoDB on AWS, Azure Blob Storage on Azure, etc.—and should consider high availability (HA) requirements. Enterprise Vault clusters are supported on HashiCorp Consul or Integrated Storage (Raft). Introduced in Vault 1.4, Integrated Storage now (as of Vault 1.7) offers feature parity with Consul, including cloud auto-join, automated backups, and autopilot. Other community-supported backends (etcd, MySQL, PostgreSQL) suit non-Enterprise deployments.

​
Supported Storage Backends

Vault 1.7 provides a broad selection of backends for any environment:
BackendEditionTypical Use Case
ConsulOpen Source & Ent.HA clusters with mature ecosystem
Integrated Storage (Raft)Open Source & Ent.Built-in HA, auto-join, backups
S3Open SourceSimple scalable object storage
DynamoDBOpen SourceKey/value store with single-region HA
Azure Blob StorageOpen SourceBlob-based storage on Microsoft Azure
Google Cloud StorageOpen SourceObject storage on GCP
etcd, MySQL, PostgreSQLCommunityCustom database deployments
In-Memory (dev mode)Open SourceTesting and non-production
The image lists various storage backend options, divided into two columns, with a note indicating they are updated based on Vault 1.7.

​
Storage Backend Architecture

A Vault cluster consists of one active node and one or more standbys, all sharing a single storage backend. Every node reads from and writes to the same data store. If you deploy multiple clusters for geographic redundancy, each cluster uses its own backend. Enterprise-level replication is handled between Vault nodes via the Vault API—not directly between storage backends.
The image illustrates a diagram of two Vault clusters, each with multiple Vault nodes connected to a single storage backend, with replication between the clusters. It emphasizes that there is only one storage backend per Vault cluster.

​
Choosing a Storage Backend

When evaluating storage backends, consider:
  • Production vs. non-production environments
  • HA requirements (single-node vs. multi-node)
  • Whether Enterprise support and features are needed
Use this decision flow to match your requirements with the right backend. For simple testing or CI, in-memory dev mode may suffice. For critical production data, choose a robust HA backend like Consul or Raft.
The image is a flowchart for choosing a storage backend, with decision points for production use, high availability support, and HashiCorp support, leading to various storage options like In-Memory, Filesystem, and others.

​
Configuring Your Storage Backend

Define your storage backend inside the storage stanza of your Vault HCL configuration file.

​
Example: Consul

storage "consul" {
  address = "127.0.0.1:8500"                     # Consul agent endpoint
  path    = "vault/"                             # KV namespace for Vault data
  token   = "1a2b3c4d-1234-abcd-1234-1a2b3c4d5e6a"  # Consul ACL token
}
  • address: Host and port of the Consul agent
  • path: Prefix within Consul’s key/value store
  • token: ACL token granting Vault access

​
Example: Integrated Storage (Raft)

storage "raft" {
  path     = "/opt/vault/data"                   # Local directory for Raft logs and snapshots
  node_id  = "node-a-us-east-1.example.com"      # Unique identifier for this node

  retry_join {
    auto_join = "provider=aws region=us-east-1 tag_key=vault tag_value=us-east-1"
  }
}
  • path: Filesystem path for replicated data
  • node_id: Identifier used by Raft to address each node
  • retry_join.auto_join: Uses AWS EC2 tags to discover and join peers automatically
Do not commit configuration files containing plain-text tokens or credentials to version control. Use environment variables or a secure secrets manager to inject sensitive data.
For detailed configurations and advanced options, see the Vault Storage Backends documentation.

Watch Video