Skip to main content
Historical evidence (2026-09-24, v0.39.7): Passwords with Vaultwarden was available, lifecycle-verified. A lifecycle run on Ubuntu 24.04 amd64 (Basement Kit, standalone) passed install, init, generate, apply, setup-vault, verify, backup, isolated restore and restore activation. The service-secret and Bitcoin extensions below are planned: target design only, with no release and no committed date.
Vault keeps passwords, machine secrets and Bitcoin roles under separate owner control. Today it ships one experience, Passwords, on Vaultwarden. The extensions on this page are planned directions, not something you can select yet.

​
Passwords, today

Passwords

Vaultwarden and Bitwarden clients: released contract, owner setup and client enrollment.
See the Passwords page and the Vaultwarden application page to select and set up the released password-vault experience.

​
Install the password vault

This recipe covers the released Vaultwarden alternative in an existing, verified standalone Basement or Cloud workspace. It does not install any of the planned extensions below. The current application recovery evidence is more limited than the historical v0.39.7 result above.
  1. In the existing stack-spec.yaml, select vault in workloads, with alternative: vaultwarden and runtimeAdapterRef: standalone-compose. Set its secretRefs.admin-token to the opaque reference secret://workloads/vault/admin-token. Keep the site’s existing storage and placement. Follow the selection structure in Configure a StackSpec.
  2. Validate the selection and establish custody for its admin-token reference before generating. The released stackkit secrets materialize creates or reuses the local owner-bound secret without printing it. Run stackkit validate, then stackkit secrets materialize, then stackkit generate and stackkit plan --json in that order. Stop on a validation, custody or readiness error. Never put the token in the StackSpec or replace invalid or foreign custody to make a plan pass.
  3. Review the plan’s vault placement and persistent data, then run stackkit apply followed by stackkit verify --http --json.
  4. Open the generated Passwords address and complete Vaultwarden first use. Set the registration policy, invite one person, then use an official Bitwarden client to register, sign in, create and sync one test entry. An invitation alone is not a working vault.
Keep recovery material outside the server. Follow Back up and restore and verify client sign-in and entry sync after recovery before relying on the vault for secrets you cannot recreate.

​
Planned extensions

None of the experiences below are selectable yet. They are design proposals for a broader Vault & Sovereignty umbrella, and existing Vaultwarden users will not receive a Bitcoin node or a new credential broker merely because Vault expands.

Service secrets

Grant applications limited machine credentials, kept separate from human passwords and owner custody. OpenBao is the first candidate under evaluation; Infisical is a comparison candidate.

Bitcoin node and verification

Validate and inspect Bitcoin using your own node. Bitcoin Core, with an explicit pruned or full-data mode. No funds custody.

Explorer

Private indexed queries and a familiar explorer view, on a full-data node plus electrs and mempool.

Payments

Receive invoice payments without moving signing authority onto the server. BTCPay Server with a watch-only or external-signing wallet configuration.

Portfolio (read-only)

Inspect selected multi-asset records privately with rotki, using read-only sources only.

Lightning

Deferred until recovery and custody are specifically designed; not a reward for finishing Bitcoin onboarding.

​
Security principles behind the design

  • Separate trust domains. A password client, a service-secret grant, a Bitcoin node’s blockchain data, and an external signer’s keys are four different things. The design keeps them on separate credentials and does not put them in one generic secrets bundle.
  • No hot keys on the server. The proposed Bitcoin paths keep signing keys on an external signer, outside StackKits and any workflow history or agent context. Nothing asks you to type a seed phrase into onboarding, a chat, or a support ticket.
  • Watch-only data is still sensitive. Descriptors, extended public keys, addresses and invoice records can reveal financial activity even though they do not confer spending authority, and the design treats them accordingly.
  • Recovery is not one generic snapshot. A password vault, a service-secret engine, a blockchain index and a hardware signer each need a different recovery treatment; rebuildable public chain data is not treated the same as owner-controlled private metadata.

​
Choose the host

  • Use Basement Kit for local hardware and LAN-first access.
  • Use Cloud Kit for an existing VPS or cloud host with a domain you control.