Picking the best self hosted password manager in 2026 comes down to one question before anything else: do you actually need a server? If you are a single user or a small family, a server adds attack surface and maintenance overhead that may not pay off. If your answer is still yes, the field has consolidated around four real options — and the correct one depends almost entirely on your team size and tolerance for unofficial software.
Who This Is For (and Who Should Skip It)
Self-hosting a password manager makes sense when you have an existing always-on server already running Docker — the kind of box a first self-hosted stack already gives you — a team with a genuine shared-secrets workflow, or a compliance reason to keep credentials off a vendor’s cloud. It does not make sense as a cost-saving measure — both Bitwarden and KeePassXC are free or near-free in their cloud or local forms, and the operational burden of a self-hosted vault is real.
If you are running a single NUC with no prior server experience, start with KeePassXC synced over Syncthing or Nextcloud. You get AES256 encryption, a 2023 third-party security audit, and zero server management. That covers the majority of solo and family use cases.
The Four Contenders
Vaultwarden — recommended for most homelab setups
Vaultwarden is an unofficial Bitwarden-compatible server written in Rust. It runs in a single Docker container on under 50 MB of RAM, uses all official Bitwarden clients (browser extensions, iOS, Android, desktop), and unlocks premium Bitwarden features — organizations, advanced 2FA, Send — at no licensing cost. The release history on GitHub shows active development: 1.37.2 landed in August 2026, 1.37.1 in July 2026, and 1.36.0 in May 2026 addressed multiple security advisories including SSO CSRF, user enumeration, and an SSRF vulnerability in the icon endpoint.
A minimal compose file:
services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: unless-stopped
volumes:
- ./vw-data:/data
environment:
DOMAIN: "https://vault.yourdomain.com"
SIGNUPS_ALLOWED: "false"
ADMIN_TOKEN: "${VW_ADMIN_TOKEN}"
ports:
- "127.0.0.1:8080:80"
Put Caddy or Nginx Proxy Manager in front for automatic TLS. Set SIGNUPS_ALLOWED: "false" immediately after creating your account — an open registration endpoint is the first thing that gets you burned. Enable fail2ban on the login endpoint. Backup the vw-data/ directory; that single path contains your entire vault.
The honest caveat: Vaultwarden has no formal third-party security audit. The project has had meaningful vulnerabilities patched over the past year, including access control issues that allowed low-privileged organization members to read credentials outside their permitted collections. If you run Vaultwarden for a team, pin to tagged releases and monitor the GitHub security advisories feed. Auto-updating to latest without review is a real risk on a credential store.
Official Bitwarden Self-Hosted — when audit history matters
Bitwarden’s self-hosted option requires a Families or Enterprise plan license, which means you pay even when running your own infrastructure. In return, you get audited server code, full FIDO2/passkey support, SSO integration, SCIM provisioning, and proper audit logging. The server stack runs on Docker and needs more resources than Vaultwarden. The standard deployment runs about a dozen containers, including a bundled MSSQL Express database capped at 10 GB. An external SQL Server is optional, and PostgreSQL only works with the Lite deployment.
For teams of 20+ where a compliance auditor might eventually ask “show me your audit trail,” official Bitwarden is the defensible choice. For a five-person family, it is almost certainly overkill.
KeePassXC — zero server, full local control
KeePassXC stores your vault as an encrypted local file, supports AES256 and Twofish, integrates with YubiKey and OnlyKey for hardware-factor unlocking, and received an independent security audit in January 2023. Sync is your problem — you handle it via Nextcloud, Syncthing, or a shared NAS mount.
This approach has a legitimate security advantage: there is no server to harden, no exposed HTTPS endpoint, and no CVE that puts your vault at risk while you sleep. The tradeoff is that mobile sync requires you to manage file distribution, and merge conflicts on the vault file are annoying when multiple devices write simultaneously.
Best for: solo users, people who already manage their own file sync, and anyone who considers a server another thing to patch.
Passbolt CE — team-first, browser-extension-driven
Passbolt’s Community Edition is free, AGPL-licensed, and built explicitly for credential sharing across a team. Where Vaultwarden and Bitwarden treat sharing as a feature, Passbolt treats it as the product. Credentials are encrypted per-user using OpenPGP, so the server never holds plaintext keys. The browser extension is the main interface, alongside mobile apps and a native Windows desktop app.
Passbolt CE supports unlimited users at no cost with core features including MFA, role-based access, and folder organization. Pro adds LDAP/AD provisioning, SSO, and audit logging at $4.90 per user per month (minimum 10 users). The CE install is heavier than Vaultwarden: Passbolt’s official Docker Compose file runs the passbolt/passbolt image plus a MariaDB container (PostgreSQL support is still experimental).
For sysadmin teams who spend half their day rotating shared service credentials, Passbolt’s access model makes sense. For everyone else, the setup complexity is not worth it over Vaultwarden organizations.
Vaultwarden vs Official Bitwarden: The Real Cost
The two speak the same protocol and use the same client apps, so the decision is rarely about features. It comes down to licensing, resource footprint, and audit posture.
| Vaultwarden | Official Bitwarden (self-hosted) | |
|---|---|---|
| License to self-host | None; free and open source | Paid Families or Enterprise plan required |
| Ongoing cost | Electricity only | Plan fee even on your own hardware |
| RAM footprint | Under 50 MB, single container | Several containers plus a SQL database |
| Database | SQLite by default (Postgres/MySQL optional) | Bundled MSSQL Express; PostgreSQL only with the Lite deployment |
| Third-party security audit | None | Yes, audited server code |
| Client apps | All official Bitwarden clients | All official Bitwarden clients |
| Best for | Homelabs, families, small teams | Orgs needing audit trails, SSO, SCIM |
Bitwarden documents its self-host path as requiring a Families or Enterprise license, so “self-hosted” here does not mean “free”: you run the servers and still pay the plan. The Families plan is a low flat annual fee for a handful of users; Enterprise is billed per user per month. Check the current pricing page for the exact figures, because they change. Vaultwarden charges nothing and still unlocks the premium client features, which is why it is the default recommendation for a homelab. The price you pay for that is the missing formal audit noted above, so match the choice to how much the vault is worth if it were breached.
Security and Keeping It Patched
Any self-hosted credential store is a high-value target. A few non-negotiable controls regardless of which tool you pick:
- Do not expose the admin panel to the internet. Vaultwarden’s
/adminendpoint and Bitwarden’s management UI should be accessible only from Tailscale or a local network. A credential database with an exposed admin endpoint is one misconfigured firewall rule away from a bad day. - Pin to tagged releases. Track the security advisories channel for whichever project you run. Password managers have historically been attractive targets; Vaultwarden’s CVE history over the past 18 months shows that “unofficial” does not mean “safe to ignore.”
- Enable 2FA on every account. Vaultwarden supports TOTP, email codes, and WebAuthn/passkeys. Hardware security keys are the strongest option; at minimum, use an authenticator app.
Backing Up and Restoring the Vault
Self-hosting moves the vault’s safety onto you. Get it wrong and one disk failure takes every credential you own, so this is the section to over-engineer.
What to back up. For Vaultwarden, everything lives under the vw-data/ bind mount: the SQLite database (db.sqlite3) holding accounts and encrypted vault items, the rsa_key files that sign login tokens, plus attachments/, sends/, and config.json. Copy the whole directory and you have captured all of it. If you moved Vaultwarden onto Postgres or MySQL, dump that database too, because the vault items then live there instead of in the SQLite file.
How to back up safely. A plain copy of an open SQLite file can be inconsistent. The reliable pattern is to stop the container, copy vw-data/ off the host with an encrypted rclone job to Backblaze B2 or an rsync to a NAS, then start it again — a few seconds of downtime buys a clean snapshot. If that downtime is unacceptable, use SQLite’s own .backup command against the live file rather than cp. Run it daily and keep at least one copy off-site; the vault contents are already encrypted, but encrypting the backup target protects the token-signing keys as well.
How to restore. Restoring is the reverse, and it should be rehearsed before you need it: stop the container, put the backed-up vw-data/ back in place, confirm file ownership matches the container’s user, and bring it up. Because the rsa_key material is in the backup, existing device sessions survive the restore; leave those files out and every client is forced to re-authenticate. Do a test restore into a throwaway container on a spare port at least quarterly and actually unlock the vault — an untested backup is a guess, not a safety net.
That routine is simply the 3-2-1 backup strategy for a self-hosted stack applied to the one directory you least want to lose: three copies, on two kinds of media, one of them off-site.
Getting to it remotely. Tailscale is the cleanest answer for personal use: no port forwarding, no exposed HTTPS endpoint, and no attack surface on the open internet. Cloudflare Tunnel is reasonable for teams who need access from managed devices where Tailscale is blocked. Raw port forwarding behind fail2ban is acceptable but adds exposure you do not need.