Disclosure: No affiliate or sponsored relationship is active for Vaultwarden or Bitwarden. Links below go to official sources.
What is Vaultwarden?
On this page
- What is Vaultwarden?
- What evidence did we observe, and what remains unobserved?
- What belongs in the human vault and what belongs in the runtime manager?
- What must an operator own before deploying Vaultwarden?
- Who should evaluate official Bitwarden instead?
- How should an operator approach a Vaultwarden update?
- What should a recovery check establish?
- Does this review establish a self-hosting price?
- Should you choose the self-hosted path?
Vaultwarden is an unofficial Bitwarden-compatible server written in Rust, according to the official Vaultwarden repository. The word "unofficial" matters when you decide who will own the system and where you expect help to come from. It does not settle whether Vaultwarden fits your environment.
The project maintains an official Vaultwarden wiki for installation and administration documentation. That documentation, rather than this review, is the place to find project instructions. We do not reproduce commands because the evidence available for this review does not establish a universal installation or update procedure.
Bitwarden documents its official self-hosting path separately in the Bitwarden self-hosting FAQ. That distinction gives operators two different paths to evaluate. It does not support a comparison about security, features, service quality, or any other area that we did not test.
This is an operator review. It explains the job we assign to Vaultwarden, the deployment state we observed, and the responsibilities a team must accept before it self-hosts. It does not rank password managers or answer which product is the "best."
What evidence did we observe, and what remains unobserved?
The fleet evidence is one read-only check with a limited meaning. On 2026-10-09, two Vaultwarden deployment processes were observed on AI Jungle's fleet server, one healthy and one running, each with three months of process uptime.
We use the label Fleet-tested only for that observation. The check establishes the states reported at the time of inspection and the process uptime shown then. It does not turn process state into evidence for any property outside that check.
The observation did not test or establish:
- security, compliance, or breach history;
- encryption, retention, or SSO behavior;
- availability or performance;
- price, operating costs, or savings;
- support quality;
- backup correctness or recovery success;
- an installation or update procedure;
- a completed migration; or
- the official Bitwarden server or service.
Official Bitwarden remains not tested by us. The fleet check also does not show what happened before the recorded process uptime or what happened after the inspection. Its value is modest but real: it records what was running and the two distinct states we saw. Our public conclusion stays within that limit.
What belongs in the human vault and what belongs in the runtime manager?
We classify a credential by its consumer. Vaultwarden is for a credential that a person enters or needs to retrieve for recovery. The separate runtime secret manager is for a secret consumed by a service while that service runs.
| Decision question | Human vault | Separate runtime secret manager |
|---|---|---|
| Does a person enter or retrieve the credential? | Yes | No |
| Does a person need the credential for recovery? | Yes | No |
| Does a service consume the secret at runtime? | No | Yes |
| Does either system replace the other in our model? | No | No |
This division is about responsibility, not a product comparison. A human-entered credential does not become a runtime secret because a service exists nearby. A runtime secret does not belong in the human vault merely because an operator can copy it there. The intended consumer decides the side.
Before classifying an item, ask:
- Will a person enter or retrieve it?
- Is human recovery the reason it needs to be available?
- Will a service consume it at runtime?
- Would this placement blur the documented boundary between the two systems?
The answers give the item one destination under our model. Public copy does not need the names or contents of credentials to explain this rule. The boundary is useful precisely because an operator can apply it without exposing those details.
For wider context on how we think about operated open-source systems, see our articles about an open-source AI agent platform and private AI. Those articles do not add evidence to this Vaultwarden review.
What must an operator own before deploying Vaultwarden?
Self-hosting creates work that needs named owners. A team should settle those responsibilities before the vault becomes part of its operating environment. The checklist is cautious because our fleet observation does not validate anyone else's setup.
Confirm the following before choosing the self-hosted path:
- Name the person or team that owns installation and administration.
- Assign ownership of HTTPS and access control.
- Assign ownership of updates and the checks around them.
- Define what counts as a backup under your own process.
- Name the person or team that performs recovery tests.
- Define what evidence will show that a recovery test succeeded.
- Document the boundary between human credentials and runtime secrets.
- Decide whether the organization requires official support.
This list is not a deployment sequence. It does not say how to configure any component. The project wiki is the source for installation and administration documentation, while each operator remains responsible for the choices made in its environment.
An owner on paper is not enough if nobody can answer the related question. For example, assigning recovery to a team does not show that recovery succeeded. The team still needs its own definition of success and its own evidence. We make no claim that our read-only process check answered those questions. It did not.
The same caution applies to HTTPS and access control. They must have owners before you choose self-hosting, but this review does not prescribe their configuration. That would require operational facts and procedures beyond the evidence available for this review.
Who should evaluate official Bitwarden instead?
Organizations that require official support should evaluate the official Bitwarden server. The Vaultwarden repository recommends that path for organizations with that requirement.
Official Bitwarden is also the path to evaluate when an organization wants Bitwarden's officially documented self-hosting option. The Bitwarden self-hosting FAQ documents official self-hosting separately from Vaultwarden.
That guidance is deliberately limited. We did not test official Bitwarden, and we do not compare the two options on security, compliance, availability, performance, price, savings, or support quality. The official-support requirement alone is enough to direct an organization toward an evaluation without inventing a broader product verdict.
The operating model matters too. If nobody owns updates, backups, recovery tests, HTTPS, or access control, the team is not ready to choose the self-hosted path. Evaluating an officially supported server or service is then the appropriate next decision. This statement does not claim that official operation removes those responsibilities. It only follows the choice presented by the project repository and the ownership test in this review.
How should an operator approach a Vaultwarden update?
Start with the current Vaultwarden wiki, which the project provides as installation and administration documentation. Do not treat a command copied from this review as a universal update method. We provide no such command.
For an update, frame the work as checks that your own process must answer:
- Identify who owns the update.
- Confirm that your own backup requirement has been met.
- Confirm that your own recovery-test requirement has been met.
- Account for HTTPS and access control under their named owners.
- Define the expected deployment state that you will inspect after the change.
These checks do not claim that an update will succeed. They keep the change tied to explicit ownership and to evidence chosen by the operator. Our observed process states do not prove an update procedure.
What should a recovery check establish?
A recovery check needs a definition of success set by the operator. Ask what evidence will show that the recovery worked, who will review that evidence, and whether the restored result preserves the division between human credentials and runtime secrets.
Do not substitute a running process for recovery proof. Process state says nothing about backup contents or the result of a recovery test. This review did not inspect either one. It also does not provide a backup format, schedule, retention rule, or recovery sequence.
The practical question is whether the responsible operator can state what will be checked after recovery without exposing sensitive operational details. If that answer is missing, recovery ownership is not yet clear enough for the self-hosting decision.
Does this review establish a self-hosting price?
No. The evidence available for this review contains no price, cost comparison, or savings calculation. We therefore do not estimate the price of self-hosting Vaultwarden or Bitwarden.
The Bitwarden self-hosting FAQ establishes only that Bitwarden documents official self-hosting separately for the purpose of this review. We do not use it to make a pricing claim. Operators who need a price decision must gather evidence that is outside the scope of this article.
Should you choose the self-hosted path?
Choose self-hosting only if you own updates, backups, recovery tests, HTTPS, and access control. Make the human-vault and runtime-secret boundary explicit as part of that decision.
If those responsibilities lack clear owners, evaluate the officially supported server or service instead. If official support is a requirement, follow the Vaultwarden project's recommendation and evaluate the official Bitwarden server. That option remains not tested by us, so this article makes no broader comparison.
The decision is not a vote for one tool to handle every kind of secret. It is a choice about whether your team can operate a human credential vault while keeping runtime secrets in a separate system.
Written by Loïc Guyon (Tileo), who runs the AI Jungle fleet these tools are tested on.