Vaultwarden: Your Own Bitwarden-Compatible Vault

Vaultwarden is a lightweight, Rust-based server that implements the Bitwarden API, so the official Bitwarden apps connect unmodified and you get a self-hosted password vault that idles under 100 MB of RAM. It is the highest-value app in the stack — and the last thing you want on a public hostname.

The reason Vaultwarden exists is that the official Bitwarden server is an enterprise product. It ships as a Docker Compose stack of half a dozen containers including Microsoft SQL Server, which is fine for a company and absurd for a household. Vaultwarden collapses all of that into a single Rust binary that runs happily in a 512 MB LXC container with a SQLite database, while speaking the exact same API the official clients expect. You get the same apps, the same client-side encryption, the same browser extensions — just a server you own instead of one you rent.

I run Vaultwarden on the Proxmox host alongside the rest of the stack from the self-hosted personal cloud apps guide, and it is the one app I am most careful with. This is the setup that keeps a password vault both useful and safe — the database choice, the client configuration, the exposure model, and the backup pattern that means a dead host is a ten-minute recovery rather than a locked-out-of-everything emergency.

What Is Vaultwarden and How Is It Different From Bitwarden?

Vaultwarden is an unofficial, community-written server that speaks the Bitwarden client API; the official Bitwarden server is the reference implementation Bitwarden itself ships. The clients are identical — you install the normal Bitwarden app, browser extension, and desktop client, point them at your Vaultwarden URL instead of bitwarden.com, and they work. The difference is entirely on the server side, where Vaultwarden trades the official server’s heavy Microsoft stack for a single Rust binary.

The encryption model is the part that matters for trust, and it is identical to official Bitwarden: the vault is encrypted client-side with a key derived from your master password before anything ever reaches the server. Vaultwarden never sees your plaintext passwords — it stores encrypted blobs and serves them to clients that decrypt locally. That means the security of your vault depends primarily on your master password and your 2FA, not on whether the server is Bitwarden’s or yours. What you take on by self-hosting is the operational responsibility: patching, backups, and keeping the box private.

Feature parity is close but not absolute. Vaultwarden supports organizations, collections, sends, file attachments, emergency access, and WebAuthn hardware keys. The official server’s enterprise features — enterprise policies, directory sync, SSO connectors — are things a household does not need. For personal and family use, Vaultwarden covers everything Bitwarden’s paid tier offers, including the secure sharing of logins between household members through organizations.

How Much Hardware Does Vaultwarden Need?

Almost none. Vaultwarden is a single Rust binary that idles in tens of megabytes of RAM and barely registers on the CPU, which makes it the lightest app in the personal-cloud stack by a wide margin. A 512 MB LXC container is overkill; the official Bitwarden server’s multi-container, MSSQL-backed footprint is a different universe.

This lightness is why Vaultwarden is the app I tell people to install first, even before they have the rest of the stack figured out. It runs on a Raspberry Pi without breaking a sweat, it runs in a corner of an existing server without competing for resources, and it delivers immediate, daily value — every account you create from then on goes into a vault you own. In my rack it shares a host with the much heavier Immich and Nextcloud containers from the Immich setup and the file-sync comparison, and its resource footprint is invisible next to theirs.

The one resource you should not skimp on is the storage underneath the database, because a corrupted vault database is a bad day. Vaultwarden defaults to SQLite, which means the entire vault is one file on disk — and that file should live on SSD with snapshots, not on a flaky SD card or a drive you are not backing up. The binary is cheap; the data is not.

The Database Choice: SQLite, MySQL, or PostgreSQL?

SQLite is the default and the right choice for almost every household Vaultwarden install — the vault is one file, backups are a file copy, and the concurrency a family generates is well within SQLite’s comfort zone. MySQL or PostgreSQL only earn their place if you have many simultaneous users or you want to run Vaultwarden across multiple replicas, which a household does not.

The appeal of SQLite here is operational simplicity. The database is a single file on the filesystem, which means backing up the vault is literally copying that file (with the server stopped or using SQLite’s online backup to avoid a torn copy). Restore is putting the file back. There is no database server to run, no credentials to rotate, no separate backup job for the DB. For a workload that is overwhelmingly reads (your clients fetching the vault on unlock) and occasional writes (saving a new login), SQLite is the correct engineering choice, not a compromise.

PostgreSQL becomes worth it only at scale that does not exist in a home. If you ever move to it, do it because you want Vaultwarden in a high-availability pair, not because SQLite is too slow — it is not. The mistake to avoid is treating SQLite as a “starter” database you will outgrow; for a password vault, its single-file simplicity is a feature you want to keep.

How Do the Official Bitwarden Clients Connect?

The official Bitwarden clients connect to Vaultwarden by changing one setting — the server URL — in each app, after which every feature works exactly as it did against bitwarden.com. There is no special Vaultwarden client; you use the apps you would use anyway, pointed at your own server.

In the desktop client and the browser extension, the server URL is in the settings before you log in. On mobile, the iOS and Android apps have a self-hosted option on the login screen where you enter your Vaultwarden URL. Once set, the app talks to your server for everything: vault sync, item updates, organization sharing, 2FA, and WebAuthn. Your existing Bitwarden vault can be exported from the official service and imported into Vaultwarden, so migration is a one-time export-and-import rather than a re-entry of every login.

The configuration detail that catches people is the URL itself. The clients expect an HTTPS URL with a valid certificate, and they are picky about it — a self-signed certificate produces cryptic sync failures on mobile in particular. The fix is a real certificate, not convincing the client to trust a self-signed one, which leads directly into the exposure question.

Should You Expose Vaultwarden to the Internet?

No. Vaultwarden should be reachable only over WireGuard or a private overlay like Tailscale, never on a public hostname with a forwarded port. The vault’s client-side encryption means a breach does not hand attackers your plaintext passwords, but a publicly exposed login surface still invites brute-force attempts against accounts, attracts automated scanners, and puts the burden of patching on a clock you did not choose.

The argument people make for exposing it is convenience — they want to unlock the vault from their phone anywhere without connecting a tunnel first. That convenience is real but cheap to reproduce safely: WireGuard connects in well under a second on a modern phone, and it can be set to auto-connect on unlock, so the practical difference between “open the app” and “connect WireGuard then open the app” is negligible. The home VPN and remote access guide covers the WireGuard setup, and Tailscale is the even-lower-friction alternative if you do not want to run your own endpoint.

My Vaultwarden sits on the management segment of my network, behind the OPNsense firewall, with inter-VLAN traffic default-deny and an explicit rule allowing only the WireGuard subnet to reach it. The IoT VLAN, the kids’ segment, and the workshop sensor network have no route to it at all — the hydro lab and the welder-bench sensors are different trust zones on the same router, and none of them need to talk to my password vault. The only door in is the WireGuard key my devices hold, and that is the way it stays.

Enabling HTTPS and the Mobile App Certificate Quirk

Vaultwarden requires HTTPS for the browser extension and the mobile clients to function, and the certificate has to be real — a self-signed one produces sync failures that look like bugs but are really trust failures. The clean path is a Let’s Encrypt certificate in front of the server, terminated by your reverse proxy.

I run Caddy in front of Vaultwarden on the LAB segment, and Caddy obtains and renews the Let’s Encrypt certificate automatically — the 90-day cert lifecycle is handled with no intervention. For a service that stays fully internal, a wildcard certificate via DNS-01 is the cleanest approach because it does not require any inbound port; the Let’s Encrypt wildcard DNS-01 guide covers it, and the internal HTTPS certificates guide covers running your own CA for services you never intend to expose even through a tunnel. The reverse proxy comparison lays out the proxy choices.

The mistake I made here is the one I warn everyone about now: I initially exposed Vaultwarden on port 443 with a self-signed certificate to dodge the mobile trust warning, and within a week the mobile app was logging me out intermittently because the cert chain was not quite right. Behind WireGuard, with a real Let’s Encrypt cert at Caddy, it just works — the apps trust the cert, sync is reliable, and the server is not on a public hostname. The lesson is that the certificate is not an obstacle to work around; it is the system telling you the correct architecture.

Backups: Your Vault Is a Single File

Because Vaultwarden on SQLite stores the entire vault in one file, the backup problem is trivial in theory and non-negotiable in practice — back up that file on a schedule and test a restore, because a password vault you cannot recover is worse than no vault at all. The file is small (a few megabytes for a household), so there is no excuse for infrequent backups.

The pattern I run is a pre-update export plus a scheduled file backup. Before any Vaultwarden update, I stop the container and copy the SQLite file; that gives me a clean rollback point if the update migrates the schema in a way I do not want. On a schedule, the vault file is backed up with SQLite’s online backup API (so the copy is not torn while the server is running) to the NAS, and the NAS replicates offsite. I learned the hard way to test restores — I once ran Vaultwarden for months with a backup job that was silently failing because the path changed after a container rebuild, and I only found out when I needed it. Now a restore is part of my quarterly drill, not a faith-based exercise.

For defense in depth, the vault itself is encrypted at rest by Bitwarden’s client-side encryption, the SQLite file sits on an encrypted ZFS dataset, and the backups are encrypted. Even someone who stole the backup file would face the vault’s master-password key derivation before they could read a single login. That layered model — encrypted client-side, encrypted at rest, encrypted in backup, reachable only over WireGuard — is what makes self-hosting a password vault defensible rather than reckless.

What I’d Do Starting Today

If I were standing up Vaultwarden fresh, I would run the Rust binary in a 512 MB LXC on the Proxmox host, keep the SQLite database on SSD with snapshots, front it with Caddy and a real Let’s Encrypt certificate obtained via DNS-01, and expose it only over WireGuard from the management segment. I would enable WebAuthn hardware-key 2FA on my account immediately — the solid tap of a hardware key against the phone is the right second factor for the vault that protects every other account — and I would back up the SQLite file on a schedule with a tested restore.

The discipline is the whole game with a password vault. The app is bulletproof; the failures are operational — an exposed port, an untested backup, a self-signed cert worked around instead of fixed. Get the exposure right, get the backup right, and a self-hosted Bitwarden-compatible vault is the most quietly valuable thing in the rack: every login you create from then on lives in a vault you own, on a box you control, behind a firewall whose rules you wrote.

Related Guides

• Self-Hosted Personal Cloud Apps: The Complete Guide
• Home VPN and Remote Access: The Complete Guide
• Homelab Internal HTTPS Certificates: The Complete Guide
• Proxmox Homelab Setup Guide: Build a Self-Hosting Platform
• Self-Hosted Notes: Joplin Server vs Obsidian Sync vs Trilium