🔐 Vault Error: 'Vault is sealed' on Every Request

Exact Error Message

$ vault kv get secret/app/config
Error making API request.

URL: GET https://vault.example.com/v1/secret/data/app/config
Code: 503. Errors:

* Vault is sealed

From a raw API call you see the same condition as a JSON body:

$ curl -s https://vault.example.com/v1/sys/health | jq
{
  "initialized": true,
  "sealed": true,
  "standby": true,
  "server_time_utc": 1752883200,
  "version": "1.x.x"
}

What It Means

A sealed Vault holds its data encrypted at rest and does not have the encryption key in memory. On startup Vault knows where its storage is, but every secret in that storage is encrypted with a data encryption key that is itself encrypted by the root key. The root key is protected by the seal. Until the seal is opened, Vault can serve only a handful of sys/ endpoints — sys/health, sys/seal-status, sys/unseal, sys/init — and answers everything else with HTTP 503 and Vault is sealed.

This is a normal state, not corruption. Vault starts sealed by design every single time the process starts. With the default Shamir seal, an operator must supply enough key shares to reconstruct the unseal key, which decrypts the root key, which decrypts the data. With an auto-unseal seal (AWS KMS, GCP Cloud KMS, Azure Key Vault, or Vault Transit), the process asks the external KMS to decrypt the root key at startup and unseals itself without human input. If you are seeing this error unexpectedly, either a restart just happened on a Shamir cluster or your auto-unseal path is failing.

Common Causes

• The Vault process or host was restarted and nobody re-supplied the Shamir key shares.
• Fewer than the threshold number of unseal key shares have been submitted so far.
• An auto-unseal seal is configured but the node cannot reach or is not authorized to use the KMS key.
• A seal migration was started (Shamir to auto-unseal or the reverse) and left the cluster half-migrated.
• You unsealed one HA node but are talking to a different, still-sealed node through a load balancer.
• Vault sealed itself after a critical storage or replication failure, or an operator ran vault operator seal.

Diagnostic Commands

Check the seal state and, critically, how many shares have already been entered:

vault status

Query the same information without authentication, which works even when sealed:

curl -s https://vault.example.com/v1/sys/seal-status | jq

Ask a specific node directly rather than through the load balancer, so you know which member is sealed:

VAULT_ADDR=https://vault-node-1.internal:8200 vault status
VAULT_ADDR=https://vault-node-2.internal:8200 vault status

Look at the server logs for the reason the node is sealed or why auto-unseal failed:

journalctl -u vault -n 200 --no-pager | grep -iE "seal|unseal|kms|core:"

Confirm which seal type the configuration actually declares:

grep -A8 -E '^seal ' /etc/vault.d/vault.hcl

Step-by-Step Resolution

1. Read vault status before doing anything. The Unseal Progress field tells you how many of the required shares have been accepted, and Seal Type tells you whether a human is even supposed to be involved:

vault status
# Seal Type       shamir
# Initialized     true
# Sealed          true
# Total Shares    5
# Threshold       3
# Unseal Progress 0/3

2. For a Shamir seal, submit key shares until the threshold is met. Each share must come from a different key holder; run the command once per share:

vault operator unseal
# Unseal Key (will be hidden): <share 1>
vault operator unseal
# Unseal Key (will be hidden): <share 2>
vault operator unseal
# Unseal Key (will be hidden): <share 3>

3. Confirm the node is open and, on an HA cluster, note whether it came up active or standby. A standby node is unsealed and healthy — requests to it are forwarded or redirected, which is a different condition covered in Vault error: “Vault is in standby mode”:

vault status | grep -E "Sealed|HA Mode"

4. Repeat the unseal on every other cluster member. With a Shamir seal each node maintains its own seal state, so unsealing the active node does not unseal the standbys:

for host in vault-node-1 vault-node-2 vault-node-3; do
  VAULT_ADDR="https://${host}.internal:8200" vault status | grep -H Sealed
done

5. If the seal type is not shamir and the node is still sealed, the KMS call is failing. Check the seal stanza and the node’s credentials against the key. A typical AWS KMS seal looks like this:

seal "awskms" {
  region     = "us-east-1"
  kms_key_id = "arn:aws:kms:us-east-1:111122223333:key/abcd-1234"
}

The instance role must be allowed kms:Encrypt, kms:Decrypt, and kms:DescribeKey on that key ARN. The equivalent stanzas are seal "gcpckms", seal "azurekeyvault", and seal "transit" for unsealing against another Vault cluster.

6. To stop the manual unseal cycle for good, migrate from Shamir to auto-unseal. Add the new seal stanza to the configuration, restart, then unseal once with the -migrate flag on each node using the existing Shamir shares:

systemctl restart vault
vault operator unseal -migrate
vault operator unseal -migrate
vault operator unseal -migrate
vault status | grep -E "Seal Type|Sealed"

After migration, restarts unseal themselves. Keep the old Shamir shares — after migration they become the recovery keys, and you still need a threshold of them for operations like vault operator generate-root and rekeying. If unsealing succeeds but reads then fail with a 403, that is a policy problem rather than a seal problem; see Vault error: “permission denied” on a path.

Prevention

• Use auto-unseal (KMS or Transit) on every production cluster so a reboot never causes an outage.
• Distribute Shamir shares to distinct people or distinct secure stores, and verify the threshold is achievable on short notice.
• Alert on sys/health returning 503 with sealed: true, not just on the process being down.
• Run a periodic unseal drill so key holders confirm their shares still work before you need them.
• Give each node’s instance role explicit kms:Decrypt/Encrypt/DescribeKey on the seal key, and monitor for key policy drift.
• Configure the load balancer health check against sys/health so sealed nodes are removed from rotation automatically.

Related Errors

• Vault is in standby mode — the node is unsealed but not active; requests need forwarding or the active node.
• Vault is not initialized — storage is empty and vault operator init has never run; unsealing is not applicable yet.
• error checking seal status: connection refused — the process is not listening at all, a connectivity problem rather than a seal state.
• failed to unseal barrier: cipher: message authentication failed — a wrong or mismatched unseal key share was supplied.

Frequently Asked Questions

Why does Vault seal itself every time the server reboots? That is intentional. Vault never persists the root key in plaintext, so a restart always returns it to a sealed state. Only an auto-unseal seal backed by an external KMS removes the manual step.

Do I need all the key shares to unseal? No. You need the threshold, which is usually a subset — three of five is the common default. vault status prints both Total Shares and Threshold, and shares can be entered from different machines in any order.

Why is one node in my cluster still sealed after I unsealed the leader? With a Shamir seal, seal state is per-node. Each member needs its own unseal ceremony. With auto-unseal each node unseals independently at startup, which is the main operational reason to migrate.

Can I unseal from a script? You can pipe shares into vault operator unseal - or POST /v1/sys/unseal, but storing a threshold of shares where one script can read them defeats the purpose of Shamir — use a real auto-unseal seal instead. More seal and auth fixes are collected in the Vault guides.