Published

Vaultwarden

Self-hosted password manager server, written in Rust and compatible with the Bitwarden apps and browser extensions. An unofficial project, not affiliated with Bitwarden, Inc. Fits a household or a small team that wants its passwords on its own server.

Resources by load level

What the app itself needs at each level, next to what we recommend for a server that runs only this app.

Level	What it means	App requirements	Recommended
LightEstimate	Up to 10 people (a household), about 2,000 vault items, a few devices each, under 1 GiB of attachments, SQLite, no admin page.	0.25 vCPU · 0.25 GiB RAM · 1.5 GiB disk	0.42 vCPU · 1.8 GiB RAM · 11.04 GiB disk
MediumEstimate	Up to 50 users in a small business, organizations and collections, about 25,000 items, browser extensions online all day, up to 5 GiB of attachments, SQLite.	0.5 vCPU · 0.5 GiB RAM · 5.5 GiB disk	0.72 vCPU · 2.1 GiB RAM · 15.64 GiB disk
HeavyEstimate	Up to 250 users across several organizations, about 100,000 items, hundreds of clients connected at once, up to 20 GiB of attachments, still on SQLite.	1 vCPU · 1 GiB RAM · 20.5 GiB disk	1.32 vCPU · 2.7 GiB RAM · 32.89 GiB disk

Recommended = app requirements + system baseline + safety headroom, under sizing policy 2026.10.0. Options stay at their defaults. “Estimate” means the sources give no number for that case, so it is worked out from them by the method stated under Components. How the numbers are built

Size it in the Stack Sizer

Ready-to-run files

Support level Supported

Compose template from the official sources; not yet verified by a run.

Create docker-compose

Components

What each component needs at each load level, before baseline and headroom.

vCPU / GiB RAM / GiB disk
Component	Light	Medium	Heavy	Sources
Vaultwarden (app)	0.25 / 0.25 / 1.5	0.5 / 0.5 / 5.5	1 / 1 / 20.5	[5][10][11][12][22][29][31]

How the estimates are worked out

Vaultwarden · Light: No upstream figure. Vaultwarden is one Rust binary with an embedded SQLite file, built for setups where the official server is too heavy; the official image table lists it running on a Raspberry Pi Zero W and Pi 1. RAM 0.25 GiB and a quarter core cover sync and the server-side PBKDF2 (600,000 iterations) of a few logins at a time. Disk: image 90,367,076 B compressed (0.084 GiB) + 303,042,560 B unpacked (0.282 GiB), both kept by the containerd store = 0.366 GiB. 0.366 + 1 GiB data and attachments → 1.5.
Vaultwarden · Medium: RAM: the light 0.25 GiB ×2 for one open WebSocket per online client, the SQLite page cache of a larger vault and up to 10 pooled DB connections (DATABASE_MAX_CONNS) → 0.5 GiB. vCPU: logins at the start of the workday each run PBKDF2 with 600,000 iterations, and full syncs serialize whole organization vaults → half a core. Disk: image 90,367,076 B compressed (0.084 GiB) + 303,042,560 B unpacked (0.282 GiB), both kept by the containerd store = 0.366 GiB. 0.366 + 5 GiB → 5.5.
Vaultwarden · Heavy: RAM: medium ×2 for hundreds of open WebSockets and a SQLite database of about 100,000 ciphers held hot in cache → 1 GiB. vCPU: one full core for bursts of logins (each PBKDF2 with 600,000 iterations) and large syncs; SQLite serializes writes, so more cores add little. Disk: image 90,367,076 B compressed (0.084 GiB) + 303,042,560 B unpacked (0.282 GiB), both kept by the containerd store = 0.366 GiB. 0.366 + 20 GiB → 20.5.

Ports

Public ports are meant to be reached from outside the stack, usually through a reverse proxy; internal ones stay on the stack's own network.

Component	Port	Exposure	Purpose	Sources
Vaultwarden	80/tcp	Public, through a proxy	Web vault, client API and WebSocket notifications (Rocket HTTP); serve only through an HTTPS reverse proxy	[1][3][22]

Every port in the catalog, with conflicts between apps

User and permissions (UID/GID)

The user each container's process runs as, and the paths it writes to. A bind mount for one of these paths must be writable by that UID:GID.

Component	UID:GID	User	Starts as root	Writes to	Sources
Vaultwarden	0:0	`root`	No	`/data`	[3][6][14]

Storage growth

How much each component's data grows per month at each load level, on top of the disk in the profile. A value marked Assumption is ANAROQ's stated assumption, not a figure from the sources; the notes say what it rests on.

GiB per month
Component	Light	Medium	Heavy	Sources
VaultwardenAssumption	0.05	0.25	1	[5][12]

What the growth figures rest on

Vaultwarden: Vault items are small encrypted records; growth comes from attachments and Send files, which have no size limit by default (USER_ATTACHMENT_LIMIT unset). Assumed upload rates: 50 MB, 250 MB and 1 GiB a month. Org event logs are off by default, trash is not auto-deleted, and the icon cache expires after 30 days.

Upgrade and rollback

How to move to a new version safely, and how to go back if it fails.

Back up first

Run docker compose exec vaultwarden /vaultwarden backup (SQLite copy into /data), then copy the whole /data volume: db.sqlite3, attachments, sends, config.json and rsa_key*. [12][24][25]

Upgrade steps

Back up /data first (see backup). Then set the new pinned tag in the Compose file and run docker compose pull and docker compose up -d. [12][19]
Vaultwarden applies its database migrations at start, so check the logs (docker compose logs vaultwarden) and the /alive check before you rely on the new version. [4][16][24]

Roll back

Stop the stack, restore the /data backup taken before the upgrade (delete any db.sqlite3-wal when restoring a .backup or VACUUM INTO copy), pin the previous tag and run docker compose up -d. [12][24]DerivedUpstream documents no downgrade. Migrations run forward at start, so an older binary on a migrated database is not safe; restoring the pre-upgrade backup is.

Known breaking changes

In 1.37.4: Legacy API endpoints that upstream Bitwarden dropped were removed, along with DUO_USE_IFRAME (Duo Traditional Prompt) and the automatic email 2FA code for clients older than 2025.5.0. Update old clients before upgrading. [5][27]DerivedThe release page was not reachable from the research environment; taken from the 1.37.3 → 1.37.4 diff of .env.template and the tagged commit 'Remove legacy API endpoints and compatibility code dropped upstream' (#7809).
In 1.37.0: The client IP header is trusted only from private addresses (IP_HEADER_TRUSTED_PROXIES=local); a proxy on a public address must be listed, or rate limits and fail2ban see the proxy IP. A DATABASE_URL without a scheme now only works if the file exists; use sqlite://. [5][28]DerivedTaken from the 1.36.0 → 1.37.0 changes of .env.template (commits #7472 and #7061); the release page was not reachable from the research environment.

Limits

The web vault needs HTTPS: the browser's Web Crypto API only runs in a secure context, so open it through the HTTPS proxy (or http://localhost in the local mode). DOMAIN must be the exact https:// URL users open. [1][5][13]
No SMTP in the template: email verification, invitation and 2FA emails are not sent. Without push credentials from bitwarden.com/host, mobile apps do not sync live; browsers and desktop apps get WebSocket updates on the same port. [5][22][23]
The template uses SQLite in /data. PostgreSQL and MySQL are supported upstream through DATABASE_URL, but not templated here, and moving from SQLite later is marked unsupported in the wiki. [5][21]
Settings saved in the /admin page go to /data/config.json and override environment variables, so a later change in the Compose file can be silently ignored. [18]

Security

Vaultwarden is not affiliated with Bitwarden, Inc.; report problems to the Vaultwarden project, not to Bitwarden support. It holds every user's encrypted vault, so treat the server and its backups as critical. [1][12]
Anyone who reaches the URL can register while SIGNUPS_ALLOWED is true. Create your accounts, then turn on close-signups; set INVITATIONS_ALLOWED=false too if organization owners should not invite. [8][14][17]
The /admin page is off. If you enable it, ADMIN_TOKEN must be an Argon2id PHC string from /vaultwarden hash (single-quoted in .env), never a plain token, and HTTPS must be in place first. [5][9][25]
Against brute force, Vaultwarden rate-limits logins per client IP and logs each failed login with the IP, which fail2ban on the host can ban. That needs the real client IP from the proxy (IP_HEADER) and the logs in a file (LOG_FILE). [5][15][16]
The container runs as root (no USER in the image). Running as 1000:1000 is documented, but then Rocket must listen on a port above 1024 or get CAP_NET_BIND_SERVICE. [6][14][20]

Backup

Back up daily: db.sqlite3 with sqlite3 .backup on the host or /vaultwarden backup in the container (the image has no sqlite3), plus attachments (required), sends, config.json and rsa_key* from /data. Encrypt the copies: config.json and rsa_key.pem are sensitive. [12][25]
Restore with Vaultwarden stopped; when restoring a .backup or VACUUM INTO copy, delete any db.sqlite3-wal first, or SQLite may corrupt the database. icon_cache does not need a backup. [12]