Bitwarden's free tier is genuinely good, right up until you want a family or team plan — then it's per-seat pricing for what is, functionally, a sync server and a web vault. If you're already the person who self-hosts things, that's an easy service to bring in-house instead of paying for it monthly.
Vaultwarden is the reason this is actually viable: it's a full reimplementation of the Bitwarden server API in Rust, not a toy clone. It talks the same protocol the official apps expect, so the real Bitwarden browser extension, mobile apps, and desktop client all point at it and just work — you're not asking anyone to install a different password manager, you're pointing their existing one somewhere else. It's community-maintained (not run or supported by Bitwarden the company), but it's been around for years and is one of the most widely deployed self-hosted projects that exists for exactly this reason.
What self-hosting actually looks like
The image is vaultwarden/server, single container, listens on ROCKET_PORT (80 by default). Data — the SQLite database, attachments, sends — lives wherever you point it, and needs a real persistent volume or you lose every stored credential the next time the container restarts. That part's non-negotiable for a password manager specifically: "oops, ephemeral storage" here means locking your users out of their own vault, not just losing some logs.
Two settings matter more than people expect going in:
-
DOMAINhas to be the real HTTPS URL you're serving from, set correctly before anyone logs in the first time. Get it wrong and WebAuthn/passkey login and file attachments break in ways that are annoying to debug after the fact, because the clients compare it against the origin they connected on. -
SIGNUPS_ALLOWEDdefaults to open. Fine for the five minutes it takes to create your own account; leave it on past that and you've got a public password-manager signup form sitting on the internet. Flip it tofalseright after account #1 exists. This one's caused real incidents for people who forgot the step — worth doing before you close the tab, not on a todo list.
Local test if you want to poke at it before deciding anything:
docker run -d --name vaultwarden \
-e DOMAIN=https://your-domain.example \
-v $(pwd)/vw-data:/data \
-p 8080:80 \
vaultwarden/server:latest
Then point the Bitwarden browser extension's server URL at https://your-domain.example and log in like normal.
One-click if you'd rather not manage the box
I maintain a Railway template for this — full disclosure, I get a kickback if you deploy through it: https://railway.com/deploy/vaultwarden-4?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=inventory
It's the stock vaultwarden/server:latest image, nothing patched, wired up so the annoying parts are already handled: ROCKET_PORT set to Railway's PORT so the proxy routes correctly, the volume mounted at /data so your vault survives redeploys, and ADMIN_TOKEN set as an auto-generated secret so the /admin panel is protected from the start instead of left open on a default. You still have to remember to flip SIGNUPS_ALLOWED off yourself — that one's a decision only you can make, not something a template should silently do for you.
Honest limitations
This is a community reimplementation, not Bitwarden's own server — if Bitwarden ships a protocol change, there's a lag before Vaultwarden catches up, historically small but real. Ships with SQLite by default, which is genuinely fine for personal use or a small team; if you're putting this in front of an org large enough to worry about concurrent-writer contention, Vaultwarden does support Postgres/MySQL backends, but that's a config change you'd make yourself, not what this template ships. And self-hosting your password manager means you're now the backup strategy — there's no "forgot my master password, please recover" support line to call when it's your own box.
Upstream project, all credit to the actual maintainers: https://github.com/dani-garcia/vaultwarden
Top comments (0)