Vaultwarden - Lightweight Self-Hosted Bitwarden Compatible Server

Vaultwarden calls itself “An alternative server implementation of the Bitwarden Client API, written in Rust,” built for the case where “running the official resource-heavy service might not be ideal.” It is AGPL-3.0 licensed. The official Bitwarden apps and browser extensions talk to it unchanged — you point them at your own URL.

The “lightweight” claim is the one worth checking, because it is the entire reason the project exists. The container registry answers it precisely.

What the registry says

Querying Docker Hub for the published tags while writing this:

vaultwarden/server:alpine — 60.3 MB
vaultwarden/server:latest (the standard tag) — 80.4 MB
Architectures on both: linux/amd64, linux/arm64, linux/arm/v7 and linux/arm/v6
Pull count on the repository: 343 million

The armv6 build is the detail that proves the point. That is the architecture of the original Raspberry Pi and the Pi Zero — hardware with 512 MB of RAM. A password server you can run on a device that costs less than a meal is a materially different proposition from one that needs a database server, and it explains why the project reached 343 million pulls without being the official anything.

Four architectures also means the box you already own almost certainly qualifies, which removes the usual excuse for leaving a password vault in someone else’s hands.

Two disclaimers that are not boilerplate

The README carries two statements that deserve more weight than readers usually give them.

“This project is not associated with Bitwarden or Bitwarden, Inc.”

“We cannot be held liable for any data loss that may occur while using Vaultwarden.”

The first is a legal clarification, but it has a practical edge: when a Bitwarden client update changes an API, compatibility is maintained by Vaultwarden’s maintainers catching up, not by the vendor coordinating with them. In practice this has worked well for years. It is still a dependency on volunteer responsiveness rather than a contract.

The second is the one that should change your behaviour. A password vault is the single worst thing to lose, and it is also the thing most likely to be running on the cheapest hardware in your house, on an SD card, with no backup, precisely because it was so easy to install.

So the backup is the project

If you take one action after reading this, make it this one: back up the data volume before you migrate a single credential into it.

The documented run command mounts /vw-data/ as the data directory, so your backup unit is that one path. Snapshot it off the host and encrypt it where it lands — Kopia is a reasonable fit because it does end-to-end encryption and deduplication, and a vault database that changes slightly every day deduplicates well. The failure mode to design against is not a hack; it is an SD card wearing out on a Tuesday.

Test the restore, too. A backup of a vault you have never restored is a guess.

The network detail in the official command

The README’s own docker run example contains a decision that is easy to undo by accident:

--publish 127.0.0.1:8000:80

It binds to localhost, not to every interface. That is deliberate: Vaultwarden expects to sit behind a reverse proxy that terminates TLS, because the Bitwarden clients require HTTPS and because a vault on a plain HTTP port on the open internet is indefensible.

The temptation, when the web vault does not load from another machine, is to change that to --publish 8000:80 and move on. Do not. Put a proxy with a real certificate in front of it. This is the same class of mistake as opening a setup wizard’s port to finish an install — convenient for five minutes, permanent if you forget.

Also set DOMAIN correctly, as the example does. Several client features depend on the server knowing its own public URL.

Who this is for

Vaultwarden fits anyone who wants Bitwarden’s clients with their own storage, on hardware they control, without running a multi-service stack. It is a particularly good fit for a household or a small team: one small container, the official apps, no per-seat pricing.

It is the wrong choice if you need a vendor to be accountable to you. An organisation with a compliance obligation should buy the official product precisely because of the first disclaimer above — that is what the money is for.

The finding, stated plainly: “lightweight” is verifiable and generous — 60 MB and an armv6 build — and the project’s own liability disclaimer means the hard part of the deployment is not installing it but backing it up. Budget your effort accordingly, and if you are assembling a wider toolkit, the security resources roundup covers the surrounding practice.