Self-host · Reviewed 2026

Vaultwarden — the lightweight Bitwarden server rewrite in Rust

Hand-forged metalwork on an anvil — Vaultwarden, the community-built Rust rewrite of the Bitwarden server

Vaultwarden is a third-party reimplementation of the Bitwarden server in Rust. Same wire protocol, same clients (your Bitwarden iOS app and Chrome extension talk to it without knowing the difference), but a tenth of the resource footprint and zero licence concerns about Premium-only features. It runs comfortably on a $5/month VPS or a Raspberry Pi — places where the official multi-container Bitwarden stack would either fail to start or run unhappily.

TL;DR

Vaultwarden is the right server pick for personal and small-team self-hosters: minimal RAM, all features unlocked, no licence keys. Official Bitwarden self-host is the right pick if you need formal vendor support, SSO/SCIM, or enterprise compliance scope. Clients are identical.

What Vaultwarden actually is

Bitwarden, the cloud service, runs on Microsoft's stack: ASP.NET Core for the API, MS SQL Server for storage, an Identity service for OAuth, plus several smaller containers for events, icons, notifications, attachments. The unified install Bitwarden ships for self-hosters bundles all of this into a single Docker image — but the underlying components and their resource appetites are unchanged. On a 1 GB VPS the unified container is a slow burn; on a Raspberry Pi 3 with 1 GB RAM, it doesn't start at all.

Vaultwarden takes a different path. Started in 2018 by Daniel García under the original name "bitwarden_rs," it reimplements the same HTTP API surface — the endpoints your Bitwarden Android app calls when you open the vault, the routes the browser extension hits when it autofills — using Rust and a SQLite/MySQL/PostgreSQL backend. It's a single static binary in a 50 MB Docker image. It uses about 200 MB of RAM idle, well under that on light load. It works on ARMv7 and ARM64 alongside x86, so it runs on every Pi that supports Docker.

Crucially, Vaultwarden is not a fork of the Bitwarden code. There is no copy-pasted server source. Daniel and the contributors read the public Bitwarden API specification and the open-source clients, then wrote a Rust server that matches the protocol from scratch. That distinction matters legally — Bitwarden's server source has historically been licensed under terms that restrict commercial redistribution, but reimplementing the protocol independently is fair game.

Why a community rewrite exists at all

Three reasons converge.

Resource footprint. Bitwarden's official self-host stack assumes datacenter hardware. The MS SQL Server container alone wants 2 GB RAM minimum. For a household running a Bitwarden vault with five users and a thousand items, that's massive overprovisioning — and most home servers are running on 4–8 GB total. Vaultwarden brings the resource profile down to "fits on a Raspberry Pi" so home labs become viable hosting targets.

Premium-feature licensing on self-host. The official self-hosted Bitwarden server requires a per-user licence to unlock Premium features (TOTP storage, attachments, hardware-key 2FA). The licence is free for individual use but you have to register with Bitwarden, generate a licence file, upload it to your instance. For a single-family server this is a one-time annoyance; for a small team it's an ongoing administrative tax. Vaultwarden enables all Premium features by default — no licence keys, no Bitwarden-issued tokens, no annual renewal.

Operational simplicity. One container, one config file, one storage volume. The official unified install is much closer to this than the legacy multi-container stack, but Vaultwarden remains simpler: there is genuinely nothing to misconfigure beyond the domain and admin token. For people self-hosting just one thing on a VPS, the difference between "five-minute setup" and "afternoon of YAML" is meaningful.

Vaultwarden vs official Bitwarden self-host

VaultwardenBitwarden self-host (unified)
LanguageRustC# / .NET
Image size~50 MB~600 MB
RAM idle~150 MB~1.2 GB
Minimum hostRaspberry Pi 3 (1 GB)VPS with 2 GB
DatabaseSQLite default; MySQL / Postgres optionalMS SQL / MySQL / Postgres / SQLite
Premium featuresAll unlocked, no licencePer-user licence required
SSO (SAML / OIDC)NoYes
Directory sync (LDAP / SCIM)NoYes
Vendor supportCommunity (Discourse forum, GitHub)Bitwarden, Inc.
Update cadence~monthly~monthly, lockstep with cloud
API compatibility~99% — small drift possible100% (same code as cloud)
Suitable forPersonal, family, small teamOrg with compliance / SSO needs

For everyone who isn't an enterprise — Vaultwarden is the practical choice. For everyone who is an enterprise — official Bitwarden self-host is the only choice that gets you SSO, SCIM, and a vendor on the other end of an SLA.

Install — Docker, three commands

This is the entire install for a basic Vaultwarden instance:

mkdir -p ~/vaultwarden
docker run -d \
  --name vaultwarden \
  -v ~/vaultwarden:/data \
  -p 8080:80 \
  -e ADMIN_TOKEN=$(openssl rand -base64 48) \
  --restart unless-stopped \
  vaultwarden/server:latest

Inside one minute, port 8080 on your host is serving the Bitwarden web vault, backed by SQLite at ~/vaultwarden/db.sqlite3. The ADMIN_TOKEN you generated above gates access to the /admin page — copy it somewhere safe.

For a real install you want HTTPS and a real domain — the browser extensions and mobile apps refuse to connect to plain HTTP except localhost. That requires a reverse proxy.

Reverse proxy + HTTPS (Caddy example)

Caddy is the simplest option — it does Let's Encrypt automatically, no manual cert renewal scripts. Single Caddyfile:

vault.example.com {
  reverse_proxy localhost:8080
}

Caddy fetches a certificate, terminates TLS, proxies to Vaultwarden's HTTP port. Done. Nginx and Traefik configs are slightly longer but the principle is the same — Vaultwarden listens on plain HTTP locally; the proxy speaks TLS to the world.

Once HTTPS is up, point a Bitwarden client at your domain. In the desktop app, on the login screen, click the gear icon → Self-hosted → enter https://vault.example.com as the server URL. The client now talks to your Vaultwarden instance instead of bitwarden.com — and stops working when your home internet goes down, which is the trade-off you accepted by self-hosting.

Admin panel

Visit https://vault.example.com/admin, paste your ADMIN_TOKEN, and you're in the operator console. From there:

Restrict /admin to your home/office IP via firewall or reverse-proxy access rules. The admin token alone is decent protection, but defense in depth is cheap and admin-panel exposure is the single most common operational mistake on self-hosted Vaultwarden.

Premium features — all unlocked

What Bitwarden charges $10/year for on the cloud, Vaultwarden gives you for free on your own server:

The catch is enterprise-only features (SSO, SCIM, directory sync, event log retention) which Vaultwarden doesn't reimplement. If you need those, you're not the target user — pay Bitwarden for the official self-host.

Security & trust

Vaultwarden inherits the Bitwarden cryptographic model — vault data is encrypted on the client with AES-256, the server never sees plaintext, the master password never leaves your device. The server is a dumb ciphertext store; bugs in Vaultwarden cannot leak vault contents because Vaultwarden never has them in the first place. This is the core property of zero-knowledge design and it survives the rewrite intact.

That said, you are running a Rust server written by community contributors rather than Bitwarden, Inc. Two things follow:

The recommended security checklist:

  1. Run behind HTTPS with a reverse proxy.
  2. Disable open signups after your accounts are created.
  3. Restrict /admin to a known IP range or behind extra auth.
  4. Enable 2FA on your master Vaultwarden account immediately.
  5. Patch promptly when new Vaultwarden versions ship.
  6. Back up the data volume daily (see below).

Backup strategy

The entire Vaultwarden state lives in /data — that's it. SQLite database, attachments folder, RSA keys, config. Back up that directory and you can rebuild a working instance in five minutes on any host.

# Stop, snapshot, restart — clean SQLite backup
docker stop vaultwarden
tar czf vaultwarden-$(date +%F).tar.gz ~/vaultwarden/
docker start vaultwarden

# Or with restic (incremental, encrypted, off-site)
restic -r s3:s3.amazonaws.com/your-bucket backup ~/vaultwarden/

For a more sophisticated setup, run the backup against a snapshot of the data volume rather than stopping the container — but for personal scale, a brief overnight stop is fine. The total state is under 100 MB for most family deployments.

Test restore monthly. A backup you've never tested is not a backup.

Updates & tracking upstream

Vaultwarden ships a new tag roughly monthly. The pattern:

docker pull vaultwarden/server:latest
docker stop vaultwarden
docker rm vaultwarden
# re-run the docker run command above

Subscribe to the GitHub Releases Atom feed so security updates don't sit unnoticed. Watchtower works for unattended updates — many home-lab operators run it gated to a manual confirmation rather than fully automatic, but either way it's better than letting your instance drift months out of date.

Switching between Bitwarden cloud and Vaultwarden

Both speak the same protocol, so migrating either direction works:

The migration walkthrough we wrote for LastPass users covers the import mechanics — they apply identically here.