Skip to main content

Self-Hosted Vault Recovery

What matters most​

If you run Dralvia with a self-hosted Vault, keep the unseal shares and root token off-host and keep a separate inventory of the secrets you expect to restore.

A root token alone does not unseal a Shamir-sealed Vault.

If the unseal shares are gone​

If the Vault is sealed and the required unseal shares are unavailable, the existing Vault cannot be reopened. The practical recovery path is to initialize a replacement Vault and reseed it from the secret material that still exists outside Vault.

In Dralvia deployments that usually means:

  • rendered service secret files
  • deployment env files
  • any external system of record you keep for operator credentials

What usually recovers cleanly​

Core platform wiring such as database passwords, Redis credentials, service admin passwords, and app client secrets can usually be restored if they are still present in rendered service secret files or deployment env files.

What often needs manual follow-up​

Short-lived or user-authorized credentials may need to be re-entered or re-authorized after a Vault rebuild. Expect that for some social, OAuth, and operator-scoped tokens unless you store them in a separate recovery inventory.

Operator guidance​

  • Do not rely on host disk state as the only copy of Vault recovery material.
  • Keep recovery inventory outside the application host.
  • After any Vault rebuild, rotate or reissue AppRole credentials and verify every dependent service can still render its secret templates.