The Family Vault: Vaultwarden

Passwords were on the original to-do list from the very first post: the family needed to stop keeping credentials wherever their browsers happened to put them. The answer is Vaultwarden, the lightweight Rust reimplementation of the Bitwarden server, deployed in March as one of the earliest tenants on apps1.

The deciding factor wasn’t the server at all. It’s that Vaultwarden speaks the Bitwarden protocol, which means my family gets the official Bitwarden apps: browser extensions, iOS and Android apps, autofill that actually works. For every other service on this platform I control both ends. For a password manager, client quality decides whether the household adopts it, and shipping my own client was never on the table. Speaking someone else’s well-supported protocol is the sweet spot between sovereignty and usability.

Deployment, by now, is a rhyme

The infrastructure story barely deserves its own paragraph, which is itself the story: a PostgreSQL database on the managed DBaaS, the standard role shape copied from the blog and dashboard (upstream container, Tailscale sidecar, Traefik route, numbered playbook), TLS from the shared DNS-01 machinery. By the third apps1 service the epics had converged on a canonical arc: infrastructure, deploy, TLS, SSO, backup. Later services would copy Vaultwarden’s role the way Vaultwarden copied the dashboard’s. Patterns compounding is what a one-person platform survives on.

Where single sign-on stops

The interesting design decision is where Authelia does not sit. Every other web service here hides entirely behind forward auth. Vaultwarden can’t: the native apps and browser extensions talk to the API directly and would never survive an SSO redirect. More fundamentally, a password vault has its own, stronger boundary: end-to-end encryption. The vault is encrypted client-side with each person’s master password; the server stores blobs it cannot read. My server being compromised is a bad day, not a leaked-credentials day.

So the routing splits. The /admin panel, which can create users and read configuration, sits behind the Authelia forward-auth middleware like any other admin surface. The vault API itself faces the internet guarded by master passwords and the E2E design. Defense in depth where it helps, protocol compatibility where it matters.

The paranoid tier

The backup story got the full treatment in May: the database and attachment data flow nightly into the fleet’s backup system, which keeps two independent copies, one of them offsite, and the integration work ended with an actual restore drill rather than a hopeful checkbox. A password vault is the single worst thing to discover missing from your backups, so this one earned the paranoid tier. The backup machinery itself, and why I’ve come to trust it, gets two full posts of its own in a few weeks.

The honest scoreboard

Now the part a marketing page would omit. The server has been running since March. The family migration onto it, the account setup, the client configuration guide, the “move your passwords out of the browser” sessions, is still ahead of me at the time of writing. The stories exist in the backlog with their boxes unticked.

Partly that’s sequencing: the fleet era you’ll read about in the coming weeks ate the calendar. But partly it’s that this migration is the most human-dependent one on the platform. Moving mailboxes is my work; moving password habits is theirs, and it needs unhurried sit-down time with each person, not a Tuesday-evening deploy window. I’d rather run the server empty for months than rush the one onboarding where a botched first impression means someone quietly goes back to sticky notes.

So: infrastructure done, verified, backed up. Adoption pending. Sometimes that’s the truthful shape of self-hosting progress, and pretending otherwise would break the one rule this blog has.

Next week: the service that ended up hosting this project’s own beating heart.