Vaultwarden: Lightweight Bitwarden-Compatible Server

What Vaultwarden is

Vaultwarden is an alternative server implementation of the Bitwarden Client API, written in Rust and compatible with the official Bitwarden clients: the browser extensions, desktop apps, mobile apps and CLI. Its README pitches it as a good fit for self-hosted deployments where running the official, resource-heavy Bitwarden server might not be ideal. You run one small service (usually a single container), point your Bitwarden apps at your own domain, and keep your encrypted vault data on hardware you control.

The project was previously called Bitwarden_RS and was renamed to separate itself from the official Bitwarden server, to avoid confusion and trademark issues. It is explicitly not associated with Bitwarden, Inc. The disclaimer notes that one active maintainer is employed by Bitwarden and contributes on their own time, with those contributions reviewed by the other maintainers, and that the maintainers focus on serving the self-hosting community: individuals, families and small organizations.

Vaultwarden is licensed under AGPL-3.0. Its audience is self-hosters and homelab operators, small teams and families who want shared password management without a subscription to a hosted service, and developers who want a lightweight Bitwarden-compatible backend they can run next to their other services.

How it works

A Rust server behind the Bitwarden clients

Vaultwarden implements the API that official Bitwarden clients speak, so the clients do not know they are talking to a different server. It is built on the Rocket web framework. The container images bundle a modified build of the Bitwarden web vault from the separate bw_web_builds project, so the web UI is served by the same container and its version always matches the server.

Encryption happens in the clients. The web vault depends on the browser's Web Crypto API, which only works in a secure context, so the README is emphatic that the web vault requires HTTPS. The project recommends putting Vaultwarden behind a reverse proxy that terminates TLS rather than using Rocket's built-in TLS.

Storage

By default all data lives in a data directory, which you mount as a volume in Docker (the README mounts /vw-data/ to /data/). With the default SQLite backend, db.sqlite3 holds almost all state: users, organizations, devices and vault entries. File attachments and Send attachments are stored as separate files under attachments and sends. The rsa_key* files sign users' authentication tokens, icon_cache stores fetched website icons, and config.json exists only if settings were saved from the admin page.

A single image supports SQLite, MySQL/MariaDB and PostgreSQL backends since version 1.17.0. The container-image page says SQLite is the most widely used and tested backend and is recommended for most users. MySQL and PostgreSQL are selected by setting DATABASE_URL; for PostgreSQL the wiki gives the syntax postgresql://[[user]:[password]@]host[:port][/database].

Configuration

The configuration overview lists three ways to configure Vaultwarden: environment variables (recommended), an ENV_FILE that Vaultwarden reads itself (by default .env in the working directory), and a config.json managed through the admin page, which the wiki explicitly says is not recommended. Most options are documented in the repository's .env.template, with src/config.rs as the source of truth. Any option can be loaded from a file by appending _FILE, for example SMTP_PASSWORD_FILE=/run/secrets/smtp_password, which works with Docker secrets. Environment-configured containers must be recreated, not just restarted, for changes to take effect.

Email, invitations and notifications

Vaultwarden works without email, but several features depend on it. The SMTP page configures a mail relay with variables such as SMTP_HOST, SMTP_FROM, SMTP_PORT, SMTP_SECURITY, SMTP_USERNAME and SMTP_PASSWORD. SMTP_SECURITY replaced an older, mislabelled setting in v1.25.0 and defaults to starttls on port 587. When SMTP and invitations are enabled, invitations go out by email, and DOMAIN must be set to the instance's base URL so the invite links are correct; the wiki says invitation links stay valid for five days. It also warns that configuring an SMTP relay yourself isn't trivial and the mailer is not the easiest to troubleshoot, so an external mail service is often simpler.

For live updates, browser, desktop and extension clients receive WebSocket notifications when vault entries change. Since v1.29.0 these run on the main HTTP port and are enabled by default; the old WEBSOCKET_ENABLED and WEBSOCKET_PORT settings are ignored, and port 3012 support was removed in v1.31.0. Reverse proxies must pass the WebSocket Upgrade and Connection headers, which some, such as Traefik, do by default. Mobile apps don't use WebSockets; they rely on FCM and APNs, which Vaultwarden reaches through Bitwarden's push relay once you register an installation ID and key.

Image tags and updates

The vaultwarden/server image is multi-arch, so pulling it selects the right architecture automatically. The latest tag tracks the newest release and is recommended for most users; testing tracks the latest commits for early access; x.y.z tags pin a release; and latest-alpine or x.y.z-alpine are functionally the same but Alpine-based for a slimmer image. Older database-specific images under the bitwardenrs/ name still exist but the wiki says they will be removed and users should move to the unified image.

Key features

The README describes a nearly complete implementation of the Bitwarden Client API, including:

• Personal vault, Send and attachments. Standard vault items, Bitwarden Send for sharing text or files, and file attachments on items.
• Website icons and personal API keys. Icon fetching (cached locally) and per-user API keys.
• Organizations. Collections, password sharing, member roles, groups, event logs, admin password reset, Directory Connector support and policies.
• Two-factor authentication. Authenticator apps, email, FIDO2 WebAuthn, YubiKey and Duo.
• Emergency access. Bitwarden's trusted-contact emergency access feature.
• Admin backend. An /admin panel to configure the server, view and delete users and organizations, invite users even when registration is disabled, and generate a support string from a diagnostics page.
• Bundled web vault. A modified Bitwarden web vault ships inside the container images.
• Live sync. WebSocket notifications for browser, desktop and extension clients, enabled by default since v1.29.0 on the main HTTP port, plus optional mobile push notifications through Bitwarden's push relay.
• Multi-arch images on three registries. Images on ghcr.io, docker.io and quay.io, Debian-based by default with -alpine variants, and a testing tag that tracks the latest commits.
• Built-in backup command. Since 1.32.1, a vaultwarden backup command creates SQLite backups without needing a separate sqlite3 binary.

Getting started

The recommended installation is the container image. The README's Docker example pulls the image, sets the public DOMAIN, persists data under /vw-data/, and publishes the service only on localhost port 8000 so a reverse proxy can sit in front of it (you can substitute podman for docker):

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

The equivalent Docker Compose service from the README:

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

Next, put an HTTPS reverse proxy in front (the wiki maintains proxy examples), then register your account. Once your own accounts exist, the hardening guide recommends turning off open registration, which the wiki shows with SIGNUPS_ALLOWED=false. SIGNUPS_DOMAINS_WHITELIST can restrict sign-ups to specific email domains instead, and SIGNUPS_VERIFY=true requires email verification.

To enable the admin panel, set ADMIN_TOKEN. The wiki recommends storing it as an Argon2id PHC string rather than plain text, and Vaultwarden has a built-in generator. Via a temporary container:

docker run --rm -it vaultwarden/server /vaultwarden hash

For backups of the default SQLite database, the backup page shows the built-in command for Docker deployments:

docker exec -it vaultwarden /vaultwarden backup

or the SQLite CLI's online backup, which it describes as the best way to copy a live database:

sqlite3 data/db.sqlite3 ".backup '/path/to/backups/db-$(date '+%Y%m%d-%H%M').sqlite3'"

Run one of these from cron at least daily, the wiki suggests, and keep at least one copy off the machine. To turn on mobile push sync, request an installation ID and key from Bitwarden's hosting page and set PUSH_ENABLED=true with PUSH_INSTALLATION_ID and PUSH_INSTALLATION_KEY (plus EU relay URIs if you registered for bitwarden.eu).

Use cases

• Family or personal password manager. One instance on a home server or small VPS, with the official Bitwarden apps on every device and shared collections through an organization.
• Small-team credential sharing. Organizations with collections, groups, member roles and event logs for a startup or agency that wants self-hosted shared secrets.
• Homelab and edge hardware. Multi-arch images and a single process make it practical on ARM boards; the container page includes guidance for ARMv6 devices such as early Raspberry Pi models.
• Air-gapped or data-residency setups. Keeping the encrypted vault database and attachments on infrastructure you control, with optional PostgreSQL or MySQL if you already run one.
• Secure file and text sharing. Using Bitwarden Send from your own server for one-off credentials or files.
• Learning and testing Bitwarden clients. A lightweight backend for evaluating Bitwarden client features without deploying the full official stack.

How it compares

The obvious comparison is the official Bitwarden server, which the README calls resource-heavy for some self-hosted scenarios. Vaultwarden trades the official server's footprint for a single Rust service with SQLite by default, while keeping compatibility with the official clients. The trade-off is that Vaultwarden is an independent, community-maintained implementation: features land when the maintainers implement them, support comes from the Vaultwarden community rather than Bitwarden, and the README asks users to report bugs to Vaultwarden, not to official Bitwarden support channels, regardless of which client they use.

Compared with Bitwarden's hosted cloud service, self-hosting means you own uptime, TLS, backups, upgrades and email delivery. The container page stresses that staying current matters: Bitwarden controls client releases, mobile apps and browser extensions auto-update, and backward-incompatible client changes can break an outdated Vaultwarden server.

Things to know before adopting

• AGPL-3.0. If you modify Vaultwarden and offer it to users over a network, the AGPL requires you to make your modified source available to them. Running it unmodified for yourself or your organization raises no such obligation.
• HTTPS is mandatory in practice. The web vault needs a secure context for the Web Crypto API. The wiki recommends a reverse proxy with Let's Encrypt or Cloudflare-issued certificates over Rocket's built-in TLS, which the hardening guide quotes Rocket as calling not ready for production; it also says the mobile app needs properly configured OCSP stapling.
• Open registration by default. Anyone who can reach the instance can create an account until you set SIGNUPS_ALLOWED=false or a domain allow-list. Existing organization owners and admins can still invite users unless invitations are also disabled, and the admin can always invite.
• Password hints are shown. To support deployments without SMTP, Vaultwarden displays password hints on the login page; the hardening guide recommends disabling this because it can aid password-guessing.
• Admin token handling. ADMIN_TOKEN acts as the admin password, so hash it. Admin sessions are JWTs that last 20 minutes by default, and changing the token does not log out existing sessions; the wiki says deleting rsa_key.pem and restarting invalidates them, which also logs out every user.
• Sensitive files at rest. config.json can contain the admin token and SMTP credentials in plain text, and rsa_key.pem signs login tokens. Encrypt backups that include them.
• Backups are on you. The README disclaims liability for data loss and urges regular backups. The wiki advises against relying on filesystem or VM snapshots, says the Docker images include neither sqlite3 nor cron, and lists the database and attachments directory as required backups.
• Container runs as root by default. The hardening guide explains why and shows running as uid/gid 1000 with -u 1000:1000.
• Prefer a hostname over a bare IP. The hardening guide recommends strict SNI so the instance answers only on its domain, since IP addresses are continually scanned and instances reachable by IP are easier to find.
• Token in proxy logs. WebSocket notifications pass a JWT in the access_token query parameter, so the hardening guide recommends redacting it in reverse-proxy access logs.
• MariaDB client libraries. MySQL works, but builds use MariaDB client libraries; servers without default TLS may need MARIADB_TLS_DISABLE_PEER_VERIFICATION=1.
• Third-party packages lag. Community packages exist but may trail the latest version or configure things differently from the official images.

Project activity

As of November 2026 the dani-garcia/vaultwarden repository has about 70,400 stars and around 3,430 forks on GitHub. It was created in February 2018, is written in Rust and is licensed under AGPL-3.0. The latest release at the time of writing is 1.37.5, published on 1 November 2026, and the main branch was last pushed on 4 November 2026. Community support runs through Matrix, GitHub Discussions and a Discourse forum, and most operational documentation lives in the project's GitHub wiki.

The source and wiki are at github.com/dani-garcia/vaultwarden.