Self-Hosting Vaultwarden: Setup and Real Costs

Every login I own lives in a container I built myself, on a box in my own house. No monthly bill, no company deciding to raise my price overnight, no breach notice from someone else's cloud. That's the pitch for self-hosting a password manager. It's also, I'll admit up front, not free — it's just a different bill.

I run Vaultwarden in Docker on my Proxmox homelab, and I've been asked often enough "should I just do this too?" that it's worth answering honestly: what it is, the real setup, the parts people underestimate, and what it actually costs once electricity and your own time stop being free.

TL;DR

Vaultwarden is an unofficial, Rust-written server that speaks the same API as Bitwarden — official clients connect to it without knowing the difference.
It unlocks Bitwarden Premium features for everyone, free, because it has no billing system at all.
HTTPS is not optional. Bitwarden's own clients refuse to talk to a non-secure server, full stop.
The sqlite database is your entire vault. Back it up properly or lose everything in one bad disk failure.
Priced honestly — hardware, power, a domain — self-hosting is not automatically cheaper than paying for Bitwarden Premium. It's a control trade, not a savings trade.

What Vaultwarden actually is (and isn't)

Vaultwarden started life as `bitwarden_rs`, an unofficial reimplementation of the Bitwarden server API written in Rust, maintained by a small community team on GitHub. It's not affiliated with Bitwarden, Inc. — though one maintainer happens to also work there, contributing on their own time.

The reason it exists: the official self-hosted Bitwarden server is a full multi-container stack (database, API, identity, admin, web vault) that Bitwarden's own docs recommend running with at least 2 GB of RAM. Vaultwarden is one small binary that runs comfortably in under 256 MB, easily on a Raspberry Pi.

KEY-STAT: 256 MB — RAM Vaultwarden needs, versus 2 GB+ recommended for the official multi-container Bitwarden server

The bigger reason people actually pick it: Vaultwarden has no concept of a paid tier. Every account it serves reports back to Bitwarden's official apps as "premium," so things Bitwarden normally charges for — built-in TOTP codes, file attachments, emergency access, full organizations for sharing with family — are just on, for free, for anyone who deploys it. Nothing to configure, nothing to unlock.

It talks the same protocol Bitwarden's real apps expect, so your phone, browser extension, and desktop app all connect to it exactly like they would to bitwarden.com — you just point them at your own domain instead.

My docker-compose: the real setup

This is close to what actually runs in my homelab, trimmed to the parts that matter. It assumes a reverse proxy in front (Caddy, in my case) handling the TLS certificate — more on why that's non-negotiable in a second.

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "false"
      WEBSOCKET_ENABLED: "true"
      ADMIN_TOKEN: "${VAULTWARDEN_ADMIN_TOKEN}"
    volumes:
      - ./vw-data:/data
    ports:
      - "127.0.0.1:8080:80"

  caddy:
    image: caddy:2
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data

volumes:
  caddy_data:

A few lines trip people up. `SIGNUPS_ALLOWED: "false"` matters the moment you go public — leave it `true` and anyone who finds your domain can register a vault on your server. `ADMIN_TOKEN` gates the `/admin` panel and should be a long, random value from an environment file, never hardcoded. Vaultwarden's own Docker Compose wiki page is the primary reference if you're adapting this — it changes with releases.

Vaultwarden binds only to `127.0.0.1:8080`, unreachable directly. Caddy is the only container facing the network, terminating TLS and proxying in. If you're deciding whether a service like this belongs in a VM or a container in the first place, that split is covered in Proxmox vs Docker: what to run where.

HTTPS is not optional

This is the part people skip in a hurry and then can't figure out why nothing works.

Warning

Bitwarden's browser extensions and apps will refuse to connect to a server that isn't served over HTTPS (localhost is the one exception). This isn't a Vaultwarden quirk — it's because the Web Crypto APIs the clients rely on for encryption only run in a secure browser context. No cert, no vault, no exceptions.

The `DOMAIN` environment variable has to be the literal `https://` URL your clients will actually use — not a bare hostname. Get that wrong and attachments, icons, and some client features quietly misbehave even if login technically works.

The realistic path is a reverse proxy that automates certificates: Caddy (what I use, because it issues and renews Let's Encrypt certs with almost no config), Nginx Proxy Manager, or Traefik. Set it up and get a valid cert before you create a single account — retrofitting HTTPS onto a vault you're already using is a needless risk window.

Backups: your vault is one bad disk from gone

Vaultwarden stores almost everything in a single `db.sqlite3` file, plus a separate `attachments/` folder and your RSA key files for token signing. Lose the sqlite file and you lose every saved login, full stop — there's no cloud copy sitting behind it the way there would be with hosted Bitwarden.

Tip

Don't just `cp` the live database file. SQLite keeps `-wal` and `-shm` sidecar files alongside it while running, and a raw copy can grab them mid-write and hand you a corrupted backup. Use Vaultwarden's own `docker exec -it vaultwarden /vaultwarden backup` command, which writes a clean, consistent snapshot — or SQLite's own `.backup` command, which does the same thing safely.

My backup covers the sqlite snapshot, the `attachments/` and `sends/` folders, `config.json`, and the RSA key files — the same set the community's backup guidance walks through. All of it goes to encrypted offsite storage, not just a second folder on the same box, because a backup that lives on the same disk as the original protects you from exactly nothing if that disk dies.

How exposed should it be

There are really two honest choices here, and the "right" one depends on how much friction you're willing to accept for how much attack surface you're willing to remove.

LAN-only plus a tunnel. Vaultwarden never touches the public internet directly. You reach it only over a WireGuard tunnel back into your home network — from your phone on mobile data, it looks like it's on your LAN. Smallest possible attack surface, zero public listening ports on your vault. The trade-off versus the older standard is covered in WireGuard vs OpenVPN: which to self-host — WireGuard is the one I'd pick for exactly this use case: light, fast to reconnect, easy on a phone's battery.

Public with a reverse proxy. You open 443, Caddy terminates TLS, and the vault is reachable from anywhere without a VPN client first. More convenient — family members who won't install a WireGuard app can just open a browser. More surface, though: your admin token and login form are internet-facing, so rate limiting and disabling public signups stop being optional.

I run the tunnel for myself and only expose the login publicly for the family accounts sharing the organization. Neither answer is wrong; picking blind is.

Keeping it patched

Vaultwarden ships frequent releases, and unlike a SaaS vault, nobody patches it for you. `docker compose pull && docker compose up -d` on a schedule is the whole update — but "on a schedule" needs to mean something real: a cron job, a calendar reminder, or Watchtower pulling new images automatically. An unpatched, internet-facing vault is worse than the SaaS option you were trying to avoid.

What self-hosting actually costs

Here's the part most self-hosting posts skip: "free software" still runs on hardware that draws power, needs a domain to be reachable by name, and eats your Saturday afternoons when something breaks. Bitwarden Premium isn't free either anymore — Bitwarden roughly doubled its Premium price in January 2026, from $9.99 to $19.80 a year.

Rough numbers below, using a typical low-power N100 mini PC (about 7 W idle) and Germany's average 2026 household electricity price of roughly €0.35/kWh:

Cost item	Dedicated mini PC just for this	Add-on to an existing homelab box	Hosted Bitwarden Premium
Software license	€0	€0	~€19.80/yr
Hardware (amortized, ~5 yrs)	~€30–40/yr	€0 (already sunk)	€0
Electricity (7 W, 24/7, €0.35/kWh)	~€21/yr	~€21/yr (marginal)	€0
Domain (.com, at-cost registrar)	~€10/yr	~€10/yr	€0
TLS certificate	€0 (Let's Encrypt)	€0 (Let's Encrypt)	€0
Offsite backup storage	~€6–12/yr	~€6–12/yr	included
Rough total / year	~€67–83	~€37–53	~€19.80

Read that table straight: on pure cash, hosted Bitwarden Premium is cheaper than self-hosting, even in the best case. What you're buying with the extra euros is full data ownership, every premium feature unlocked with no upsell, and a vault that answers to nobody's pricing decisions but your own — not a lower bill.

That math only flips if the box is already running 24/7 for other things you'd run anyway — which, if you've read our homelab beginner's guide, describes most homelabs a few months in. At that point Vaultwarden is a free extra service on hardware you were already paying to keep on.

Who this is genuinely for — and who should just pay

Self-host Vaultwarden if you already run a homelab for other services, you're comfortable with Docker and Linux basics, and you'll actually do backups and updates — not "plan to." It's also right if you specifically want every Bitwarden Premium feature free, with your vault's fate tied to nobody's billing decisions but your own.

Just pay for Bitwarden, 1Password, or a similar dedicated manager if you don't already have always-on hardware, don't want uptime and patching to be your problem, or know honestly that backup discipline isn't a habit you'll keep. A paid vault with automatic redundancy beats a self-hosted one that silently rots. For the fuller head-to-head across Bitwarden, 1Password, KeePassXC and Dashlane, see our dedicated comparison.

Frequently asked questions

Is Vaultwarden safe to trust with real passwords?

Yes, for the encryption itself — it speaks Bitwarden's protocol, so your vault is encrypted client-side before it ever reaches the server, same as official Bitwarden. The risk it adds is operational, not cryptographic: you're now responsible for HTTPS, timely updates, and backups that a managed service would otherwise handle for you.

Can I run Vaultwarden without exposing it to the internet at all?

Yes, and it's the lower-risk option. Bind it to a private network and reach it only over a WireGuard tunnel; your apps behave exactly as if you were on your home LAN, and the vault never has an open port facing the public internet.

What happens if my home server dies — do I lose every password?

Only if your backups were also on that box, or nonexistent. A clean, offsite backup of the sqlite database, attachments, and key files — taken with Vaultwarden's own backup command rather than a raw file copy — lets you restore the entire vault on new hardware in minutes.

Is Vaultwarden really free, or are there hidden costs?

The software itself is free and unlocks every Bitwarden Premium feature at no charge. The real costs are the always-on hardware, its electricity, a domain if you want it reachable by name, and your own time for updates and backups — none of which show up on a "free software" claim but all of which are real.