Self-host Vaultwarden on a VPS.
Your own Bitwarden-compatible vault, in 30 minutes.
Vaultwarden is the lightweight, Rust-based, Bitwarden-compatible password server. Five Docker commands, one HTTPS reverse proxy, one backup cron — and the credential vault of every account you own lives on metal you rent, not on infrastructure you trust.
- 01
Vaultwarden is Bitwarden-compatible at the wire and vault level — every official client just works. Runs in 50–100 MB of RAM; any VPS handles it.
- 02
The vault is client-side AES-256 encrypted. The server never sees your master password. Compromising the VPS yields an encrypted blob, not credentials.
- 03
The non-obvious step is the metadata layer — paying for the host with a KYC-linked card ties your real identity to the IP of your vault. A no-KYC, crypto-paid host removes that link.
What Vaultwarden is, and what it is not.
Vaultwarden — formerly bitwarden_rs — is an independent server-side reimplementation of the Bitwarden API in Rust. It speaks the same wire protocol as the official Bitwarden server, stores vaults in the same encrypted format and accepts every official client unchanged. To a Bitwarden browser extension or iOS app, a Vaultwarden server is indistinguishable from bitwarden.com.
The interesting differences are operational. The official Bitwarden server is a multi-container .NET stack designed for enterprise deployment; the published self-host image expects 2 GB of RAM and a SQL Server licence to be comfortable. Vaultwarden is a single 15 MB Rust binary that uses SQLite by default, runs happily in 50 MB of RAM and starts cold in under a second. The whole project fits in a single Docker container with no dependencies.
What you get is the entire Bitwarden feature surface — password vault, secure notes, identity records, payment cards, file attachments, send (one-time encrypted shares), TOTP authenticator, Organizations with shared collections, hardware key 2FA, browser autofill, mobile biometric unlock — without any of the paid tier gates. The Families plan equivalent and the Enterprise SSO equivalent are both free on a self-hosted Vaultwarden.
What Vaultwarden is not: a formally-audited server. The cryptographic primitives are inherited from the Bitwarden clients (which have been independently audited), but the Vaultwarden server itself has not been through a third-party security audit. For a personal or small-team vault that is a perfectly reasonable trade-off; for a regulated enterprise it is not.
Picking the VPS — why the host you rent from matters more than the spec.
Vaultwarden runs on essentially any Linux VPS — the resource floor is so low that the spec sheet is the wrong axis to optimise on. The right axis is what you have to hand over to rent the box.
A password vault is the single highest-value target a private person owns. Compromising it grants access to every other account the owner holds. The cryptographic posture protects the vault's contents; it does not protect the metadata around the vault — who rented the IP, from where, paid for with which card, registered under which name.
When you rent a VPS from a mainstream provider with full KYC, the billing database links your legal name to the IPv4 of the server. If the host is breached, or subpoenaed, or simply sells anonymised data to a marketing-analytics partner, the link survives. The vault stays encrypted, but the metadata layer is leaky by design.
NordBastion is the inverse — email plus password as the only signup floor, payment in Bitcoin, Monero, Lightning or other crypto, four Nordic constitutional press-freedom regimes for the data centre. The vault is yours; the metadata trail back from the vault to your identity does not exist to begin with. For a Vaultwarden host the entry-tier <a href="/vps/" class="text-nord-cyan border-b border-nord-cyan/40 hover:border-nord-cyan transition">Ravelin VPS at $5.90/month</a> is comfortably oversized — 2 vCPU, 4 GB RAM and 80 GB SSD will run Vaultwarden, the reverse proxy, and three other self-hosted apps on the same box.
The Docker install. Five commands, ten minutes.
Spin up a fresh Debian 12 VPS, SSH in as a non-root sudo user, then run these five blocks. Substitute vault.example.com with your own subdomain throughout — it will be the URL you reach the web vault on.
1. Install Docker. curl -fsSL https://get.docker.com | sh && sudo usermod -aG docker $USER — log out and back in so the group membership takes effect.
2. Create the data directory. mkdir -p ~/vw-data — Vaultwarden's entire state (the SQLite vault DB, attachments, the icon cache) lives in one directory; backing it up is straightforward because of this.
3. Generate the admin token. docker run --rm vaultwarden/server /vaultwarden hash --preset owasp — paste your chosen admin password when prompted, capture the resulting Argon2 hash. This protects the /admin panel.
4. Start the container. docker run -d --name vaultwarden --restart unless-stopped -e DOMAIN="https://vault.example.com" -e ADMIN_TOKEN='<paste-hash-from-step-3>' -e SIGNUPS_ALLOWED=false -e WEBSOCKET_ENABLED=true -v ~/vw-data:/data -p 127.0.0.1:8080:80 vaultwarden/server:latest — note the -p 127.0.0.1:8080 binding keeps Vaultwarden private to the host; the reverse proxy in chapter 4 fronts it.
5. Verify. curl -s http://127.0.0.1:8080/alive should return a timestamp. If it does, Vaultwarden is up. If it does not, docker logs vaultwarden shows what went wrong — almost always a typo in the ADMIN_TOKEN environment variable.
SIGNUPS_ALLOWED=false in step 4 is the most-forgotten setting. Leave it true and your vault is open for anyone who finds the URL to register on. Flip it true only long enough to create your own account, then flip it false and restart.
HTTPS and the admin panel. Non-optional, but five minutes.
Vaultwarden refuses to serve the web vault over plain HTTP from a non-localhost address; every official client also refuses to talk to a non-HTTPS server. The reverse-proxy + Let's Encrypt step is the gate to the rest of the setup. Caddy is the lightest path — one binary, automatic ACME, no separate certbot to schedule.
Point your DNS A record for vault.example.com at the VPS IP and wait for propagation (about two minutes for fresh records on most providers). sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https && curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg && echo "deb [signed-by=/usr/share/keyrings/caddy-stable-archive-keyring.gpg] https://dl.cloudsmith.io/public/caddy/stable/deb/debian any-version main" | sudo tee /etc/apt/sources.list.d/caddy-stable.list && sudo apt update && sudo apt install caddy.
Write /etc/caddy/Caddyfile: vault.example.com { reverse_proxy 127.0.0.1:8080 header_up X-Real-IP {remote_host} } — that is the whole config. sudo systemctl reload caddy and within ten seconds Caddy has fetched a Let's Encrypt certificate and the vault is reachable on https://vault.example.com.
The /admin panel. Vaultwarden exposes an administrative UI at /admin, protected by the Argon2 hash you generated in chapter 3. From there you can disable signups (already done in step 4), set the SMTP server for invitation and password-reset emails, configure Yubikey or Duo 2FA, set per-user limits and inspect the user list. Open it once, walk through every section, save the settings — they live in /vw-data/config.json from then on.
A small hardening detail: bind /admin off the public internet entirely. Add to the Caddyfile: vault.example.com { @admin path /admin* @admin not remote_ip 10.0.0.0/8 192.168.0.0/16 your.home.ip/32 respond @admin 404 ... } — anyone who is not on your home IP gets a 404 when they probe /admin, the panel is invisible from the open internet.
Backups. The one mistake that kills you.
A password vault you cannot restore from is a password vault you have already lost. The backup story for Vaultwarden is mercifully simple — everything that matters lives in one directory — but the discipline around restore-testing is what separates a working setup from a future incident.
What to back up. The whole ~/vw-data/ tree. Inside it: db.sqlite3 is the encrypted vault, attachments/ holds file attachments, config.json holds /admin settings, sends/ holds the temporary encrypted shares, rsa_key.* are the JWT signing keys used by sessions.
How to back up. SQLite handles concurrent backup via its .backup command — schedule a nightly cron: 0 4 * * * docker exec vaultwarden sqlite3 /data/db.sqlite3 ".backup /data/db.sqlite3.bak" && tar czf /backups/vw-$(date -I).tgz -C /home/<user>/vw-data . — a 50-account vault produces a sub-1 MB tarball.
Where to send the backups. Anywhere that is not the same VPS. rclone to an S3-compatible bucket, a second VPS, your home NAS over WireGuard, or an encrypted USB key you mail to a sibling once a quarter — pick what fits your threat model. The fundamental rule is geographical and administrative separation from the primary.
The restore drill. Spin up a second VPS, copy yesterday's backup to it, unpack into ~/vw-data, run the docker block from chapter 3 pointing at it, open the web vault on a temp subdomain, log in with your master password. If your account opens and the vault decrypts, the backup is real. Run this drill once now, before you put your real credentials in the vault. Re-run it every six months.
Clients, sharing, mobile. The Bitwarden ecosystem, pointed at your server.
Install the official Bitwarden client of your choice — browser extension, desktop app, iOS, Android. Before logging in, tap the gear icon in the top left, switch the server from bitwarden.com to https://vault.example.com, then log in with the account you created in chapter 4. The client cannot tell the difference and behaves identically to a managed Bitwarden subscription.
The mobile clients carry one extra step: biometric unlock requires the device to be enrolled, which the first login on iOS / Android handles automatically. Browser autofill, mobile autofill, TOTP generation, password generator, breach-monitor lookup (HaveIBeenPwned) and Bitwarden Send all work without further configuration.
Family sharing. Create an Organization in the web vault → New Organization → name it (e.g. "Family"), free plan. Inside the org, create a Collection ("Shared bills", "Streaming services", "WiFi & router"). Invite each family member by their server-local email, accept the invitation when they sign up, assign them to the collection. From that moment any item in the collection is end-to-end encrypted to every member of the collection — the server only sees ciphertext.
What you do not have to pay for. All Bitwarden paid features that are server-policy (Organizations, shared collections, the Families plan equivalent, hardware-key 2FA, Send file attachments) are unlocked by default on Vaultwarden because the server is the gate. Paid features that are client-policy (some Bitwarden mobile premium gates) are honoured by the clients unless you patch them — not worth doing for an honest user.
Questions, answered.
Eight questions that come up before and during the first month of running a self-hosted Vaultwarden.
Is Vaultwarden the same as Bitwarden?
Vaultwarden is an independent, Rust-based reimplementation of the Bitwarden server, fully compatible with every official Bitwarden client — browser extension, desktop app, iOS, Android, CLI. It is not produced by Bitwarden Inc. The wire protocol and the vault format are the same; the server binary is roughly 1/100th of the size and runs comfortably in 50–100 MB of RAM.
Why self-host Vaultwarden instead of paying for Bitwarden hosted?
Three reasons. One: nobody else holds your encrypted vault — even though Bitwarden cannot read it either, removing the third party is the cleanest threat model. Two: cost — a $5/month VPS handles a family of five with room for the rest of your self-hosted stack. Three: no telemetry, no analytics endpoints, no account verification email tied to a name.
Is self-hosting a password vault actually safe?
Yes — Vaultwarden uses the same client-side encryption as Bitwarden. The vault is encrypted with AES-256 on the client before it is sent to the server; the server never sees your master password or any plaintext. A compromise of the VPS yields an encrypted blob that is only as weak as your master password. The operational risk is on you (backups, HTTPS, server hardening), but the cryptographic risk is identical to managed Bitwarden.
How much VPS do I need?
Very little. Vaultwarden itself is happy on 1 vCPU and 512 MB of RAM. The minimum NordBastion VPS (2 vCPU, 4 GB, $5.90/month) is more than enough to run Vaultwarden, the reverse proxy, and three other self-hosted services on the same box. Disk usage is negligible — a 50-account vault with attachments stays under 200 MB.
Why does a KYC-free, crypto-paid host matter for a password manager?
A password vault is the highest-value target a private person owns — it contains the credential to every other account. Renting the server under your legal name with a card linked to your real identity means a compromise of the host's billing database links your identity to the IP of your vault. A no-KYC, crypto-paid host removes that link by design. The vault itself is still client-side encrypted; the no-KYC posture protects the metadata layer.
Do I really need HTTPS for the Vaultwarden web vault?
Yes, strictly. Vaultwarden refuses to serve the web vault over plain HTTP from any address other than localhost, and every official client also refuses to talk to a non-HTTPS server. The reverse proxy + Let's Encrypt setup in this guide is non-optional. The good news: the whole TLS step takes about three minutes once your DNS A record has propagated.
What is the single biggest mistake people make self-hosting Vaultwarden?
Not testing the restore from backup. A nightly tar.gz of /vw-data/ is not a backup until you have unpacked it to a fresh VPS and successfully logged into the recovered web vault. Plan for the failure case: the server is gone, the disk is wiped, the only artefact you have is yesterday's backup file — can you walk back into your vault? Run that drill once before you put real credentials in the vault.
Can I share my vault with my family from a self-hosted Vaultwarden?
Yes. Vaultwarden re-implements Bitwarden's Organizations feature — including shared collections, granular permissions and the equivalent of the Bitwarden Families plan — without any paid tier. You create an organisation in the web vault, invite your family by email (or by sharing the invite link directly), and from there the sharing UX is identical to the official Bitwarden product.
Rent a KYC-free VPS, pay in crypto, run Vaultwarden today.
The Ravelin entry tier (2 vCPU, 4 GB RAM, 80 GB SSD, $5.90/month) is comfortably oversized for Vaultwarden and leaves room for the rest of your self-hosted stack on the same box.
Last reviewed · 2026-05-20 · Sources · Vaultwarden upstream docs, Bitwarden client compatibility matrix, Let's Encrypt ACME · Cadence · yearly
Anonymous VPS hosting in 2026 — the cluster.
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Files, calendar, contacts, photos — owned, not rented.
Postfix, Dovecot, SPF/DKIM/DMARC — deliverability included.
A meta search engine that does not log you — because you own it.
What “no KYC” actually means — and what it does not.