Self-host your password manager: Bitwarden server or Vaultwarden

Official Bitwarden server vs Vaultwarden

Both run the same client apps against a server you control. They differ in who builds the server and what it costs to run.

The official Bitwarden server is the AGPL-3.0 code Bitwarden Inc. runs for its cloud. It installs with the bitwarden.sh script from Bitwarden’s Linux install guide, needs a free installation ID and key from bitwarden.com/host, and starts around a dozen containers including MS SQL Server. A newer unified image, which Bitwarden still documents as beta, packs everything into one container and supports lighter databases. Premium and organisation features need a licence file from a paid hosted account.

Vaultwarden (dani-garcia/vaultwarden) is a community reimplementation of the API in Rust: a single vaultwarden/server container, SQLite by default (MySQL and PostgreSQL optional), a few tens of megabytes idle, and most Premium features, including TOTP, attachments, emergency access and organisations, without a licence. It is unofficial and unsupported by Bitwarden Inc.

Choose the official server for a business that needs support and audited code, Vaultwarden for a household, lab or small team where you are the administrator. The rest of this guide is mostly Vaultwarden, with the official quick start summarised near the end. If you first want to know whether the hosted service is trustworthy, read is Bitwarden safe.

Vaultwarden quick start

You need a Linux host with Docker and a DNS name pointing at it. The steps match the HowTo summary above.

1. Start the container. The volume holds everything: database, attachments and keys. Binding to 127.0.0.1 keeps port 8080 off the network; only the reverse proxy reaches it.

docker run -d --name vaultwarden -v /vw-data/:/data/ --restart unless-stopped -p 127.0.0.1:8080:80 vaultwarden/server:latest

2. Put HTTPS in front with Caddy or another reverse proxy (next section).
3. Set DOMAIN to your HTTPS URL, open it in a browser and create the first account. DOMAIN must be right before accounts exist, because attachment links, email links and WebAuthn all derive from it.
4. Disable signups and set an admin token, then recreate the container with the new environment.
5. Point the clients at the server and schedule backups, both covered below.

The same setup as Compose, which is easier to maintain as the environment grows:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "false"
      ADMIN_TOKEN: "replace-with-a-long-random-value-or-argon2-hash"
      SMTP_HOST: "smtp.example.com"
      SMTP_PORT: "587"
      SMTP_SECURITY: "starttls"
      SMTP_FROM: "vaultwarden@example.com"
      SMTP_USERNAME: "vaultwarden@example.com"
      SMTP_PASSWORD: "your-smtp-app-password"
    volumes:
      - ./vw-data:/data
    ports:
      - "127.0.0.1:8080:80"

Start it with docker compose up -d. Set SIGNUPS_ALLOWED to "true" for the first run, create your account, change it to "false" and run docker compose up -d again.

HTTPS with a reverse proxy

HTTPS is not optional. The clients encrypt and decrypt with the browser’s Web Crypto API, which is only available in a secure context: https:// or localhost. Over plain HTTP the web vault fails to load and the apps refuse to log in.

Caddy is the shortest path because it obtains and renews Let’s Encrypt certificates on its own. Install Caddy on the host and use this Caddyfile:

vault.example.com {
    reverse_proxy 127.0.0.1:8080
}

Reload Caddy and open https://vault.example.com. Caddy proxies the WebSocket connection the clients use for live sync without extra configuration. For nginx or Traefik, the Vaultwarden wiki has tested configurations; forward WebSocket upgrades and pass X-Real-IP so rate limiting sees the client rather than the proxy. A server that is only reachable at home or over a VPN still needs a valid certificate: use Caddy’s DNS challenge, or a private CA trusted on every device.

Configuration: environment variables, admin token, email

The variables that matter on day one:

• DOMAIN=https://vault.example.com: the public URL, with scheme, no trailing slash.
• SIGNUPS_ALLOWED=false once your accounts exist. To add family members later, set it to true briefly, invite them from an organisation, or use SIGNUPS_DOMAINS_WHITELIST for an email domain you control.
• ADMIN_TOKEN: enables the /admin page for managing users, viewing diagnostics and editing settings. Generate a plain token, or better an Argon2 hash so the secret is not readable from the config.

openssl rand -base64 48

docker exec -it vaultwarden /vaultwarden hash

The hash command asks for a password and prints an ADMIN_TOKEN='$argon2id$...' line. In a Compose file, double every $ to $$ or Compose will try to expand them. If you do not need the admin page, leave ADMIN_TOKEN unset and it stays disabled.

• SMTP (SMTP_HOST, SMTP_PORT, SMTP_SECURITY, SMTP_FROM, SMTP_USERNAME, SMTP_PASSWORD): required for email verification, emergency access and organisation invitations, and new-device alerts. An app password on a mailbox you own is enough. Test with Send test email on the admin page. Every other variable is documented in .env.template in the Vaultwarden repository.

Point the clients at your server

Every Bitwarden client can target a different server; accounts there are entirely separate from bitwarden.com.

• Desktop app, browser extension, mobile apps: on the login screen open Logging in on, choose Self-hosted, enter https://vault.example.com in Server URL, save, then log in. Extension setup is covered in the browser extension guide.
• Web vault: open your URL. Vaultwarden serves the official web vault build.
• CLI: log out if needed, set the server, log in. Details in the CLI guide.

bw config server https://vault.example.com

Moving from the hosted service: export from vault.bitwarden.com as password-protected encrypted JSON, import through Tools, Import data on your server, then delete the file.

Backups

The /data directory is the whole server. Losing it without a backup means losing every password, so backups are part of the install, not a later improvement.

• Database: with the container running, use SQLite’s online backup rather than copying db.sqlite3 directly, which can capture a half-written file.

sqlite3 /vw-data/db.sqlite3 ".backup /backups/db-$(date +%F).sqlite3"

• Everything else: attachments/, sends/, config.json (settings changed on the admin page) and the rsa_key* files. Without the RSA keys every client is logged out after a restore and must sign in again. Copying the entire volume with the container stopped is the simplest complete backup.
• Offsite and encrypted: the vault is ciphertext, but a stolen backup still allows offline guessing against a weak master password. Encrypt with age or restic and keep a copy elsewhere.
• Test a restore on a second container at least once. A backup you have never restored is a hope.

Run it nightly from cron or a systemd timer and keep several generations.

Updates

Vaultwarden releases often, and its bundled web vault follows Bitwarden’s client releases. Update by pulling and recreating:

docker compose pull && docker compose up -d

Read the release notes on GitHub first: migrations run automatically, but a few releases have renamed settings or required a minimum client version. Keep the apps current too; the releases page shows the current client version.

Official server quick start

If you chose the official server, the outline is short. Create a bitwarden user with Docker access, then as that user:

curl -Lso bitwarden.sh https://go.btwrdn.co/bw-sh && chmod 700 bitwarden.sh

./bitwarden.sh install

The installer asks for your domain, whether to use Let’s Encrypt, and the installation ID and key from bitwarden.com/host. Edit bwdata/env/global.override.env for SMTP and admin settings, then:

./bitwarden.sh start

Updating is ./bitwarden.sh updateself followed by ./bitwarden.sh update. Back up the bwdata directory. The complete documentation is at bitwarden.com/help.

Security checklist, and who should not self-host

• Expose only 443 (and 80 for certificate challenges). Keep 8080 bound to 127.0.0.1 and use the host firewall.
• Protect /admin: a long token, fail2ban on Vaultwarden’s log file (set LOG_FILE and EXTENDED_LOGGING=true), and consider restricting the path to your VPN or home IP in the proxy.
• Remove ADMIN_TOKEN when you are not using the admin page.
• Turn on two-step login for every account and keep recovery codes outside the vault.
• Keep signups closed, and keep the host, Docker, proxy and container current.
• Automate encrypted offsite backups and test a restore.

Self-hosting is right when you want the data on hardware you control and are willing to be the operator. It is wrong if you will not do backups and updates, if the household depends on the vault while you are away, or if a single disk failure would take the only copy. In those cases the hosted service, free for individuals and audited, is the safer option; the one-command install on this site sets up the client for it.