Self-Hosting Vaultwarden: You're the SRE Now

Your password manager is the hub of your whole security setup: site passwords, recovery codes, server keys, even shared items for family members — they can all converge in one place. Bitwarden's official service is genuinely good. I run Vaultwarden as a self-hosted node on top of it, and I keep the critical data exportable either way — two tracks, chosen for control, not for faith. This post is a threat-model-driven essay, and the point I'll hammer home is that backups are an obligation.

Threat model: who are you defending against, and what are you betting?

Let me list the adversaries first, so we're not just vaguely muttering "more secure."

• Random bots scanning the public internet: probing default ports, weak admin tokens, open registration. The response is not exposing (or tightly restricting) admin, disabling public registration, and using HTTPS with a strong master password.
• Someone who gets your backup bundle: if the backup isn't encrypted, they've got the whole vault. The response is encrypting the backup itself and storing the key separately.
• Yourself: accidentally deleting a volume, a botched upgrade, silent disk corruption, three years without testing a restore. This is usually the biggest enemy of self-hosting.
• A lost device: phone gone — can you still control sessions and 2FA devices? Remote logout, session timeouts, and 2FA recovery codes stored offline.

Self-hosting trades "the SaaS vendor's availability and backups" for "your SRE skills." The right to sovereignty comes with the duty to actually look after it. If you can't guarantee backups and restore drills, use a solid SaaS — don't fight for the romance of "I control everything myself."

Deployment baseline (don't put production entries in before this)

HTTPS is non-negotiable; don't settle for plain HTTP on the LAN — a password manager's traffic shouldn't start life as cleartext habits. Set a strong admin token and turn off public registration as soon as it's installed. The reverse proxy must pass WebSockets, or sync and notifications behave weirdly. Behind the proxy, mind the real client IP and the security headers. Tighten permissions on the container's data directory; admin goes through VPN or Access only, and turn it off or IP-restrict it when not in use.

The official Bitwarden clients can point at a self-hosted URL. Turn on 2FA. Keep the web vault session timeout short. These aren't nice-to-haves; they're the direct answer to the "bots plus session hijacking" slice of the threat model.

The backup obligation: losing this hurts worse than losing your photo album

The data directory and the database need encrypted backups off-site. If the vault is gone, the loss can outweigh your photo album — every site password, recovery code, and server key can live in there. The rhythm: automated daily encrypted backup, one copy off-site; and on a schedule (say quarterly), restore it on a different machine and confirm the clients can unlock and the entries are intact. Don't assume tar just works — permissions, paths, and versions can all trip you up.

One more export discipline: regularly do an encrypted export to a second location, complementing the automated backup. The export is your human-readable exit ramp; the backup is your whole-vault recovery path. Don't keep the master password and the backup key in the same plaintext note. If you lose your phone, 2FA plus remote logout stops the bleeding; recovery codes go in a sealed paper copy or an encrypted USB stick — not in a "vault-notes.md" that's encrypted with the same key, which is a circular dependency.

Family and the emergency exit

Think one step further for the family scenario: if you're not around, how do family members retrieve the passwords they need, with authorization? Trusted-contacts functionality, or an offline emergency kit (sealed, stored in separate places) — this isn't morbid, it's what an adult's backup looks like. For item organization, split the genuinely urgent entries (door access, bank support, cloud console) from "forums I can reset later," and keep only the minimal set in the emergency kit.

Before upgrading Vaultwarden, snapshot or back up; check the changelog for breaking migrations. Monitor container health and disk space — the disk holding the vault filling up causes "can't open it" far more often than getting hacked does. And the reverse proxy's request-size limits and timeouts need to accommodate clients syncing large attachment items, or you get the fake failure of "web opens fine, client sync fails" — don't blame the database first when you troubleshoot that.

How the two-track setup coexists with the official cloud

I keep the truly high-value stuff — the parts that need stable multi-device sync — portable back to the official service or exportable; the experimental self-hosted node starts with non-critical entries to learn on, and only after backups and drills are solid do I migrate core data over. On migration day, test it all again: unlock on new clients, revoke old devices, 2FA still works. Dual-track isn't a permanent split personality; it's leaving yourself a retreat route.

Writing a threat model as an essay, it comes down to one line: self-hosting a password vault makes you your own SRE, and availability, upgrades, and backup drills are obligations. If you can carry that, sovereignty means something; if you can't, keeping your master password in the browser while believing "I have a self-hosted vault" is more dangerous than honestly using SaaS. Put the backup obligation on your calendar, at the same priority as disk scrubs and certificate expiry — a password vault isn't "just another Docker toy," it's the ledger of every key in the house.