Yes, self-host your passwords — Vaultwarden makes it less risky than it sounds, because every Bitwarden client keeps a complete encrypted offline copy of your vault. Your server dying doesn't lock you out of anything; it stops sync until you restore. The three non-negotiables: HTTPS from the first request, a nightly backup you have restored at least once, and no raw exposure to the internet. Meet those and a $0/month container beats a SaaS subscription for one of the most personal datasets you own.

What you're actually running

Vaultwarden is an unofficial Rust reimplementation of the Bitwarden server API — the official browser extensions, mobile apps, and desktop clients all work against it unmodified. It has been maintained continuously since 2018, idles at 20–40MB of RAM with a SQLite file for storage, and includes the paid-tier features (TOTP authenticator, emergency access, organizations) free. The official Bitwarden self-host wants multiple containers and gigabytes of RAM; Vaultwarden is one container you could run on a router. The trade you're making: it is not Bitwarden the company's code, so track the Vaultwarden wiki for upgrade notes rather than assuming client and server always move in lockstep.

The honest threat model

Your vault is encrypted client-side — AES-256, key derived from your master password via Argon2 or PBKDF2 — before it ever reaches the server. A stolen database yields ciphertext plus metadata: your email, item counts, timestamps. What a fully compromised server could do is worse: serve you a tampered web-vault page that captures the master password on login. That's why HTTPS is non-negotiable and why the browser extension and mobile app (installed code, not served code) should be your daily entry points rather than the web vault.

Ranked by actual likelihood, the risks are: 1) you lose the server and have no backup — by far the most common failure; 2) a weak master password meets a leaked database; 3) the tampering scenario above. Notice what's not high on the list: cryptographic failure. The design protects the secrets; your job is availability and the master password.

A setup that won't bite you later

# /opt/stacks/vaultwarden/compose.yml
services:
  vaultwarden:
    image: vaultwarden/server:latest
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "false"
      ADMIN_TOKEN: "$argon2id$v=19$m=65540,t=3,p=4$..."
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:8081:80"
    restart: unless-stopped

The details that matter: SIGNUPS_ALLOWED=false after you've created your accounts, or anyone who finds the URL can register. The admin token should be an Argon2 hash, generated with docker exec -it vaultwarden /vaultwarden hash — a plaintext token in an env var is a secret sitting in docker inspect. Binding to 127.0.0.1 keeps the container reachable only through your reverse proxy, which terminates TLS; clients refuse to talk crypto over plain HTTP anyway. Configure SMTP (any relay works) because invitations, new-device alerts, and emergency access all depend on it. For reaching the vault away from home, a WireGuard or Tailscale path beats public exposure — the options are compared in remote access three ways. Since clients work offline, "sync only when home or on VPN" costs you almost nothing in practice.

Two operational notes. First, protect every account with 2FA — Vaultwarden supports TOTP and WebAuthn/passkeys natively, and the vault is precisely the account that deserves a hardware key. Second, update deliberately rather than automatically: pin a version tag instead of latest, skim the release notes (the maintainers flag breaking changes and any minimum client versions clearly), and upgrade monthly. Blind auto-updating is fine for a media server; for the service holding your credentials, thirty seconds of changelog reading per month is the right amount of paranoia.

Backups: small data, maximum stakes

The entire dataset is a few megabytes, which makes thorough backups almost free. Don't copy the live SQLite file with cp — use the backup API so you get a consistent snapshot even mid-write:

#!/bin/sh
sqlite3 /opt/stacks/vaultwarden/data/db.sqlite3 \
  ".backup /backup/vaultwarden/db-$(date +%F).sqlite3"
cp -r /opt/stacks/vaultwarden/data/attachments /backup/vaultwarden/
find /backup/vaultwarden -name 'db-*' -mtime +30 -delete

Run it nightly, ship the backup directory off-site with the rest of your 3-2-1 setup, and do one restore drill: fresh container, restored data/ directory, log in, confirm your newest entry is there. Ten minutes, done once, and the worst failure mode in the threat model is retired. As a second layer, periodically use the client's "Export vault (encrypted JSON)" — a server-independent copy that imports into anything Bitwarden-compatible.

Emergency access: plan for the bus

Two mechanisms, use both. Vaultwarden implements Bitwarden's emergency access: a trusted contact requests access, and if you don't veto within your chosen waiting period (72 hours is sensible), they get read access to your vault — it needs SMTP working and the contact to hold an account on your server. The low-tech layer matters more: a sealed envelope in a drawer or safe with the master password, the server's location, and one paragraph of "how to get the passwords out if I'm gone." Password self-hosting has a special obligation the password managers category doesn't print on the label: your household's continuity now depends on your documentation.

Bottom line

Vaultwarden is the best effort-to-value ratio in self-hosting: one container, 40MB of RAM, official clients, and a failure mode (server down, clients keep working offline) that forgives operational sloppiness better than almost any other service. Run it behind Caddy on a LAN or tailnet, disable signups, hash the admin token, script the SQLite backup tonight, and hand someone you trust the envelope. The subscription you cancel is $10 a year; the actual win is that the database of everything you can log into no longer lives on someone else's computer.