The usual objection to self-hosting a password manager is that it sounds reckless. Putting every credential your company owns on a box you administer yourself feels like the last thing a sensible person would do.
That instinct is aimed at the wrong risk. It is worth understanding why before you decide either way, because the real trade-off is not the one most articles argue about.
The part that changes, and the part that does not
In a Bitwarden-compatible password manager, your vault is encrypted on your device. The key is derived from your master password, which never leaves the client. What the server stores and syncs is ciphertext, and the server operator cannot read it.
That is true whether the operator is Bitwarden or you. So moving the server to your own infrastructure does not hand you the burden of keeping the contents secret - the contents were already opaque to the server. Someone who steals your database gets an encrypted blob and your master password's key derivation to fight.
What you do take on is availability. If your instance is down, nobody can sync. If your volume is gone and your backup was never tested, the vault is gone with it, and there is no support line that can restore it, because nobody else ever had the plaintext.
Self-hosting a password manager is therefore a backup problem wearing a security costume. Decide it on whether you will genuinely run backups, not on whether you trust yourself with secrets.
The licence detail nobody mentions
Here is something that does not appear in any of the comparison lists we read while writing this.
Bitwarden's server repository is not under a single open-source licence. It ships LICENSE_AGPL.txt and LICENSE_BITWARDEN.txt, alongside a bitwarden_license/ directory covered by the second one. Read from the repository on 17 August 2026, that directory contains these modules:
Commercial.Core · Commercial.Infrastructure.EntityFramework · Scim · Services · Sso
SSO and SCIM are in there. Which is to say: the two features an organisation is most likely to want when it self-hosts a password manager - single sign-on and automated user provisioning - are the ones outside the AGPL portion of the codebase.
This is not a scandal. It is a normal open-core arrangement and Bitwarden documents it. It is just worth knowing before you plan an architecture around self-hosting, because "Bitwarden is open source" is true of most of it and not of the parts an IT department reaches for first.
It also explains something that looks odd at first glance: Vaultwarden, an unofficial reimplementation of the Bitwarden server API, has 65.5k GitHub stars against the official server's 19.9k.
The options
Read from the projects themselves:
| Project | Stars | Licence | Notes |
|---|---|---|---|
| Vaultwarden | 65.5k | AGPL-3.0 | Rust reimplementation of the Bitwarden API; works with the official clients |
| KeePassXC | 28.4k | GPL family, no single SPDX identifier | A local database file, not a server |
| Bitwarden server | 19.9k | AGPL + Bitwarden Licence | Official; SSO and SCIM under the proprietary portion |
| Passbolt | 6.1k | AGPL-3.0 | Built for teams from the start, PHP |
| Psono | small on GitHub | source-available | Primary development is on GitLab, not GitHub |
Vaultwarden is the pragmatic answer for most people, and the one in our catalogue. It speaks the Bitwarden API, so the official desktop, mobile and browser clients work against it unmodified, and it runs as one small Rust binary instead of a multi-container deployment. If you want Bitwarden's clients without Bitwarden's server footprint, this is why it exists.
Passbolt is the better fit if sharing credentials across a team is the actual requirement rather than an afterthought. Its permission model was designed for that rather than grown into it.
KeePassXC deserves a mention because it solves the problem differently and often better for individuals: there is no server at all, just an encrypted file you sync however you already sync files. No server means no server to run, patch, or lose.
Bitwarden's own server is the right choice when you need SSO or SCIM and are prepared to license them, or when your organisation requires a vendor relationship.
What it actually costs to run
Our Vaultwarden stack is one container, vaultwarden/server pinned to 1.36.0, with a single data volume. That is the entire deployment.
The practical consequence is that a password manager is one of the cheapest things you can self-host. It sits beside everything else you already run rather than justifying its own machine, and on a flat plan starting at $5 a month it is not the line item that moves the bill.
Which brings the decision back to the thing that actually matters.
Get the backups right or do not do this
Everything above is easy. This is the part that is not, and it is the only part that can lose you the vault.
- Back up the data volume, not just the container. The container is disposable and rebuildable. The volume is the vault.
- Test a restore before you migrate anyone onto it. An untested backup is a belief, not a backup. Restore into a scratch instance and log in.
- Keep an offline export. Every Bitwarden-compatible client can export the vault. An encrypted export stored somewhere unrelated to your infrastructure is what saves you when the infrastructure is the thing that failed.
- Write down the recovery path for the person who is not you. If the only human who knows how to restore it is also the only human with the master password, you have built a single point of failure with a pulse.
None of this is exotic. It is the same discipline any stateful service needs. The difference is that with a password manager there is no vendor-side copy to fall back on, which is precisely the property you were looking for.
When not to self-host
Do not self-host if the honest answer to "who tests the restores?" is nobody. A hosted password manager with someone else's operational discipline beats a self-hosted one with none, and this is not a close call.
Do not self-host if you need SSO and SCIM and were counting on getting them for free - see the licence section.
Do not self-host if the motivation is cost alone. A password manager is rarely the largest line on anyone's bill, and it is a poor place to look for savings relative to what you take on.
Do self-host if the credentials must sit on infrastructure you control for compliance reasons, if you are already running and backing up other stateful services and this is one more, or if you want the reassurance of knowing exactly where the vault lives.
Frequently asked questions
Is it safe to self-host a password manager? The vault is encrypted client-side, so the server never holds plaintext and self-hosting does not expose the contents. The risk you take on is availability and backup discipline, not confidentiality.
Is Vaultwarden safe to use instead of official Bitwarden? It is an independent AGPL-3.0 reimplementation of the server API, not an official product, and it is widely used - 65.5k stars against the official server's 19.9k. The clients are unchanged, so the encryption model is the same. Evaluate it as you would any third-party server implementation, which means reading its release notes and keeping it updated.
Is Bitwarden fully open source?
Most of the server is AGPL, but the repository also carries a separate Bitwarden Licence covering the bitwarden_license/ directory, which includes the SSO and SCIM modules.
What do I need to run one? For Vaultwarden: one container and one persistent volume. The ongoing work is backups, not capacity.
Can I move my existing vault in? Yes. Every Bitwarden-compatible client exports and imports the vault, and Vaultwarden accepts the same format. Export from the old instance, import into the new one, verify a few entries by hand, and only then remove the old one.