Vaultwarden self-hosted: a password vault you run yourself

Is this the same thing as Bitwarden?

No, and the difference matters when something goes wrong. Bitwarden makes the apps; Vaultwarden is a separate, open-source (AGPL-3.0) server that the apps happen to accept. Its README states that Bitwarden, Inc. has no connection to the project, and asks you to report problems to Vaultwarden's own forums and issue tracker, never to Bitwarden's support, even when the trouble shows up in a Bitwarden app.

What you get is a full vault for your household or small team: shared collections in organizations, file attachments, Send, emergency access and two-step login with an authenticator app, a security key or email. What you take on is the job of hosting it: a certificate, updates and backups. The sections below walk through each of those.

Before you start: your checklist

• A small Linux server that stays on. Vaultwarden runs as a single container and keeps everything in one SQLite file plus a few folders. Its wiki does not publish CPU or memory requirements.
• A domain or subdomain, such as vault.yourname.com. You will point it at the server so it can get a certificate.
• HTTPS. This is not optional. The web vault encrypts in your browser using the Web Crypto API, and browsers only allow that on secure pages. Self-signed certificates are a common cause of apps refusing to connect, so use a free Let's Encrypt one.
• Optionally, an email service with SMTP login, so the server can send invitations and two-step login codes. The Vaultwarden wiki suggests an outside service is easier than running mail yourself.

The server that fits

A password vault is the textbook small, steady job, and that is what a Cloud VPS is for. It is a virtual machine on one of our servers in New York, with its own operating system, one IPv4 address and an IPv6 /96, and root access for you. Pick the Docker app when you order and the machine arrives with Docker and Docker Compose ready; you take it from there over SSH. It is built on its own once your first payment clears, usually within a couple of minutes.

• A console in your browser for the day SSH will not answer, plus restart and reinstall from the dashboard.
• Email works through ports 465 and 587 from day one, which is what Vaultwarden's SMTP settings use. New machines keep port 25 shut.
• Only what the machine sends counts toward its monthly traffic. Syncing passwords is tiny.
• If you outgrow it, ask us to move you to a bigger size. It restarts once and keeps its files and IP addresses.

Up and running in an evening

1. In your domain's DNS, add an A record for your vault's name pointing at the VPS address.
2. SSH in as root. Make sure ports 80 and 443 can reach the machine: Caddy needs 80 to prove you own the name and 443 to serve the vault. Check that nothing else on the machine is already using ports 80 or 443 (ss -tlnp). If something is, stop it before starting Caddy.
3. Create a folder, say /opt/vaultwarden, and save the two files below in it, with your own domain and email address in place of the examples.
4. Start everything with docker compose up -d and watch with docker compose logs -f until Caddy reports a certificate.
5. Open https:// plus your vault's name, create your own account, and have each family member or colleague create theirs.

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: always
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"
    volumes:
      - ./vw-data:/data

  caddy:
    image: caddy:2
    container_name: caddy
    restart: always
    ports:
      - 80:80
      - 443:443
      - 443:443/udp
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy-config:/config
      - ./caddy-data:/data
    environment:
      DOMAIN: "https://vault.example.com"
      EMAIL: "admin@example.com"

{$DOMAIN} {
  tls {$EMAIL}
  encode zstd gzip
  reverse_proxy vaultwarden:80 {
    header_up X-Real-IP {remote_host}
  }
}

In each Bitwarden app, set the server URL to your vault's https address before signing in. Only Caddy is published to the internet; Vaultwarden listens on the private network Compose creates between the two.

Close the front door

Out of the box, anyone who finds your vault's address can register on it. Once your people have accounts, edit compose.yaml so it reads SIGNUPS_ALLOWED: "false", then repeat docker compose up -d. A plain restart is not enough: Compose bakes environment values into the container, so it has to be recreated.

• Invitations. Even with sign-ups closed, anyone who owns or administers an organization may invite new people. If you want nobody added except by you, also set INVITATIONS_ALLOWED: "false".
• The admin page. It only appears if you set ADMIN_TOKEN, and it can delete users. If you want it, let Vaultwarden's own hash command (run with docker exec) make one, type a long password twice, and use the $argon2id$... string it prints as the token. Inside compose.yaml, double every $ to $$ so Compose does not swallow them. You then sign in at /admin with the password you typed.
• Two-step login. Turn it on for every account. Without it, the hardening guide notes that master passwords can be guessed by repeated attempts.

Will you get your passwords back if the server dies?

Only if a copy lives somewhere else. Everything Vaultwarden knows sits in the vw-data folder: db.sqlite3 holds the vault itself, attachments holds uploaded files, and the rsa_key files keep everyone signed in. The wiki marks the database and attachments as must-haves, the keys and any config.json as recommended, and the sends and icon folders as optional.

1. Make a safe copy of the database while it runs, using the command built into the image since version 1.32.1. A straight file copy can catch it halfway through a write.
2. Schedule that from the server's own cron at least once a day, without -it, as in the second line below; the container has no scheduler of its own. Each copy lands in vw-data, ready to send off the server.
3. Send the backup, the attachments and the key files to another machine or to cloud storage, encrypted, because config.json can hold passwords in plain text.
4. Every few months, try a restore on a spare machine. The wiki's advice is blunt: do not count on VM snapshots as your backup.

# by hand
docker exec -it vaultwarden /vaultwarden backup

# in root's crontab, every night at 03:00
0 3 * * * docker exec vaultwarden /vaultwarden backup

When restoring, stop Vaultwarden first and remove any leftover db.sqlite3-wal file next to the restored database, or SQLite may try to replay it and damage the copy.

Keeping it current, and when to choose something else

Bitwarden's apps update themselves, and now and then they change in a way the server has to catch up with. Vaultwarden has no fixed release schedule, so a fix can take a while to arrive, and it only helps you once you install it. Run docker compose pull and docker compose up -d regularly. Your vault folder is untouched by the swap.

A VPS shares its physical server with other customers. If you would rather your passwords sat on a machine nobody else uses, the same two files run on a whole server of your own. And if you were also planning a family file drive, keep it on its own box; our Nextcloud workload explains what that one needs. Wherever it runs, what keeps strangers out is a good master password for every person, a second sign-in step on every account, and registration switched off.

Questions people ask

Will my Bitwarden browser extension work with Vaultwarden?

Yes. Vaultwarden implements the API the official Bitwarden clients use, so the extension, desktop and phone apps all connect once you set the server URL to your own address. If something misbehaves, ask the Vaultwarden community rather than Bitwarden's support team.

Can I skip the domain and use the server's IP address?

Not comfortably. The web vault needs HTTPS to run at all, and phones and browsers are fussy about certificates that are not issued by a trusted authority. A subdomain you already own, with a free Let's Encrypt certificate from Caddy, avoids all of that.

Is self-hosting safer than a hosted password manager?

It moves the responsibility to you. You decide where the data lives and who can register, but you also own updates, backups and the server's security. If you will not keep it patched and backed up, a hosted service is the safer choice.

Do I have to set up email?

No. Your vault works without it. You need SMTP for invitation emails and for codes sent by email, and on our Cloud VPS that goes out through port 587 or 465 to a mail service, since new machines keep port 25 shut.

What if I forget the admin page password?

Generate a new hash with /vaultwarden hash, put it in ADMIN_TOKEN, and recreate the container. The admin token only guards the admin page; it never unlocks anyone's vault, which stays protected by each user's master password.