Bitwarden

Last reviewed Aug 26, 2026 · 841 words

Run Vaultwarden unless you need something only the official server provides. Bitwarden's self-host package is the same stack the company runs in its cloud, which is both its strength and its cost: roughly a dozen containers including Microsoft SQL Server, a 2 GB RAM floor that feels more like 4 GB in practice, and an installer that wants a domain, an installation ID from bitwarden.com and a licence file before premium features light up. Vaultwarden runs the same clients from a single 128 MB container. The official server is the right answer for a specific set of people, and this guide is about working out whether you are one of them.

Who actually needs the official server

Three groups. Organisations that must run vendor-supported, third-party-audited software for compliance reasons, where "a community reimplementation in Rust" does not pass the auditor. Teams on Bitwarden's paid Teams or Enterprise plans who want SSO through their identity provider, directory sync and event logs, with support tickets that get answered. And people who are simply more comfortable running what Bitwarden itself ships and tests against every client release, so a new mobile app version never lands before the server understands it. If you are a household or a solo developer, none of those apply, and the rest of the password managers category is largely Vaultwarden territory for good reason.

What the installer actually deploys

Installation is a shell script from Bitwarden's help site. It prompts for your domain, whether to obtain a Let's Encrypt certificate, and an installation ID and key you generate at bitwarden.com/host, then writes everything under a bwdata directory and starts the stack:

./bitwarden.sh install
./bitwarden.sh start
./bitwarden.sh updateself && ./bitwarden.sh update   # later, for upgrades

What comes up is a set of containers: nginx on host ports 80 and 443, the web vault, the API, the identity service, SSO, the admin portal, icons, notifications, events, attachments, and MSSQL holding the data. It is a C# application end to end, which is why the footprint is what it is. Premium features on your own server require a paid Bitwarden account (Premium is about $10 a year and Families about $40, at last check) and uploading the licence file to the instance. Free accounts get the free feature set, exactly as in the cloud.

MSSQL is the RAM, and the unified image is the escape hatch

SQL Server is the single biggest reason the catalogue lists 2 GB and the "resource heavy" note; it idles at over a gigabyte on its own. Bitwarden's answer is the unified deployment: one bitwarden/self-host container that can use MySQL, PostgreSQL or SQLite instead of MSSQL and runs in a fraction of the memory. It has carried a beta label for a long time and Bitwarden's documentation is explicit that it is not the recommended production path. I would run it for a personal instance where I still wanted the official codebase, and not for the compliance-driven organisation from the first section, who should pay for the RAM.

The backup is bwdata, and the database dump inside it

Everything is in bwdata: environment files with secrets, certificates, attachments, and the MSSQL data directory. The stack runs its own nightly database backup into bwdata/mssql/backups, so the routine is to copy the whole directory off the machine on a schedule and keep a few days of those dumps. For a clean point-in-time copy, stop the stack first:

./bitwarden.sh stop
tar czf /backups/bwdata-$(date +%F).tar.gz bwdata
./bitwarden.sh start

The same rule as any password server applies: do one restore into a scratch VM this month. A backup that has never been restored is a hope, not a backup. The Vaultwarden guide covers the same discipline for the lighter server, and the client-side cache behaviour is identical: with the server down you can read your vault, not edit it.

Bitwarden against Vaultwarden, in one paragraph

Same clients, same encryption, same features for individuals. Vaultwarden: 128 MB, SQLite, one container, community-maintained, unsupported by Bitwarden, and it tracks client changes closely but not instantly. Official: 2 GB-plus, MSSQL, a dozen containers, vendor support and audits, enterprise SSO and directory sync. For someone leaving 1Password with a family and no compliance officer, that is not a close call.

What I'd do

Household or solo: Vaultwarden behind a reverse proxy, over a VPN, with nightly backups, and stop reading here. Small business with an auditor, or a team already paying for Bitwarden Enterprise: the official stack on a VM with 4 GB, the installer's Let's Encrypt option, nightly bwdata copies to two places, and the update command on a monthly reminder. Either way you get a password manager with public audits behind it and your vault on hardware you control, which beats every proprietary alternative on the axis that matters.