vault operator init: Initialize a New Vault
vault operator init initializes a fresh Vault, generating the unseal key shares and the initial root token.
init runs once in a Vault cluster lifetime. In ephemeral or test Vaults spun up for CI you may init on the fly, but production init is a guarded, one-time ceremony.
What it does
vault operator init initializes the storage backend and produces the unseal material. With Shamir (the default) it outputs -key-shares unseal keys of which -key-threshold are needed to unseal. With an auto-unseal seal (KMS, etc.) it outputs recovery keys instead. It also prints the initial root token.
Common usage
vault operator init -key-shares=5 -key-threshold=3
# machine-readable for automation (store these securely)
vault operator init -format=json -key-shares=1 -key-threshold=1 > init.jsonOptions
| Flag | What it does |
|---|---|
| -key-shares=<n> | Number of unseal key shares to generate |
| -key-threshold=<n> | Shares required to unseal |
| -recovery-shares / -recovery-threshold | Recovery key config for auto-unseal seals |
| -format=json | Emit keys and root token as JSON |
| -status | Report whether Vault is already initialized |
In CI
For a disposable Vault in an integration test, -key-shares=1 -key-threshold=1 keeps unseal trivial. Capturing init output as JSON lets the next step pull the unseal key and root token. Never do this with production-style shares; that pattern defeats the purpose of Shamir splitting.
Common errors in CI
"Vault is already initialized" means init ran before; it is idempotent-unsafe, so check vault operator init -status (exit 0 if initialized) first. "server is not yet running" or connection refused means VAULT_ADDR points at a Vault that has not started; wait for the listener. With auto-unseal, requesting -key-shares errors because Shamil shares do not apply; use recovery flags.