Vaultwarden vs Bitwarden

Both of these put the exact same password vault on your own server, reachable from the same browser extensions and phone apps. So the real choice is not about features you can see day to day — it is about how much server you are willing to run to get them. On one side sits a single lightweight binary that boots in seconds; on the other, the official multi-service stack the Bitwarden company ships to enterprises. For most people self-hosting at home or for a small team, that difference decides it.

Same clients, two very different servers

The thing that makes this comparison unusual is that you never give up the clients. Vaultwarden is a from-scratch reimplementation of the Bitwarden server API written in Rust, and it speaks that API faithfully enough that every official Bitwarden app — the browser extension, the mobile apps, the desktop client, the CLI — connects to it unmodified. You point the same apps at your own domain and they cannot tell the difference. Your vault stays encrypted end to end either way, because encryption happens in the client, not on the server.

Official Bitwarden self-host is the real product the company runs, packaged for on-prem. It is a C#/.NET application backed by SQL Server, delivered as a fleet of Docker containers wired together by an installer script. That architecture is built to be supported, audited, and scaled inside a company — which is exactly why it asks for more of your machine than a personal vault needs.

Resources and setup effort

This is where the two pull apart hard, and it lines up with the spec table above. Vaultwarden is designed to run in as little as 256 MB of RAM and installs as one container — a single docker run with a data volume and your domain, and you are done. It earns the easiest difficulty rating here (1/5); the only real requirement is putting HTTPS in front of it, since passkeys and WebAuthn need TLS.

Official Bitwarden wants roughly 2 GB of RAM and pulls in the full multi-container stack plus a SQL Server database to babysit. Its installer asks for an installation ID and key and stands up several services at once, which is why it lands at 3/5 difficulty. None of that is hard in absolute terms — the script does the heavy lifting — but you are now maintaining a small constellation of containers and a heavier database for the same vault a 256 MB binary would hold.

A fresh, empty instance of each makes the gap concrete. Measured idle at first boot on a Docker box: Vaultwarden settles at ~7 MB, since it's one Rust binary with no separate database process (it defaults to embedded SQLite). Official Bitwarden's interactive installer stands up its full container fleet before you ever log in, so it isn't first-boot-measurable the same way — its own docs put the floor at 2 GB minimum, 4 GB recommended. Those are two different kinds of number (idle footprint vs. a documented requirement), but either way the order of magnitude doesn't change: Vaultwarden is the option that runs on hardware you'd otherwise call "too small."

Feature parity: what official Bitwarden has that Vaultwarden doesn't

Vaultwarden's own project README lists a "nearly complete" implementation of the Bitwarden client API — organizations, collections, attachments, Sends, groups, event logs, and policies are all in there, which covers what an individual or small team actually uses day to day. The real, documented gap is narrower than people assume:

If none of the bottom three rows apply to you, there's no feature gap to weigh — just a resource gap.

Security track record

Both have a real audit history, not just a marketing claim. Bitwarden's official server gets an annual third-party audit (Cure53, Insight Risk Consulting) that the company publishes. The code Vaultwarden runs is a separate, unofficial reimplementation and isn't covered by those audits — but it has had its own: independent researchers found and responsibly disclosed an admin-panel remote-code-execution flaw (GHSA-h6cc-rc6q-23j4), patched in version 1.33.0 (January 2025). Being audited and having a disclosed, patched CVE is a healthier signal than no audit history at all — but it does mean running Vaultwarden means keeping it current, the same as any other server software.

What you actually give up

Choosing the lightweight server is not free of trade-offs, so be honest about what the official build gives you:

• Vendor support — a paid support relationship with the company behind Bitwarden, which matters for organisations that need someone to call.
• Enterprise SSO and provisioning — SAML/OIDC login, directory sync, and the admin/compliance tooling built for larger deployments.
• Official-build assurance — some security and compliance policies require running the vendor's own server code, full stop.

Vaultwarden covers the features an individual or small team actually reaches for — organisations, collections, attachments, 2FA, passkeys, the admin page — and it does so on a fraction of the hardware. Both projects are open source under the AGPL-3.0, so neither locks you in; the difference is who stands behind the code and how much of it there is to run.

Which should you self-host?

Pick Vaultwarden if…

• You are self-hosting for yourself, a family, or a small team and want the lightest possible server — it runs happily in 256 MB on the cheapest VPS.
• You want to keep using the official Bitwarden apps but skip the multi-service stack and the SQL Server database behind them.
• One docker run behind a reverse proxy is your idea of an install, and low ongoing maintenance is the whole point.

Pick Bitwarden if…

• You need a vendor-supported deployment with a support contract behind it.
• Enterprise SSO, SCIM provisioning, and compliance tooling are hard requirements, not nice-to-haves.
• Policy dictates running the company's official server build rather than a community reimplementation, and the extra RAM is not a concern.

Who should pick neither

Both of these are personal-vault-first tools — a single vault a person or a small team logs into. If what you actually need is a password manager built from the ground up for team secret-sharing, with per-folder permissions and a server that only ever holds ciphertext (no decryption on the server, even in principle), look at Passbolt instead. It's built on OpenPGP specifically for that model, rather than adapting a personal vault to fit a team.

Choosing between Bitwarden and Vaultwarden

Flip the question around and it gets simpler: pick official Bitwarden first if a support contract, enterprise SSO, or a compliance policy already decided it for you — those are real, documented reasons a community reimplementation can't satisfy. Everyone else should default to Vaultwarden. It speaks the same client API, covers organizations, policies, attachments, and 2FA, and does it on hardware an order of magnitude smaller — measured at ~7 MB idle against Bitwarden's own documented 2–4 GB. Start with Vaultwarden and only reach for official Bitwarden when one of those three specific, enterprise-shaped reasons actually applies to you.

Running either on a VPS

Both run fine on a single small server, but the gap here is real rather than cosmetic: Vaultwarden will sit comfortably on the smallest box you can rent, while official Bitwarden wants several times the memory for its container stack and database. If you are watching cost or want the most headroom left over for other services, Vaultwarden is the easy call — and it is our pick for almost everyone self-hosting a personal or small-team vault. The step-by-step setups are linked below, and any of the VPS options here has plenty of room for the app plus its database; just remember to terminate TLS in front so passkeys work.