# What is unsealing a vault?

> Unsealing gives a secrets server the key it needs to decrypt its own storage after a start. How Shamir shares and auto-unseal work, and what it means to run.

URL: https://crunu.com/learn/vault-unseal
Language: en
Updated: 2026-10-30

Unsealing is the step in which a secrets server that decrypts data itself, such as HashiCorp Vault or OpenBao, receives or reconstructs the key that protects its storage, so that after starting up it can decrypt and serve secrets again; until then it is sealed and can do almost nothing.

## How it works in Vault

HashiCorp's description: a Vault server "starts in a sealed state", in which it "can access the physical storage, but it cannot decrypt any of the data on it." Unsealing "is the process of obtaining the plaintext root key that is necessary to read the decryption key" ([HashiCorp](https://developer.hashicorp.com/vault/docs/concepts/seal)). Before that, the only possible operations are unsealing and checking status.

There are two ways to provide the key:

- **Shamir's secret sharing**, the default. The key is split into shares, and "Vault requires a certain threshold of shares to reconstruct the unseal key." Operators type in their shares one at a time.
- **Auto-unseal.** Vault "delegates the responsibility of securing the unseal key from users to a trusted device or service", a cloud [KMS](https://crunu.com/learn/kms) or an [HSM](https://crunu.com/learn/hsm). At startup Vault asks that service to decrypt the root key.

A node stays unsealed until something reseals it, and a server restart is one of those things. With Shamir and several nodes, each node needs the threshold of shares.

*Figure: Diagram of who can decrypt HashiCorp Vault values, split into your side and the provider side. On your side, your team’s devices, your machines, and CI runners can decrypt. On the provider side, the HashiCorp Vault server holds the key and can decrypt values too.*

## What it means for operators

- **Restarts need people or a dependency.** With Shamir, someone holding shares has to be available after every restart or crash. With auto-unseal, the vault depends on the KMS being reachable and the cloud credentials being valid.
- **Share holders are a team process.** Who holds shares, how they are stored, and what happens when a holder leaves.
- **The unsealed server holds the key in memory.** That is what lets it decrypt for clients, run dynamic secrets and sync values to other systems. It also means a compromise of the running server exposes the data.

## Common mistakes

- **All shares with one person,** or in one password manager vault, which turns a threshold scheme into a single key.
- **Auto-unseal with broad KMS access.** Whoever can use that KMS key can unseal the data.
- **No practiced restart.** The first time you need the shares shouldn't be during an outage.

## Why Crunu has nothing to unseal

The Crunu server never decrypts values, so it has no key to unseal. Values are encrypted on people's devices and in the `crunu` agent; the server stores ciphertext and environment keys sealed to each recipient's public key. A restarted server is immediately ready, without shares or a KMS.

The server does have one secret of its own, `SERVER_KEY`, which protects token HMACs, authenticator-app secrets and alert channel settings. Losing it signs everyone out and breaks share links, but environment data isn't lost. Keep it in a password manager, separate from database backups.

The trade-off is real: because the server can't read values, it can't offer server-side features such as dynamic secrets or syncing values to other platforms. Running each kind of vault is compared in [self-hosted secrets manager: options and trade-offs](https://crunu.com/guides/self-hosting-a-secrets-vault).

## Sources

- [HashiCorp Vault: Seal/Unseal](https://developer.hashicorp.com/vault/docs/concepts/seal), checked October 30, 2026.