Vaultwarden

Vaultwarden is the Rust reimplementation of the Bitwarden server — a community-maintained open-source server that's API-compatible with the official Bitwarden clients (desktop, mobile, browser extensions), meaning you can self-host the credential vault on a $4/month VPS while using the polished commercial-grade Bitwarden client UX. Listed at Grade A because Vaultwarden occupies the self-host-without-the-bloat slot: a single Rust binary (lightweight, fast, minimal dependencies) that replaces Bitwarden's official server (.NET stack, heavier resource footprint), making self-host viable on cheap VPS hosting.

Background. Vaultwarden was created in 2018 by Daniel García (`dani-garcia`) originally under the name bitwarden_rs ("Bitwarden in Rust"). After legal-correspondence concerns from Bitwarden, Inc. about trademark confusion, the project was renamed to Vaultwarden in 2022 — preserving the same maintainer team and codebase, just disambiguated from the official Bitwarden product. Codebase at github.com/dani-garcia/vaultwarden. Open source under the AGPLv3 license. Hosting model: deploy as a single Docker container (recommended) or compile-and-run the Rust binary directly; SQLite or PostgreSQL for storage; ~50MB RAM footprint typical (vs ~1GB+ for the official Bitwarden server's .NET stack on Windows containers). The project is community-maintained — Daniel García + contributors; no commercial entity, no company behind Vaultwarden the way Bitwarden, Inc. is behind Bitwarden. The Bitwarden, Inc. team has been publicly cordial about the existence of Vaultwarden (it's a complementary deployment option, not a fork-and-compete) — both projects share the same end goal of letting users self-host if they choose.

What you trust. API-compatible with official Bitwarden clients — the same Bitwarden mobile app, desktop app, browser extension, and CLI work against a Vaultwarden server. You get the polished client UX + your own server backend. Same end-to-end encryption — Vaultwarden implements the same client-side encryption protocols as official Bitwarden; the server only ever sees ciphertext. Open-source Rust codebase — auditable; Rust's memory-safety properties mitigate a class of vulnerabilities that C/C++ servers are vulnerable to. Lightweight resource footprint — runs on a $4/month VPS, a Raspberry Pi, or alongside other services on shared hosting. No vendor lock-in — your vault is in a standard Bitwarden format; you can move between Vaultwarden ↔ official Bitwarden ↔ KeePassXC export format. What you don't trust: Vaultwarden is not an official Bitwarden, Inc. product — the maintenance is community-driven, not commercial. If you're an organisation with compliance requirements that mandate vendor support agreements, the official Bitwarden server is the right pick. Self-host operational responsibility — when you self-host, you own backups, TLS certificate renewal, security updates, OS hardening, monitoring. Lose your VPS, lose your vault (unless backed up properly). Audit history is less formal than Bitwarden's — Bitwarden, Inc. has commissioned formal Cure53 audits; Vaultwarden has been informally reviewed by the community but doesn't have the same audit-report pedigree.

Operational specs. Deployment: Docker container (canonical), Rust binary compile + run, Kubernetes Helm chart, Ansible playbooks (community-maintained). Storage: SQLite (default, simplest), PostgreSQL (for HA/multi-instance setups). Resource footprint: ~50-100 MB RAM, ~50 MB disk + database size. Client compatibility: all official Bitwarden clients work — desktop apps (macOS/Windows/Linux), mobile apps (iOS, Android), browser extensions (Firefox, Chrome, Safari, Edge, Brave), CLI client (`bw`). TLS termination: typically front Vaultwarden with nginx or Caddy for TLS; Vaultwarden listens on plain HTTP and trusts the reverse proxy to handle TLS. Features: all core Bitwarden features work (passwords, secure notes, identity, credit cards, file attachments where supported by client), shared collections, organisations, password sharing, emergency access, 2FA support (TOTP, FIDO2/WebAuthn). Updates: Daniel + contributors track Bitwarden's protocol updates; typical lag is 1-4 weeks behind major Bitwarden client releases. Admin panel: Vaultwarden has an admin web UI for user management, separate from the user-facing Bitwarden client. Email: optional — for password reset notifications, 2FA email; SMTP-based, you provide your own email server or use a transactional provider.

Philosophy. Vaultwarden's editorial differentiator is the self-host-with-official-client-compatibility model. The choice between official Bitwarden hosted and Vaultwarden self-hosted is structurally a trust-source decision: with hosted Bitwarden, you trust Bitwarden, Inc. as the operator; with Vaultwarden, you trust yourself as the operator (and Vaultwarden's community-maintained server code). Both have the same client UX, same encryption story, same end-to-end zero-knowledge architecture. The trade-off: self-host operational overhead (backups, TLS, updates, monitoring) vs paying ~$10/year and letting Bitwarden, Inc. handle infrastructure. For users who want zero recurring cost + zero vendor lock-in + complete control over the storage layer, Vaultwarden is the canonical pick. For users who don't want to operate a server, hosted Bitwarden is the right pick.

Grade rationale. Grade A reflects: open-source AGPLv3 codebase (Rust); 7+ years of operational continuity (since 2018 as bitwarden_rs, renamed 2022); API-compatible with official Bitwarden clients (no client-side compromise); lightweight resource footprint (~50 MB RAM, $4/month VPS sufficient); rich feature set matching Bitwarden's core feature set; multiple storage backends (SQLite, PostgreSQL); active maintenance by Daniel García + community contributors; clear deployment story (Docker, Helm, Ansible all community-maintained); cordial relationship with Bitwarden, Inc. (no antagonistic fork dynamics); cross-listed in web3privacy peer directory. Last verified 2026-05-13.

Useful when. You want to self-host a password manager with a polished commercial-grade client UX — Vaultwarden + official Bitwarden clients is the cleanest pairing. You want zero recurring cost for password sync — a $4/month VPS or a Raspberry Pi at home is sufficient. You want no vendor lock-in — your vault data lives on infrastructure you control; migrate to or from Bitwarden, Inc.'s hosted service freely. You're an organisation or team that wants a shared password vault without trusting a third-party service (and where a vendor support agreement isn't a hard requirement). You want a lightweight self-host — Rust + SQLite means you can run Vaultwarden alongside other services on existing infrastructure without resource concerns. You're already running a personal server (Nextcloud, home lab, anything) and want to add password storage to it. You want to graduate from KeePassXC's local-first model to a sync-capable solution while preserving the trust posture.

Caveats. You operate the server — backups, TLS, security updates, OS hardening, monitoring all become your responsibility. Don't underestimate the operational discipline required; password storage is critical infrastructure. Not an official Bitwarden, Inc. product — for compliance-sensitive deployments (enterprise audits, vendor agreements), the official Bitwarden server (paid) is the right pick. Audit pedigree is informal — Bitwarden, Inc. has commissioned Cure53 audits of its server; Vaultwarden has community review but not equivalent formal audits. The codebase is small and Rust-safe; community trust is high but the audit-report story is different. Update lag behind Bitwarden — major Bitwarden client releases sometimes introduce new server-side features; Vaultwarden adds them with 1-4 week lag. For users who need cutting-edge Bitwarden features immediately, hosted Bitwarden is faster. No commercial support — community Discord + GitHub issues for help. For organisations that need SLAs, Vaultwarden doesn't fit. Backups must be designed early — losing your VPS means losing your vault (unless you've backed up the SQLite/PostgreSQL data + the rsa_keys directory). Use restic, borg, or rclone to back up to encrypted off-site storage. Multi-instance HA is more complex — for true high-availability deployments (multiple Vaultwarden instances behind a load balancer), you need PostgreSQL + shared filesystem for attachments; the Bitwarden, Inc. official server handles this with built-in clustering. Admin panel default password — set a strong admin token early; the admin panel can manage all users on your instance. TLS is mandatory in practice — Vaultwarden over plain HTTP is unsafe; front with Caddy (automatic Let's Encrypt) or nginx + certbot. Mobile clients require the server URL — when a Bitwarden mobile client first launches, it needs the server URL configured; this is a one-time step but worth knowing for onboarding family members or team members.