Vaultwarden is an unofficial server that speaks the Bitwarden client API, so Bitwarden's own browser extensions, mobile apps and CLI talk to your box instead of Bitwarden's cloud. It replaces a Bitwarden or 1Password subscription, and it replaces the official Bitwarden self-host stack for people who do not want to run it.
Our verdict on Vaultwarden#
Vaultwarden relicensed from GPL-3.0 to AGPL-3.0 in February 2023, so a public instance owes its users source on request while a family instance is unaffected. The dependency that actually bites is on the client side. You use Bitwarden's own extensions, mobile apps and CLI against your server, which means Bitwarden Inc sets your upgrade clock: 1.37.2 is explicitly marked as required for clients on 2026.8.0 and later, and that pattern repeats a few times a year. Pin Vaultwarden to an old tag and logins eventually break. What you get in return is every feature Bitwarden gates behind a paid plan, with no license key and no seat count: unlimited organization members, groups and collections, emergency access, vault TOTP, file Sends. It idles around 40 MB on SQLite, which is the whole point. The cost is that nobody is obliged to keep the client API compatible with a reimplementation, and there is nobody to call when it is not.
Who Vaultwarden is for#
Choose it if
- A household or small team that wants Bitwarden's polished clients without a per-seat subscription.
- Anyone on a Raspberry Pi or a 1 GB VPS, where the official Bitwarden self-host stack is far too heavy for the workload.
- People who need organization features (shared collections, groups, emergency access) that Bitwarden sells as a paid tier.
- Operators who want a password manager whose entire state is one directory they can copy.
Look elsewhere if
- You need vendor support, a signed compliance report, or a party to hold responsible. This is a volunteer reimplementation with no SLA.
- You want to run a paid hosting business on it. AGPL-3.0 source obligations and Bitwarden's trademarks both get in the way.
- You depend on Bitwarden's enterprise deployment pieces such as Directory Connector sync or Key Connector. Those are not implemented here.
What running it actually looks like#
One container and one volume. Mount a host directory at /data, set DOMAIN to the exact external URL, and put TLS in front, because the web vault, WebAuthn and passkeys all need a secure context. The container image listens on port 80; the standalone binary defaults to 8000 via ROCKET_PORT. Since 1.31.0 there is no separate WebSocket port, live sync rides the main HTTP port, so reverse proxy configs that still route 3012 are dead weight. First run: register your account, then set SIGNUPS_ALLOWED=false and invite people from the admin page. Enable that page by setting ADMIN_TOKEN, preferably as an Argon2id PHC string produced by vaultwarden hash. Upgrades are a tag bump and the schema migrations run at start. What breaks on upgrade is client compatibility, not the server.
Resource profile#
- Memory
- 40 MB idle, around 150 MB in ordinary use. A single Rust binary with no runtime; memory tracks connection count and the icon cache, not vault size. Estimated from typical small installs, the project publishes no figure.
- CPU and acceleration
- Effectively idle. The only real CPU is Argon2id key derivation at login and password hashing, which is deliberately expensive and lasts a fraction of a second.
- Storage growth
- The database stays small (a few MB for a household) because vault items are tiny encrypted blobs. Attachments and Sends are what grow, and the icon cache is disposable.
- Operational load
- 2 of 5, Light. One container, no separate database service, in-place upgrades that have been undramatic for years. The recurring attention is client compatibility: you have to track releases because Bitwarden client updates can require a matching server version.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Everything lives under /data. Back up db.sqlite3, attachments/, config.json if you ever saved settings in the admin page, and the rsa_key* files that sign auth tokens. sends/ is optional (Sends are meant to expire) and icon_cache/ is regenerable, so exclude it. Never copy db.sqlite3 while the server runs: use the sqlite3 .backup command or the built-in vaultwarden backup. When restoring, delete any leftover db.sqlite3-wal file first or you risk corrupting the database; db.sqlite3-shm regenerates itself and should not be backed up. On PostgreSQL, take a pg_dump and back up the same non-database files alongside it.
Derived backup shape
SQLite backup. sqlite3 <db> ".backup out.db" while running, or stop the container and copy. A live cp of a WAL-mode SQLite file can restore corrupt.
Traps and surprises#
Bitwarden's clients can outrun your server
The clients are Bitwarden's, and they update themselves. Release 1.37.2 carries an explicit warning that it is required for clients on version 2026.8.0 and later. If you pin the server tag and let browser extensions auto-update, you get login failures and sync errors that look like your problem. Subscribe to the release feed and treat a client major bump as a scheduled server upgrade.
Dollar signs in the admin token
vaultwarden hash emits an Argon2id PHC string starting $argon2id$v=19$.... In docker-compose every $ must be doubled to $$ or the value is silently mangled and login fails. Two related traps: you log in with the password you typed, not the hash itself, and a plaintext ADMIN_TOKEN triggers a startup warning that returns every 30 days until you convert it.
config.json silently outranks your environment
The moment you save anything on the admin page, Vaultwarden writes config.json into the data folder, and for most settings that file takes precedence over environment variables. People then edit their compose file, restart, and nothing changes. Either manage settings entirely through the admin page or delete config.json and go back to environment variables. Do not mix the two.
Copying the live SQLite file corrupts it
SQLite in WAL mode is not safe to cp while the server is writing. A naive nightly cp data/db.sqlite3 produces backups that restore into a corrupt or truncated vault, and you will not find out until you need them. Use the .backup command or vaultwarden backup, then restore into a throwaway container and log in once to prove the backup works.
Port 3012 no longer exists
WebSocket notifications used to run on their own listener on 3012 with a separate proxy rule. WEBSOCKET_ENABLED and WEBSOCKET_PORT were deprecated in 1.29.0 and support for the separate port was removed in 1.31.0; live sync now uses the main HTTP port and ENABLE_WEBSOCKET controls it. Old nginx and Traefik snippets copied from 2022 guides now proxy to a port with nothing on it.
Specifications#
- Category
- Passwords, SSO and identity
- Licence
- AGPL-3.0 (Copyleft)
- Written in
- Rust
- First release
- 2018
- Maturity
- Mature
- Datastore
- SQLite (default), PostgreSQL or MySQL/MariaDB
- Default ports
80,8000- Ships as
- docker, native binary, build from source
- arm64 builds
- Yes
- Identity
- Native OIDC. OIDC login is built in since 1.35.0, but a master password is still required and is not controlled by the identity provider, because it derives the vault key.
- Replaces
- Bitwarden (hosted), 1Password, LastPass, Dashlane
- Project site
- github.com/dani-garcia/vaultwarden
- Source
- github.com/dani-garcia/vaultwarden
- Documentation
- github.com/dani-garcia/vaultwarden/wiki
Alternatives to Vaultwarden#
Everything else in passwords, sso and identity, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Authelia | 3, Moderate | 35 MB | Apache-2.0 |
| LLDAP | 1, Set and forget | 15 MB | GPL-3.0 |
| Pocket ID | 1, Set and forget | 30 MB | BSD-2-Clause |
| Keycloak | 4, Heavy | 750 MB | Apache-2.0 |
| authentik | 4, Heavy | 1000 MB | MIT (core); authentik/enterprise/ under a separate Authentik Security license |
Where Vaultwarden comes up elsewhere#
Migration guides
Guides
- Backups that actually restore
- Choosing hardware for a home server
- Backing up a running database without corrupting it
- DNS, subdomains and split horizon for self-hosters
- Docker Compose conventions that survive year two
- Moving a self-hosted service to a new machine
- What a home server actually costs to run
- Remote access without port forwarding
- A security baseline for a home server
- Your first self-hosted server: the decisions that are hard to undo
- An update strategy that does not lose data
- When not to self-host
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.