Sensitive tier: Vaultwarden

[Gerrrt]

Sub-issue of #102.

What and why

Vaultwarden GPL-3.0 Rust/Docker — awesome-selfhosted README.md:1654.

A Bitwarden-compatible server in Rust, so the official clients and browser extensions work against it unchanged. Of everything ADR-0008 places on the sensitive tier, this is the highest value per megabyte — a few hundred MB resident, and it replaces the single most consequential piece of SaaS in a household.

Upstream Bitwarden (README.md:1652, AGPL-3.0) is the alternative and is a heavier deployment (MSSQL, several containers) for no benefit at two users.

The part that actually matters

The restore path, not the deployment. A password vault is the one service here where "it is running" and "it is recoverable" are entirely different claims, and only the second one counts on the day it matters.

This lands on an estate where:

• make backup overwrites its own last-good archive, and nothing verifies it #64 — make backup overwrites its own last-good archive, and nothing verifies it.
• make backup uses an unpinned alpine image that evades both CI pinning checks #65 — make backup uses an unpinned alpine image.
• Nothing schedules any backup, digest check or key verification #77 — nothing schedules any backup at all.
• Get the firewall backup off prometheus, and buy a spare ProDesk to rehearse the restore #92 — the one backup that exists sits on the machine it protects.
• The age key has one holder and one copy #106 — the age key has one holder and one copy.
• ADR-0008 puts the family's credentials, photos and documents inside the estate — settle the continuity story before building it #122 — already open, and already asking exactly this question about the family's credentials.

None of those are blockers for standing the service up, but shipping Vaultwarden without settling at least #64 and #77 means the household's credentials would be the least-backed-up data in the house. That inversion is worth avoiding on purpose rather than discovering later.

What it needs

• Admin token and any SMTP credential in secrets/*.sops.yaml, rendered by scripts/render-config.sh. Never in compose.yaml, per the Grafana-password lesson in docs/security.md.
• SIGNUPS_ALLOWED=false after the two accounts exist.
• TOTP on both accounts. ADR-0008 defers SSO knowingly (ADR-0008 defers SSO knowingly — give the deferral an expiry #103) on the basis that per-application authentication with TOTP is proportionate — this is the application that assumption most depends on.
• A verified restore, once, before it holds anything real.

Which VLAN this touches

🔴 99 — Winterfell (management)

Security review

• Does not weaken the default-deny posture between VLANs — reached from Hicks under the existing 50→99; no new rule
• Any new credential goes in secrets/*.sops.yaml
• Any new device is added to docs/network.md with an OUI-truncated MAC — n/a

Depends on

#129 (Caddy) and the mini PC in #102. Strongly related: #122, #106, #64, #77.