A password manager is the one self-hosted app where “good enough” isn’t good enough. Every other app on your stack going down for a night is an inconvenience. Your vault going down, or worse, becoming unrecoverable, is every credential you have locked behind a box you can no longer reach. That raises the bar for how carefully you set this one up compared to, say, a media server or a dashboard. Vaultwarden makes the bar easy to clear, it’s a small, mature, low-resource app, but only if you actually do the hardening and backup steps instead of just running the container and calling it done.
What Vaultwarden actually is
Vaultwarden is a Rust reimplementation of the Bitwarden server API, not an official Bitwarden product. It’s compatible with every official Bitwarden client, the browser extensions, the mobile apps, the desktop app, the CLI, because it speaks the same API those clients already expect. You point a stock Bitwarden client at your own server’s URL instead of Bitwarden’s cloud, and everything works the same way it would against the real thing.
The appeal over running the official Bitwarden self-hosted stack is footprint. Official self-hosted Bitwarden ships as a multi-container stack with a fair amount of overhead. Vaultwarden is a single small binary, comfortably runs in an LXC container or a lightweight Docker Compose setup with a fraction of a CPU core and well under a gigabyte of RAM, and doesn’t sacrifice client compatibility to get there. For a homelab running one household’s or one person’s vault, that’s the right tradeoff almost every time.
The reverse proxy requirement isn’t optional
Bitwarden clients refuse to talk to a server over plain HTTP except on localhost. This isn’t a Vaultwarden limitation, it’s baked into the official clients themselves, so there’s no config flag on the Vaultwarden side that gets around it. You need TLS in front of it before any client will actually connect, full stop.
The practical path is a reverse proxy (Nginx Proxy Manager, Traefik, or Caddy, whichever you’re already running for the rest of your stack) terminating TLS with a certificate from Let’s Encrypt or your own internal CA, proxying back to Vaultwarden’s default port internally. If you’re not running a reverse proxy for anything else yet, this is a legitimate reason to stand one up, you cannot skip this step and still use the actual client apps.
Don’t expose Vaultwarden directly to the internet on its own port. Put it behind the same proxy and access pattern as the rest of your internal apps, and if you want mobile access away from home, reach it through a VPN overlay (WireGuard or Tailscale) rather than punching a public port open for it. This is exactly the kind of app where “just expose it, it’s password protected” is the wrong call, a login form facing the open internet is a target, a login form only reachable through your VPN isn’t.
Lock down the admin panel before anything else
Vaultwarden ships with a web-based admin panel for managing users, viewing diagnostics, and adjusting server config at runtime. By default it’s gated behind an ADMIN_TOKEN environment variable, and if that variable isn’t set, the admin panel is disabled entirely, which is actually the safer default for a lot of single-user setups.
If you do want the admin panel, generate a long, random token (treat it like a root password, not a login password) and set it via ADMIN_TOKEN, or better, use the newer Argon2-hashed token format if your version supports it instead of storing the plaintext value in your environment file. Never leave this unset while also leaving the admin route reachable on a network you don’t fully trust, and never reuse a token you’ve used anywhere else. Given that this panel can create and delete user accounts and touch server settings, it deserves the same treatment as any other break-glass credential in your stack.
Registration: turn it off once your vault exists
SIGNUPS_ALLOWED defaults to enabled, which makes sense for the very first setup, you need to be able to create your own account. Once you’ve created every account you actually need (yourself, and anyone else in your household you’re vaulting for), flip it to false. An open signup form on a password manager, even one sitting behind a reverse proxy on your own domain, is not a risk worth carrying once you don’t need it anymore. If you ever need to add a new user later, flip it back on temporarily, create the account, and turn it back off.
2FA is not optional here either
Vaultwarden supports TOTP (authenticator app) 2FA and WebAuthn/FIDO2 hardware key 2FA on individual vault accounts, the same options the official Bitwarden clients support, since it’s speaking the same API. Turn this on for every account the moment it’s created, before you start actually populating the vault with real credentials. This is the single highest-leverage step in this entire guide: a vault is, by definition, the thing that unlocks everything else you have, and a stolen master password without a second factor is a full compromise.
If you’re coming from the official Bitwarden cloud service and migrating, export your vault from there first (Bitwarden’s own export tool, unencrypted JSON if you’re going straight to import, or the encrypted export format if you want a safer intermediate step), then import it into your fresh Vaultwarden instance through the same client apps. Set up 2FA on the new account before you do the import, not after.
Backup: the part people skip until it’s too late
A Vaultwarden instance is small, which means its backup is also small and cheap to run often, there’s no excuse for skipping this. Two things need to survive: the SQLite (or Postgres/MySQL, if you configured one of those instead) database file, and the rsa_key files used for encryption, plus the attachments directory if you’re storing file attachments in the vault, not just logins.
A hypervisor-level VM or container backup (Proxmox Backup Server, or equivalent) covers you against the box dying outright, but it’s coarse, daily at best, and restores the entire VM state rather than just the vault data. Pair it with an app-level backup tool like Restic or Borg pointed specifically at Vaultwarden’s data directory, run more frequently, with the same 3-2-1 principle you’d apply to anything else that matters: a local copy, a second copy on different media, and a copy that lives somewhere off-site. For a vault this small, there’s no reasonable argument for only having one copy of it anywhere.
Test the restore, not just the backup. A backup job that’s been silently failing for three weeks is worse than no backup at all, because it gives you false confidence right up until the moment you actually need it. Restore it into a scratch container periodically, confirm you can log in and see your actual vault contents, then tear the scratch container down.
Where this fits in your stack
If you’re running Vaultwarden alongside a broader self-hosted setup with an SSO/identity layer like Authentik or Authelia in front of everything else, leave Vaultwarden itself out of that forward-auth chain rather than gating it behind your IdP. A password manager should stay a hard, independent login on its own, not dependent on another service being up and healthy before you can even get to your passwords, including the ones you might need to get that other service working again if something’s gone wrong.
Bottom line
Vaultwarden is genuinely one of the easiest wins in a homelab, tiny footprint, full Bitwarden client compatibility, and a real, durable reason to stop paying for a password manager subscription. The setup itself is a few minutes of work. The part that actually matters is the stuff that’s easy to skip: TLS in front of it through a reverse proxy, a locked-down or disabled admin token, registration turned off once your accounts exist, 2FA turned on before you trust it with real credentials, and a backup you’ve actually tested a restore from. Skip any of those and you’ve built a single point of failure for every other login you own.