Vaultwarden: a Rust reimplementation of the Bitwarden server for self-hosted vaults

The problem Vaultwarden solves, and who it is written for

The README frames the project in one sentence: it is "perfect for self-hosted deployment where running the official resource-heavy service might not be ideal." That is the whole pitch. Bitwarden's clients are open source and widely used; the server side that they talk to is a heavier stack. Vaultwarden reimplements the Bitwarden Client API in Rust so those same clients can point at a server you run yourself, on hardware that would not comfortably host the official service.

The audience follows from that. It is a single operator or a small team that already runs containers, has a domain and a TLS certificate, and wants password sync without renting a managed service. The README is explicit that the result is compatible with "official Bitwarden clients", with a disclaimer link attached to that phrase. That disclaimer matters: this is not Bitwarden, it is a reimplementation, and the project asks users to report bugs to it rather than to Bitwarden's support channels. If you need a vendor to call, this is not that product.

What the Bitwarden Client API compatibility actually covers

The feature list is longer than the phrase "password manager" suggests. Beyond the personal vault, the README lists Send, attachments, website icons and personal API keys. Organizations are implemented with collections, password sharing, member roles, groups, event logs, admin password reset, directory connector and policies. Multi-factor and two-factor authentication covers authenticator apps, email, FIDO2 WebAuthn, YubiKey and Duo. Emergency access is listed too.

Two items on that list are worth pausing on. The admin backend is a Vaultwarden-specific surface, documented in the project wiki under enabling the admin page, not part of the Bitwarden API. And the web vault shipped in the containers is a "modified Web Vault client" built from the project's own bw_web_builds repository, not the upstream build. So the browser experience is a fork maintained alongside the server, which is a maintenance dependency you inherit whether or not you use it.

What the README does not claim is parity with the hosted Bitwarden service. Features that exist only in the commercial product are simply absent from this list, and the README does not enumerate them. Treat the list as the boundary of what is documented, not as a promise about everything the clients can ask for.

Installing Vaultwarden with Docker and reaching the admin page

The README calls container images the recommended install path and publishes them to ghcr.io, docker.io and quay.io. The CLI example pulls the image and runs it with a data volume, a published port bound to localhost, and the DOMAIN environment variable set to the public HTTPS address.

docker pull vaultwarden/server:latest
docker run --detach --name vaultwarden \
  --env DOMAIN="https://vw.domain.tld" \
  --volume /vw-data/:/data/ \
  --restart unless-stopped \
  --publish 127.0.0.1:8000:80 \
  vaultwarden/server:latest

After this, the container listens on port 80 inside the container, mapped to 127.0.0.1:8000 on the host. Nothing is exposed to the network yet, which is deliberate: the README suggests a reverse proxy and links to proxy examples in the wiki. Persistent state lives under /data/, mounted here from /vw-data/. If you lose that directory you lose the vault.

The Compose variant is the same configuration in a file, and is easier to keep in version control.

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vw.domain.tld"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8000:80

The README does not document the admin page's URL or the token variable used to enable it; it points to the wiki page "Enabling admin page" for that. Do not guess the path. Read the wiki entry before you expose anything, because the admin surface is the part of the deployment with the widest blast radius if it is misconfigured.

If you would rather not use containers, the README says you can build the binary yourself, again linking to a wiki page, and notes community-maintained packages that "might be lagging behind the latest version or might deviate in the way Vaultwarden is configured."

HTTPS is not optional, and that rules some deployments out

The README's usage note is blunt: the web vault requires HTTPS and a secure context for the Web Crypto API, so it "will only work if you enable HTTPS." A reverse proxy is suggested. This is the single constraint that decides whether Vaultwarden is the right tool for a given setup.

It also means the localhost port binding in the examples is not a stylistic choice. You put a proxy in front, terminate TLS there, and set DOMAIN to the public HTTPS URL. People searching for how to use Vaultwarden without HTTPS are asking for something the documentation says will not work for the web vault. Native clients may behave differently, but the README makes no such distinction, and I would not plan a deployment around the assumption that they do.

A second constraint follows from the first: the certificate has to be valid for the clients you use. Self-signed certificates and clients that validate certificate chains are a common source of confusion, and the README does not address it. The wiki's proxy examples are the place to look.

Where Vaultwarden is the wrong choice

The clearest case against it is support. The README's important note asks users to report bugs and suggestions to the project and states plainly: "DO NOT use the official Bitwarden support channels." If your organisation needs a vendor contract, a support SLA, or someone to escalate to when the vault is down, Vaultwarden provides none of that. Support runs through Matrix, GitHub Discussions and the Discourse forum, all volunteer channels.

The second case is feature scope. The README lists what is implemented; it does not promise that every Bitwarden client feature maps onto the server. Anything outside that list is undocumented here, and the honest position is that you should test the specific clients and flows you depend on before committing.

The third case is operational. This is a server you run. Backups of /data/, certificate renewal, proxy configuration and version upgrades are yours. The project publishes releases, but the README does not describe a rollback procedure or a migration path between versions, so the upgrade story is thinner than the install story. Plan for that before you put a family or a team on it.

Vaultwarden against running the official Bitwarden server

The obvious alternative is the official Bitwarden server, which the README itself contrasts with by calling Vaultwarden an "alternative server implementation" suited to deployments where the official service is too resource-heavy. The difference is not a feature checkbox; it is who maintains the server and what you get when it breaks. The official server comes from the vendor whose clients you are using, so compatibility is the vendor's problem. With Vaultwarden, compatibility is the project's problem, and the project's own disclaimer link is a reminder that it is unofficial.

A second alternative is not self-hosting at all: using Bitwarden's hosted service, or another hosted password manager. That removes the reverse proxy, the certificate, the /data/ volume and the upgrade cycle entirely. Vaultwarden is worth its operational cost only if control of the server is something you actually want, not merely something that sounds appealing.

Between those poles, the practical question is whether you need the parts of Bitwarden that Vaultwarden's README does not list. If you do, the official server is the only path. If you need the personal vault, Send, attachments, organisations, two-factor and emergency access, the README says those are implemented.

Maintenance cost, release cadence and the AGPL-3.0 licence

The repository is not archived, and the last push was on 2026-08-22, the same date as the 1.37.2 release. Before that, 1.37.1 landed on 2026-07-29 and 1.37.0 on 2026-07-24. Three releases in about a month, then a gap to the last push. That is a real cadence, and it also means the container tag you pin will go stale if you never revisit it.

Upgrades are container pulls. The README does not document a rollback procedure, a downgrade path, or what happens to the database schema between versions. The repository does contain a migrations/ directory and a diesel.toml, which tells you schema migrations exist, but the README does not explain how they run or whether they are reversible. Back up /data/ before pulling a new tag; that is the only safety net the documentation gives you.

The licence is AGPL-3.0-only, per both the repository metadata and Cargo.toml. If you run Vaultwarden for yourself or your organisation, that is a normal self-hosting situation. If you intend to offer it to others as a service, or to modify and redistribute it, the network-copyleft terms of the AGPL are the thing to read, and the README does not discuss them. This is a description of the licence, not legal advice; talk to someone qualified before building a product on it.

Editorial conclusion

Adopt Vaultwarden if you want a Bitwarden-compatible server you control, you are comfortable running a container behind a reverse proxy with a real TLS certificate, and you accept that support comes from the project's own Matrix room, GitHub Discussions and Discourse forum rather than Bitwarden. Do not adopt it if you need official vendor support, an uptime commitment, or a feature the README does not list. Before you migrate anything, confirm three things: that your chosen client works against the server in a test account, that /data/ is on storage you actually back up, and that your reverse proxy terminates HTTPS on the domain you put in DOMAIN, because the bundled web vault will not work without a secure context.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes