How to Self-Host a Password Manager with Vaultwarden

Why this matters

A password manager is the one service in your stack where an outage is not just inconvenient — it can lock you out of everything else. That sounds like an argument against self-hosting it. It’s actually the reason you should: the alternative is trusting a cloud service with the same data, and having no control when it goes down.

Vaultwarden is the self-hosted option that actually works, because it’s compatible with the official Bitwarden clients.

What I tested on

• OS: Debian 13 (trixie)
• Vaultwarden: 1.32.x (the vaultwarden/server Docker image)
• Reverse proxy: Caddy 2.8 with HTTPS
• Hardware: 2 GB RAM VPS
• Duration: daily driver for 11 months at the time of writing

⚠️ This is your most security-critical service. Before you start, read the “security” section below twice.

How I tested

I migrated my family’s passwords from a cloud manager into Vaultwarden, used it on three devices for a month, then deliberately restored from backup to confirm disaster recovery works. That last step is the only one that matters.

Step 1: The compose file

services:
  vaultwarden:
    image: vaultwarden/server:1.32
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://pass.example.com"
      ADMIN_TOKEN: "openssl rand -hex 32"
      SIGNUPS_ALLOWED: "false"
    volumes:
      - ./vw-data:/data
    depends_on: [caddy]

SIGNUPS_ALLOWED: "false" is not optional for a private install. Turn it off after creating your account.

Step 2: HTTPS is not optional

The browser extension and mobile apps refuse to talk to anything but HTTPS (except localhost). Use a reverse proxy:

pass.example.com {
    reverse_proxy vaultwarden:80
}

Caddy handles Let’s Encrypt automatically. If you skip this, you’ll spend an hour debugging “cannot connect” errors that are actually certificate errors.

Step 3: Create your account and lock signups

1. Visit https://pass.example.com and create your account
2. Log in once to confirm it works
3. Set SIGNUPS_ALLOWED=false and redeploy
4. Create an emergency sheet: write down the master password and the 2FA recovery code, print it, and store it somewhere physical

Step 4: Back it up

# Stop the container, copy the data dir, restart
docker compose stop vaultwarden
tar czf /backup/vw-$(date +%F).tar.gz vw-data/
docker compose start vaultwarden

Test the restore once. A backup you’ve never restored from is a hope, not a backup.

Security: the mistakes that actually hurt people

1. Exposing it directly. Always put it behind a reverse proxy, never -p 80:80 on the container.

2. Weak admin token. Use a real random string, not a word.

3. No 2FA on the admin panel. Enable it. The admin panel can delete everything.

4. Forgetting the master password. There is no recovery. None. Write it down.

5. Letting anyone sign up. SIGNUPS_ALLOWED=true on a public server means strangers will create accounts and fill your disk.

The backup problem nobody thinks about first

A password manager is the one service where losing the server is worse than losing the disk: the vault, the attachments and the 2FA seeds all live in one database and one directory. If you cannot restore it, you cannot log in anywhere — including the account you would need to rebuild it.

Three things have to be true before you trust this with your real passwords:

The data/ directory is backed up, not just the database. Vaultwarden stores attachments and rsa_key files alongside SQLite. Back up the whole volume, not a sqlite3 .dump.

The master password is stored somewhere that is not the vault. Obvious, and the number of people who discover they cannot restore because the password lived only in Bitwarden is not zero. Paper in a drawer is acceptable; it is in my backup routine for exactly this reason.

A restore has been tested. Stop the container, restore to a scratch directory, start a second instance on a different port, log in with the old master password. If that works once, you are safer than 95% of self-hosters.

One more: keep a current export. Vaultwarden’s admin panel can produce an encrypted JSON export, and it is the only thing that saves you if the container’s database is corrupted in a way that snapshots also captured.

The vault sits behind the same reverse proxy as everything else, so the TLS and header work is the part described in the Caddy walkthrough — a password manager is the last service you want reachable over plain HTTP on a LAN address.

Pros and cons

Pros:

• Compatible with official Bitwarden apps — the clients are genuinely good
• Tiny resource footprint (under 50 MB RAM idle)
• End-to-end encryption: the server never sees your passwords in plaintext
• Self-hosted, so your password vault lives on your hardware

Cons:

• You are now your own support team when something breaks
• Updates are your responsibility
• If your server dies and you have no backup, you lose everything — there’s no cloud fallback

Best for / Skip if

Best for: self-hosters who are comfortable with Docker, backups, and the reality that “I manage this now.”

Skip if: you’re not confident you can keep a server running and backed up. Use the hosted Bitwarden or 1Password instead — that’s not failure, it’s being honest about where your skills are.

Alternatives

• Bitwarden (official server) — the full product, heavier and more resource-hungry
• Passbolt — team-oriented, open source, but no official mobile app that matches Bitwarden’s
• KeePassXC — file-based, no server, excellent if you don’t need sync

Verdict

Vaultwarden is one of the few self-hosted services where the trade-off genuinely favours self-hosting: you get a better product (Bitwarden’s clients) on your own hardware, for almost no resources. But treat the security and backup sections as part of the install, not optional reading — because unlike your other services, an outage here has consequences.

References

• Vaultwarden GitHub repository — source, releases, and deployment notes
• Bitwarden help center — client configuration and security model