Hosted password managers have a real, documented track record of being targeted. The 2022 LastPass breach disclosed encrypted vault data of every customer, and the months of analysis that followed showed that vaults with weak master passwords were brute-forceable from the stolen ciphertext. The hosted model is convenient. It also means the encrypted blob containing all your secrets exists on someone else's infrastructure, where it can be stolen even if your password is perfect.
Self-hosting eliminates this category of risk by relocating the blob to infrastructure you control. It introduces a different category — your infrastructure, your problem. Three serious self-hosted password managers are widely deployed: Vaultwarden, KeePassXC, and pass. They take fundamentally different architectural approaches.
Vaultwarden
Vaultwarden (formerly bitwarden_rs) is a Rust implementation of the Bitwarden server API. It's fully compatible with all official Bitwarden client apps (web, desktop, mobile, browser extension) but runs as a single small binary instead of Bitwarden's heavier official server stack. A typical Vaultwarden deployment is a Docker container with a SQLite database, fronted by a reverse proxy with HTTPS.
The architecture is conventional client/server. Vaults are encrypted client-side with a key derived from your master password (PBKDF2 or Argon2id, depending on configuration). The server stores ciphertext only — it cannot read your passwords. Sync between devices works through the server, so any client with network access to your Vaultwarden instance can pull the current vault.
Strengths: Excellent client ecosystem because of API compatibility (browser autofill on all major browsers, native iOS and Android apps with biometric unlock, full Bitwarden CLI compatibility, official passkey/FIDO2 support, organizations and sharing for families and small teams). The Bitwarden clients are mature, audited, and actively maintained. The Vaultwarden server is small enough to read end-to-end and runs comfortably on a Raspberry Pi.
Weaknesses: You're running an internet-exposed service (or at minimum a VPN-exposed service) that holds the encrypted blob of every credential you have. Compromise of the server still gives an attacker ciphertext, but ciphertext you control is no better than ciphertext Bitwarden controls if your master password is weak. You also inherit the operational burden — TLS certificates, backups, OS updates, container updates, intrusion monitoring.
KeePassXC
KeePassXC is the actively-maintained desktop fork of the original Windows-only KeePass. It is fundamentally not a server — it is a desktop application that reads and writes a single encrypted database file (typically a .kdbx file). The database format is open, well-documented, and supported by dozens of third-party clients on every major platform.
The trust model is markedly different from Vaultwarden's. KeePassXC has no concept of a server, and the database file is just a file. Sync is whatever you make it: Syncthing, Nextcloud, Dropbox, manual USB transfer. Mobile clients (KeePassDX on Android, Strongbox or KeePassium on iOS) typically open the same database file from a sync service or local copy.
Strengths: The smallest attack surface of any option here. There is no service to compromise — only a file format. The encrypted database can be stored on any storage medium without trust assumptions about the medium. KeePassXC supports YubiKey challenge-response as a second factor on the database itself, which is dramatically stronger than most second-factor implementations because the YubiKey must be present to decrypt. Browser integration via KeePassXC's official browser extension is functional but less polished than Bitwarden's.
Weaknesses: Sync conflicts are real. If you edit the database on two devices simultaneously without saving in between, KeePassXC will fail to merge cleanly and you'll lose one set of changes. Mobile UX is workable but not as smooth as a native cloud-backed client. Setup of multi-device sync requires picking and configuring a separate sync mechanism.
KeePassXC's YubiKey challenge-response support is one of the strongest defensive features in any password manager. The Yubikey must be physically present and respond to a challenge to decrypt the database. Without the key, even a perfectly correct password produces only gibberish. This makes the encrypted database meaningfully safer to store in untrusted locations.
Pass (passwordstore.org)
Pass takes a Unix-philosophy approach: every credential is a small GPG-encrypted file, and the entire collection lives in a directory tree, optionally versioned with git. There is no database — just files. The reference implementation is a bash script of approximately 800 lines.
To retrieve a password, you run pass show github.com/myaccount and pass decrypts the corresponding file with GPG, prompting for your GPG passphrase (typically cached via gpg-agent for a configurable interval). To sync between devices, you push and pull the git repository. To share credentials with a teammate, you add their GPG key to the relevant subdirectory and re-encrypt.
Strengths: The data model is extraordinarily transparent. If pass disappeared tomorrow, you'd still have a tree of GPG-encrypted files that any GPG implementation can decrypt. The git history gives you free versioning, audit trail, and conflict resolution. Multi-recipient encryption (different GPG keys for different password subtrees) provides clean per-credential access control. Browser extensions exist (browserpass), but most users access pass via terminal or via rofi/dmenu launchers.
Weaknesses: You need to be comfortable with GPG, which is notoriously rough. Mobile support exists (Password Store on Android, Pass on iOS) but is more cumbersome than the alternatives. The browser autofill experience is functional but not as smooth. There's no built-in concept of TOTP storage (though plugins exist). Backup-and-recovery requires understanding both your git remote and your GPG key infrastructure.
Side-by-side comparison
| Property | Vaultwarden | KeePassXC | Pass |
|---|---|---|---|
| Architecture | Client/server | File-based | Git tree of GPG files |
| Sync mechanism | Built-in (HTTP) | External (Syncthing, etc.) | Built-in (git) |
| Conflict handling | Strong | Manual | Git merge |
| Browser autofill quality | Excellent | Good | Functional |
| Mobile UX | Excellent | Good | Rough |
| Operational burden | Server + TLS + backups | Sync + backups | GPG + git + backups |
| Audit-friendliness | Codebase auditable | File format auditable | Files = trivially auditable |
| YubiKey support | Login second factor | Challenge-response (strong) | Via GPG smartcard |
How to pick
The decision is mostly about how much operational complexity you'll tolerate vs. how much polish you want:
Vaultwarden is the right answer if you want a Bitwarden-quality experience without trusting Bitwarden the company. You will run a server. The clients are excellent and your family members will not complain. Pair with a strong master password and reverse-proxy authentication (basic auth + your normal HTTPS layer) to reduce the attack surface of the server itself.
KeePassXC is the right answer if you want maximum simplicity in the trust model and are comfortable picking and configuring your own sync mechanism. The YubiKey integration is a significant defensive feature for users handling sensitive accounts. Sync conflicts are the main operational annoyance — Syncthing handles this better than cloud-drive options.
Pass is the right answer if you're already a GPG user, comfortable on the command line, and want your password manager to be readable, scriptable, and trivially auditable. It is the worst option for users who want polished mobile and browser experiences. It is the best option for users who want to be able to inspect every byte of their password storage and understand the cryptography end to end.
All three are meaningful improvements over closed-source hosted password managers if you have the operational capacity to run them well. The largest mistake is choosing one and then operating it poorly — a self-hosted password manager without backups, with a weak master password, or exposed to the public internet without proper hardening is worse than a competently-run hosted alternative. The infrastructure has to be at least as well-administered as the service you're replacing.