Vaultwarden Review 2026: The Self-Host Bitwarden Server That Runs on a Raspberry Pi

Vaultwarden is the unofficial Rust reimplementation of Bitwarden Server. 38 MB idle RAM, 95 percent API parity, AGPL-3.0. We ran it for 60 days against the official server and rate it 8.6/10 for the homelab use case.

Vaultwarden is an unofficial Rust reimplementation of the Bitwarden Server API. It was originally written by Daniel Garcia in 2018 (then called bitwarden_rs) and renamed in 2021 at Bitwarden’s request, since the project is not affiliated with the company. The repo lives at dani-garcia/vaultwarden, current stable is 1.34.x at the time of this writing, and the license is AGPL-3.0.

The key thing to understand: Vaultwarden is a server, not a client. You point the official Bitwarden browser extension, desktop app, mobile app, and CLI at your Vaultwarden URL by changing the server setting on the login screen. The clients do not know they are talking to Vaultwarden instead of Bitwarden’s cloud. Apart from a handful of admin endpoints, the wire protocol is identical.

That compatibility is what makes Vaultwarden interesting. You get the polished, well-audited Bitwarden client surface (browser ext on Firefox, Chrome, Edge, Safari; native apps on Windows, macOS, Linux; iOS and Android apps; CLI for scripting) and you pair it with a server you control on hardware you own. The vault data never leaves your house, your VPS, or wherever you decide to host it.

For users who chose Bitwarden because of the self-host option but balked at the official server’s resource footprint, Vaultwarden is the answer. For users who chose KeePassXC because they wanted local control but found the file-plus-Syncthing workflow too manual, Vaultwarden is also the answer. It occupies the specific middle ground of “I want self-host, but I also want clients that just work on my phone”.

Why we bothered with another review

Vaultwarden gets a brief comparison section in our Bitwarden review and gets recommended as the self-host pick in 1Password and Proton Pass reviews. None of those answer the operator-shaped questions: How do you actually deploy it? What does the backup and restore loop look like? Is the AGPL-3.0 license a problem for your use case? What features lag the official server in mid-2026 and is the gap closing? This review answers those.

The single biggest selling point of Vaultwarden is the resource footprint. The official Bitwarden self-host stack ships six containers (Web vault, API, Identity, Admin, Notifications, Icons) plus MS SQL Server. Vaultwarden ships one Rust binary in one container with embedded SQLite (or you can point it at MySQL or PostgreSQL if you prefer). We ran both on three reference setups for 60 days and logged the numbers.

Raspberry Pi 4 (4 GB RAM, 32 GB SD card)

The official server simply does not fit on a 4 GB Pi. The MS SQL Server container alone wants ~1.4 GB before any data. Vaultwarden runs fine and leaves enough headroom for Pi-hole, Home Assistant, or whatever else is on the box.

Mini PC (Intel N100, 16 GB RAM, 256 GB NVMe)

On beefier hardware the difference matters less for performance and more for operational simplicity. Six containers means six logs to grep, six images to update, six possible failure points. One container is one of each.

Cheap VPS (1 GB RAM, 1 vCPU, $4/month tier)

The VPS comparison is where this gets interesting financially. A 1 GB VPS for $4/month hosts Vaultwarden, Nginx for TLS, and Fail2ban for SSH protection with room to spare. To run the official server you need at least 2 GB of RAM, which on most providers is the $12/month tier. Over a year that is $96 vs $48, and over five years it is $480 vs $240. For one person’s vault, that is real money.

Why it is so much smaller

Vaultwarden compiles to a single static-ish Rust binary that bundles the API, identity, admin panel, web vault, and WebSocket notifications into one process. The official server splits these for horizontal scaling reasons that matter at enterprise scale and do not matter for a household. The SQLite backend (default) avoids a separate database process entirely. Icons are fetched on demand and cached on disk, not pre-rendered into a database table. The web vault is served as static files baked into the binary.

Many Vaultwarden tutorials online are 800 word essays. Here is the actual minimal setup we use, end to end, in 12 minutes.

Step 1: Docker Compose file

Drop this docker-compose.yml in a directory of your choice (we use /srv/vaultwarden/):

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: https://vault.yourdomain.tld
      SIGNUPS_ALLOWED: "false"
      ADMIN_TOKEN: "<random-64-char-token-here>"
      WEBSOCKET_ENABLED: "true"
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:8080:80"

Generate the admin token with openssl rand -base64 48. Bind to 127.0.0.1 because you want Nginx (or Caddy or Traefik) handling TLS in front, not Vaultwarden directly.

Step 2: Caddy for TLS in 6 lines

If you do not already have a reverse proxy, Caddy is the lowest-friction option in 2026. Caddyfile:

vault.yourdomain.tld {
    reverse_proxy 127.0.0.1:8080
    encode gzip
}

That is it. Caddy provisions the Let’s Encrypt cert, renews it, redirects HTTP to HTTPS, and passes WebSocket upgrades to Vaultwarden for live sync. There is no separate ACME script, no cron job, no certbot.

Step 3: First-run hardening

Once the stack is up, open https://vault.yourdomain.tld/admin, paste the admin token, and:

1. Disable invitations from non-admins in General Settings, otherwise any logged-in user can invite people
2. Set SMTP so password reset emails actually send (Resend free tier works fine for a household)
3. Create your account at the regular login page, then go back to admin and flip SIGNUPS_ALLOWED back off via the env var (re-deploy needed)
4. Enable 2FA on your first account before adding any vault items

The admin panel itself is gated by the ADMIN_TOKEN, not by a normal account. Lose the token and you lose admin access (vault data is fine, just admin is locked). Save it to a sealed envelope or a separate password manager.

Step 4: Backups, the part most people skip

The Vaultwarden data directory is small (under 100 MB for a household). A daily cron job rsync to a second drive plus weekly upload to Backblaze B2 with rclone covers you for around $0.30/year of B2 storage. We documented the exact bash script in our KeePassXC review (same backup pattern works for any file-based vault). The data to back up is /srv/vaultwarden/data/ in its entirety. Stop the container before snapshotting to avoid SQLite write-in-flight corruption, or use the official vaultwarden-backup helper that does a SQLite .backup command.

Total setup time on a fresh box: 12 to 15 minutes. We have done this enough times to time it.

Vaultwarden implements roughly 95 percent of the Bitwarden client API surface. Here is what is and is not there.

Fully supported (client features that just work)

• Password vault, secure notes, identities, cards
• Vault items with custom fields, attachments, item history
• Sends (file and text Sends with expiration and password protection)
• TOTP storage and code generation
• Passkey storage, including the new WebAuthn login flow (matches official server)
• Organizations with shared collections
• Browser autofill, mobile autofill on iOS and Android
• Bitwarden CLI for scripting
• Emergency Access (request-and-wait recovery)
• Folder structure and item search
• Master password and Argon2id KDF tuning

In other words, every feature a household or individual actually uses works the same as the official server. Several features (TOTP storage, Sends, Premium-tier passkey usage) are gated behind a paid license on Bitwarden’s cloud but are open on Vaultwarden. That is technically a license-tier violation if you ran a paid plan, but on your own server with your own users it is fine.

Partially supported or with caveats

• Push notifications on mobile: Work, but require either Bitwarden’s push relay service (you register your Vaultwarden instance for a free key) or you live without instant sync and rely on WebSocket polling. The relay registration takes 5 minutes and is the recommended path.
• Admin Console: Vaultwarden ships its own admin panel with environment-driven config rather than the official server’s full Admin Console. Most settings (signups, SMTP, branding) are there. Audit logs are minimal.
• Organizations: Work for small groups. The official server’s full Enterprise org with policy enforcement, member groups, and access control reports is implemented partially. Vault sharing within an org is reliable.
• Event logs: Available but truncated compared to the official server. Login events, vault item edits, and admin actions are logged. Detailed user activity reporting (“who exported the vault”) is not.

Not supported in mid-2026

• SSO (SAML/OIDC) for the vault login itself: The official server supports SSO as a paid Enterprise feature. Vaultwarden does not implement the SSO API endpoints. You log in with master password (and 2FA) like a personal account.
• Directory sync (Active Directory, Google Workspace, Okta user provisioning): No. If you need to auto-provision 200 employees, this is a hard blocker.
• Strict AGPL compliance audits: Vaultwarden itself is AGPL-3.0. If your employer’s legal team has an AGPL ban (common at large companies), you cannot use Vaultwarden internally without source disclosure. The official server uses GPL-3.0 plus a separate AGPL-3.0 license for some components, which is sometimes acceptable where pure AGPL is not.
• Official support contracts: Obvious but worth saying. There is no SLA, no phone number, no enterprise account manager. There is a GitHub issue tracker and a Matrix channel.

Gap-closing rate

We have watched Vaultwarden’s feature gap close over the years. WebAuthn support arrived within a few months of the official server. Passkey support landed in 1.32 last year, roughly two release cycles behind Bitwarden cloud. The maintainer pace is steady and the gap is narrowing, not widening.

Vaultwarden vs official Bitwarden Server, head-to-head

Vault encryption

Vaultwarden uses identical at-rest and in-transit encryption to the official Bitwarden Server. Vault data is encrypted client-side with a key derived from your master password through Argon2id (default since 2.7, tunable in the admin panel). The server only ever sees encrypted blobs. The salt, KDF iteration count, and ciphertext format match Bitwarden’s published spec exactly, which is why the official clients can decrypt Vaultwarden vaults without modification.

If Vaultwarden’s server process were compromised (root shell on the host), the attacker gets the encrypted blob, the protected key envelope, your email address, and any 2FA backup codes you stored unencrypted in the admin notes section. They do not get your master password. They cannot decrypt the vault without an offline brute force against your Argon2id-protected key, which at the recommended 64 MB and 3 iterations costs in the tens of milliseconds per attempt on a single GPU. A 12-character truly random master password is impractical to brute force even against a dedicated rig; a 6-word diceware passphrase is the same.

Clickjacking, the 2025 industry mess

We covered the Toth password manager clickjacking class in our Bitwarden review and Proton Pass review in detail. Short version: the clickjacking vector is a property of the browser extension, not the server. Since Vaultwarden uses the official Bitwarden browser extension, you inherit Bitwarden’s clickjacking posture exactly. That means partial fix as of mid-2026, autofill detection improved but not fully closed. Vaultwarden cannot fix this on the server side; it is on the Bitwarden client team.

This is worth saying explicitly because some self-host advocates assume self-hosting solves everything. It does not solve a browser-side attack. Self-hosting solves a different threat model (vendor breach, lawful access, account lockout) very well; it solves browser-extension flaws not at all.

Vaultwarden-specific concerns

The one place Vaultwarden differs meaningfully from the official server is the admin panel. The admin panel is a single token-protected web UI that gives root over the server config. If you expose the admin endpoint to the internet without an additional layer of protection (Cloudflare Access, Tailscale, fail2ban with IP allowlist), an attacker with the token can read any user’s protected vault key envelope (still encrypted, but they could replace it and try to phish a user into re-entering the master password). The recommended deployment binds /admin to a separate path that is firewalled to your home IP or VPN, not exposed to the open web. This is in the official docs and we strongly second it.

Supply chain

Vaultwarden’s release images are published to Docker Hub under the vaultwarden/server namespace. They are built on GitHub Actions from the public repo, so the build is reproducible in principle. There is no signed-binary chain like Apple notarization, but tagged releases are pinned to specific commits and you can pin to a digest (vaultwarden/server@sha256:...) for production deployment, which we recommend. We have not seen a single supply-chain compromise report on Vaultwarden in eight years.

Pick Vaultwarden if

• You self-host for a household (1 to 10 users). The footprint is right, the feature set is complete enough, the maintenance burden is low.
• You want to run on a Raspberry Pi or other low-RAM box. The official server simply will not fit. Vaultwarden does so with room to spare.
• You care about the polished Bitwarden client experience but not the cloud relationship. Same browser ext, same mobile apps, same desktop. Different server.
• You want Premium features (TOTP, Sends, attachments) without a license. Self-hosting on Vaultwarden unlocks these. On the official server they also work for self-host, but Vaultwarden is the lighter path.
• You already run a homelab with Docker, Caddy, and basic backups. The skills are the same as for any other self-hosted service.

Pick the official Bitwarden Server if

• You are a small business with 20+ users and need directory sync, SSO, or audit logging that satisfies a compliance auditor. AGPL is also sometimes a problem here.
• You have a paid contract and want phone support when things go wrong. Bitwarden Inc. responds. The community does too, but on a best-effort schedule.
• Your threat model includes “a community fork could go dormant” and you want the company-backed roadmap commitment. Vaultwarden has been actively maintained since 2018 with no signs of slowing, but it is one maintainer plus contributors versus a funded company.

Pick Bitwarden cloud if

You want self-host as an option but not as a requirement. Bitwarden cloud free tier is generous; the upgrade-to-self-host path is open if your priorities change.

Pick KeePassXC if

You want truly local, no-server-running, no-sync-protocol-to-debug. KeePassXC plus Syncthing is simpler than Vaultwarden plus Caddy, at the cost of weaker mobile UX.

Pick 1Password if

You want zero ops, polished UX, and family sharing that works without a setup weekend. The opposite of Vaultwarden.

Pick Proton Pass if

You want metadata encryption and an integrated Proton bundle. Proton does not self-host but the metadata story is unique.

Pick Aegis or Ente Auth for 2FA

Vaultwarden does store TOTP, and you can keep your 2FA codes in the same vault. The conventional wisdom is to separate password and second-factor across two apps to prevent a single compromise from giving up both. We agree with the conventional wisdom for high-value accounts (bank, primary email, identity providers); we are relaxed about it for everything else.

Vaultwarden is 8.6 out of 10 for the homelab use case. The Rust reimplementation is mature, the official Bitwarden clients work without modification, and the resource footprint is small enough that it runs on hardware you already own. The 5 percent of features that lag the official server (SSO, directory sync, enterprise admin) are exactly the features a household does not need.

What keeps it from a higher score is the operator burden. You handle your own TLS, backups, upgrades, and any debugging when something breaks. That is the deal you signed up for by self-hosting. If that deal sounds wrong, Bitwarden cloud is the answer instead.

What about the AGPL-3.0 worry? For personal use on your own hardware, it is irrelevant. AGPL only matters if you offer Vaultwarden as a service to other parties or modify it commercially. Running it for your family does not trigger AGPL obligations.

Is Vaultwarden going away? We do not think so. The project has been steadily maintained since 2018, the maintainer is responsive, contributors are active, and Bitwarden Inc. itself has been publicly polite about Vaultwarden’s existence. A community fork can theoretically wither but this one has not, and the API-compatibility moat (work continues even if the upstream Bitwarden API changes) keeps it useful.

For the specific question “I want self-host plus polished clients, what do I run”, Vaultwarden is the right answer in mid-2026. We rate it 8.6/10 and use it daily.