Vaultwarden: a password vault that lives at home

Why not just use the hosted free tier

The hosted free tier is genuinely good and there is no shame in using it. The reason to self-host this particular service is that the vault is the thing everything else depends on — the router password, the recovery codes, the SSH keys — and a vault that lives on a machine in your house is a vault you can still open when your phone, your email and your hosting account are all locked out at once.

The corollary is the obligation: the vault backup is the single most important file on this rack. It is backed up nightly, copied to the NAS, and there is a printed copy of the recovery material in a drawer.

Access over the LAN and WireGuard, never the internet

Vault.lan resolves on the LAN and the same hostname resolves through the WireGuard tunnel from outside. Nothing is forwarded at the router, so there is no public login page for the vault — which is the difference between a service that gets probed daily and one that does not get probed at all.

The clients behave well with this: the browser extension caches the vault and syncs when the tunnel is up, and the phone app does the same. The failure mode to know about is adding a password on a plane and having it sync three days later — a real limitation, and the reason the offline export exists.

Argon2 settings and the Pi's login cost

Vaultwarden hashes the vault key with Argon2id at login. On a Pi 4 at the default settings that is about six hundred milliseconds, which is what makes a stolen database expensive to attack and what makes the Pi's CPU spike visible in Grafana for two users logging in.

Raising the KDF iterations makes the vault harder to crack and the login slower for everyone, including every device that has to re-derive the key after an app update. The default is the right trade at this scale; changing it is a decision worth writing down.

docker exec vaultwarden /vaultwarden hash --preset owasp
# generates a new ADMIN_TOKEN hash if you need to rotate it

The restore drill is the real deliverable

A backup of a password vault that has never been restored is a belief, not a backup. The drill takes twenty minutes and should be run twice a year: stop the container, move the data directory aside, restore last night's copy, start it, and log in from a device.

Do it on the same Pi with the production data moved aside rather than on a spare machine. The point is to prove the data directory alone is sufficient, because that is exactly what you will have if the SSD dies.

docker compose stop vaultwarden
sudo mv /srv/homelab/vaultwarden/data /srv/homelab/vaultwarden/data.old
sudo tar xzf /srv/homelab/backup/vaultwarden-$(date -d yesterday +%F).tgz -C /srv/homelab/vaultwarden
docker compose up -d vaultwarden && docker logs --tail 10 vaultwarden

compose file

Drop the whole file at /srv/homelab/vaultwarden/compose.yaml. Tags are pinned, never latest: rolling back on a Pi is far more work than upgrading.

services:
  vaultwarden:
    image: vaultwarden/server:1.33.2
    container_name: vaultwarden
    restart: unless-stopped
    ports:
      - "8083:80/tcp"
    environment:
      TZ: Asia/Shanghai
      DOMAIN: https://vault.lan
      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "false"
      ADMIN_TOKEN: ${VW_ADMIN_TOKEN}
      SHOW_PASSWORD_HINT: "false"
      ROCKET_PORT: "80"
      SENDS_ALLOWED: "true"
      WEB_VAULT_ENABLED: "true"
    volumes:
      - /srv/homelab/vaultwarden/data:/data
    read_only: true
    tmpfs:
      - /tmp
    security_opt:
      - no-new-privileges:true
    networks: [rack]

networks:
  rack:
    external: true

Hardening checklist

• signups are disabled so nobody can create an account on an instance they found
• the admin panel is disabled entirely; user management happens through the CLI with a token that lives in the env file
• the vault is reachable from the LAN and through WireGuard, never from a forwarded port, because a password manager login page on the public internet is a target
• two-factor is required for both accounts, and the recovery code is printed and stored offline
• the container runs read-only everywhere except its data volume

Verify it went in clean

• The vault opens from a phone on mobile data through WireGuard and shows an entry added on the LAN
• The web vault login takes around a second on the Pi, which is the Argon2id cost and not a problem
• Last night's archive restores into a running instance and the accounts still log in unchanged
• There is no signup link on the login page and the admin page returns 404

Hardware questions

Is a self-hosted password manager safe?

It is as safe as the machine and the backup. The threat it defends against — a hosted provider having a breach — is real but rare; the threats it introduces — an unpatched Pi, a forwarded port, a backup on a shared drive — are more likely. Run it on the LAN, keep it patched, keep the backup offline, and it is a net improvement.

Can the household share passwords with this?

Yes, through an organisation with collections. Create one organisation, put the shared entries — the wifi password, the streaming logins, the door code — into a collection both accounts can see, and keep personal entries in personal vaults. The recovery codes for the two-factor stay personal and offline either way.

What happens if the Pi dies?

You restore the data directory onto a new SD card or SSD, start the container, and every client syncs back from where it was. You can also read the vault without the server at all, because each client keeps an encrypted local copy — the export from the phone app is the escape hatch, and it is worth testing before you need it.