Fix Vault 'Sealed' Status After Restart

The Symptom

After restarting Vault (or the underlying server), all API requests fail with:

Error making API request.

URL: GET https://vault.example.com/v1/sys/health
Code: 503. Errors:

* Vault is sealed

Running vault status confirms:

Sealed          true

All applications relying on Vault lose access to secrets until the instance is unsealed.

Root Cause

By design, Vault starts in a sealed state. When sealed, Vault has access to its encrypted storage backend but cannot decrypt anything because the master key is not loaded into memory. This is a deliberate security measure: if a server is compromised while powered off, the attacker cannot access secrets without the unseal keys.

After every restart, Vault must be unsealed by providing a threshold number of unseal key shares (Shamir's Secret Sharing) or by having auto-unseal configured.

Step-by-Step Fix

1. Manual unseal (immediate recovery)

You need to provide the required threshold of unseal keys. The default is 3 out of 5:

vault operator unseal <unseal-key-1>
vault operator unseal <unseal-key-2>
vault operator unseal <unseal-key-3>

Check the progress after each key:

vault status

The Unseal Progress field shows how many keys have been provided versus the threshold.

2. Verify Vault is operational

vault status
# Sealed should now be false

vault token lookup
# Should return token info without errors

3. Set up auto-unseal to prevent this in the future

Auto-unseal delegates the unseal process to a trusted external KMS. Here is an example using AWS KMS:

# vault.hcl
seal "awskms" {
  region     = "us-east-1"
  kms_key_id = "alias/vault-unseal-key"
}

For Azure Key Vault:

seal "azurekeyvault" {
  tenant_id  = "your-tenant-id"
  vault_name = "vault-unseal-kv"
  key_name   = "vault-unseal-key"
}

After adding the seal stanza, you must migrate from Shamir to auto-unseal:

vault operator unseal -migrate

4. If running in HA mode

In HA mode with integrated storage (Raft), all nodes start sealed. Unseal the leader first, then the followers:

# On the leader node
vault operator unseal <key>

# On each follower
vault operator unseal <key>

Check cluster status once all nodes are unsealed:

vault operator raft list-peers

5. Handle the "recovery keys" distinction

With auto-unseal, the original unseal keys become recovery keys. They can no longer unseal Vault manually but are used for operations like generating a root token:

vault operator generate-root -init

Prevention Tips

• Always configure auto-unseal for production. Manual unseal creates operational risk and delays recovery during outages.
• Store unseal/recovery keys securely. Use a separate, offline medium for each key share. Never store all shares in one location.
• Monitor seal status. Set up an alert on the /v1/sys/health endpoint. A 503 response indicates a sealed instance.
• Test restart recovery. Periodically restart a non-production Vault node to verify that auto-unseal works as expected and that your runbooks are current.
• Use Vault's built-in Raft snapshots. Schedule vault operator raft snapshot save to protect against storage corruption during unexpected shutdowns.