Vaultwarden

Lightweight Bitwarden-compatible password server

Password Managers ★ 68.1k stars Easy setup AGPL-3.0

Vaultwarden is a lightweight, unofficial Bitwarden-compatible server written in Rust that works with all official Bitwarden clients. It targets self-hosters who want Bitwarden without heavy resource use. It is deployed via Docker.

Vaultwarden setup guides & articles

Hands-on coverage of Vaultwarden from the blog.

Key features

  • Compatible with all Bitwarden clients
  • Tiny resource footprint
  • Organizations and sharing
  • Includes premium-equivalent features

Quick deploy

A starting point for self-hosting Vaultwarden - check the official docs for the full set of options.

  • Image vaultwarden/server:latest
  • Web port 80
  • Persist /data
Docker Compose
services:
  vaultwarden:
    image: vaultwarden/server:latest
    ports:
      - "80:80"
    environment:
      - DOMAIN=https://vault.example.com
    volumes:
      - ./data:/data
    restart: unless-stopped
docker run
docker run -d --name vaultwarden \
  -p 80:80 \
  -e DOMAIN=https://vault.example.com \
  -v ./data:/data \
  --restart unless-stopped \
  vaultwarden/server:latest

Watch out for

  • Clients refuse to talk to it over plain HTTP - put HTTPS in front from the first request
  • Back up /data nightly (SQLite database plus attachments) and test a restore once
  • After creating your account, disable open registration with SIGNUPS_ALLOWED=false

Reverse proxy: DOMAIN must match the exact public URL or WebAuthn and attachment links break.

Pros & cons

Strengths

  • Extremely lightweight
  • Works with official apps
  • Easy to deploy

Trade-offs

  • Unofficial, community project
  • Self-hosting security is on you

Vaultwarden replaces

Last reviewed Aug 22, 2026 · 686 words

Vaultwarden gives you the entire Bitwarden experience — official apps, browser extensions, organizations, TOTP, emergency access — on 128 MB of RAM, for free. The setup is genuinely easy. The responsibility is not: you are about to become the operator of the single most important service in your household, and the setup choices below are ranked by how badly they bite when skipped.

First, the question worth asking: should you?

Bitwarden's own cloud is free for the features most people need, audited, and run by professionals. Self-hosting wins when you want vault data on your own hardware as a matter of principle, features like organizations without a subscription, or a vault reachable only inside your network. It loses if you will not commit to backups and updates, because "my password server died and the backup was empty" is not a recoverable category of mistake. Think through the threat model honestly before, not after.

HTTPS is not optional, even on your LAN

Bitwarden clients use the Web Crypto API, which browsers only enable in secure contexts — over plain HTTP the web vault and extensions simply refuse to work. So TLS comes first, and the tidy pattern is a reverse proxy in front:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    environment:
      - DOMAIN=https://vault.example.com
      - SIGNUPS_ALLOWED=true   # flip to false after you register
    volumes:
      - ./vw-data:/data
    restart: unless-stopped

Caddy in front of this is a three-line site block with automatic certificates; the reverse proxy showdown compares the options. Two details punch above their weight: DOMAIN must exactly match the public URL (WebAuthn security keys and attachment links break otherwise), and once your accounts exist, set SIGNUPS_ALLOWED=false and restart — an open registration page on a password server is an invitation.

A backup you've never restored doesn't count

Everything lives in /data: the SQLite database, attachments, the RSA keys that sign login tokens. The backup routine is small enough to have no excuse:

sqlite3 vw-data/db.sqlite3 ".backup /backups/vw-$(date +%F).sqlite3"
tar czf /backups/vw-data-$(date +%F).tar.gz vw-data --exclude=db.sqlite3*

Use SQLite's .backup rather than copying the live file, ship the result off the machine nightly, and — this is the part people skip — do one test restore into a scratch container this week. Note the clients' saving grace: they keep a local cache, so even with the server down you can read (not edit) your vault. That buys you calm during an outage, not immunity from data loss.

Keep it patched, keep it boring

Vaultwarden is a small, focused Rust codebase with an excellent track record, but it moves in step with official Bitwarden clients — when the apps update their API expectations, the server needs to follow. A stale instance eventually meets a new client version it doesn't understand. Update monthly, read the release notes (the maintainer flags anything requiring action), and pin versions if you automate pulls. Enabling the admin panel? Set ADMIN_TOKEN to an Argon2 hash, not a plain string, and consider leaving the panel disabled entirely once configured.

LAN-only or internet-facing?

Exposing the vault publicly is convenient and, with strong master passwords plus 2FA, defensible. But the lower-risk pattern costs little: keep Vaultwarden reachable only via Tailscale or your VPN. Clients sync when the tunnel is up and serve from cache when it isn't, so daily use feels identical — you only need connectivity to edit or add entries. My full walkthrough, including fail2ban for the internet-facing case, is in the Vaultwarden guide.

What I'd do

Vaultwarden behind Caddy on a box that does little else, DOMAIN set, signups closed after day one, reachable over Tailscale only. Nightly SQLite backup to two destinations, restore test every few months, updates on a monthly calendar reminder. Run like that, it is the best password setup money can't buy — official-client polish with your data on your own disk, for about 30 minutes of honest operational commitment a year.

Compare Vaultwarden

27 head-to-head comparisons.

Similar password managers apps