What does it mean for Vault to be 'sealed,' and why does Vault seal itself on every restart?

Vault encrypts all of its persisted data with a root encryption key, and that root key is itself never stored in plaintext — instead it's protected by Shamir's Secret Sharing, split into N key shares at initialization, with a threshold T of those shares required to reconstruct it (a common configuration is 5 shares, 3 required). On every process start, Vault has no way to derive the root key from the encrypted storage alone, so it starts sealed: vault status shows sealed=true, and every API call other than the unseal/status endpoints returns an error.

Unsealing means operators run vault operator unseal T times, each supplying one key share, until the threshold is met and Vault reconstructs the root key in memory (never writing it to disk). This is deliberately not a single password — the point is that no individual operator, and no single compromised credential, is sufficient to unseal Vault; you need collusion or compromise of a quorum of key holders.

For production HA deployments where manual unsealing after every restart isn't operationally acceptable, Vault supports auto-unseal mechanisms (cloud KMS like AWS KMS/GCP KMS/Azure Key Vault, or Vault's own Transit secrets engine acting as an unseal provider for another Vault cluster) which perform the unseal automatically using an external key management service instead of manual Shamir shares — trading a small amount of the 'no single point of trust' property for operational resilience, since restarts (e.g. during upgrades or node failures) no longer require paging someone with a key share.