Self-Host Bitwarden on an Anonymous VPS

By the HushVPS team · Updated 2026 · 8 min read

Your password vault is the single most sensitive account you own. Crack it and an attacker inherits your email, your bank, your identity providers — everything downstream. So the question of where that vault lives is not academic. If you want to self host Bitwarden on a VPS with no KYC, you are choosing to keep the encrypted database on hardware you control, paid for anonymously, instead of on a third party's cloud tied to your legal name. This guide walks through why that trade-off makes sense, how the setup actually works at a high level, and where anonymous hosting closes a gap that ordinary self-hosting leaves open.

Why self-host a password manager at all

Bitwarden's hosted service is genuinely good, and its clients use zero-knowledge, end-to-end encryption, so the company never sees your plaintext passwords. For most people that is a reasonable default. But hosting the server yourself changes three things worth caring about:

  • You remove a target. A managed vault provider is a high-value honeypot; millions of encrypted blobs sitting in one place attract determined attackers. Your single self-hosted instance is a far less interesting prize.
  • You control availability. No account suspension, no surprise policy change, no region lockout. The service stays up as long as your server does.
  • You own the metadata. Even with zero-knowledge encryption, a provider still sees your login IPs, timestamps, device fingerprints and billing identity. Self-hosting keeps that telemetry on your own box.

The catch is that you inherit the responsibility too — patching, backups and access control are now your job. Most of this guide is about doing those three things properly.

Bitwarden vs Vaultwarden: what you actually run

There are two ways to self-host the Bitwarden ecosystem. The first is the official self-hosted server from Bitwarden, which is feature-complete but heavier — it expects several containers and more RAM than a small VPS comfortably gives you. The second, and the one most privacy-minded self-hosters pick, is Vaultwarden, an unofficial, Rust-based server that speaks the same API as the official clients. It runs happily in a single container on a 1 vCPU / 2 GB box, so it fits our entry-level plan with room to spare.

The important detail: because Vaultwarden implements the Bitwarden API, you still use the official, audited Bitwarden apps and browser extensions on your devices. You are only replacing the backend. Your vault stays end-to-end encrypted; the server merely stores and syncs the encrypted blob. That is the whole appeal — official client security, self-hosted control.

What you need before you start

The requirements are modest. You need a small Linux VPS with root access, a domain name (or subdomain) pointed at its IP, and about twenty minutes. Vaultwarden's resource footprint is tiny, so our smallest Phantom plan — 1 vCPU, 2 GB RAM and 30 GB of NVMe is more than enough for a personal or family vault. Storage barely moves; a vault with hundreds of entries and attachments is measured in megabytes.

Deploy the server, note the IPv4 and IPv6 addresses we hand you, and create an A (and AAAA) record for vault.yourdomain.tld pointing at them. That is the only external dependency. Everything else lives on the box.

The high-level setup

Do not expose Vaultwarden's container port directly to the internet. The standard, safe pattern is a reverse proxy terminating TLS in front of it. Here is the shape of it, without turning this into a copy-paste script you shouldn't trust blindly.

1. Lock down the box first

Before installing anything, update the system, create a non-root user, and disable password SSH in favour of key-only login. Enable a firewall (ufw or nftables) that allows only ports 22, 80 and 443. This is baseline hygiene and takes two minutes; skipping it is how self-hosted boxes get owned.

2. Deploy Vaultwarden in a container

Install Docker, then run the official Vaultwarden image with its data directory mounted to a persistent volume on the host. That volume — typically /vw-data — holds the SQLite database, attachments and RSA keys. It is the one thing you must never lose, which is why backups get their own section below.

3. Put a reverse proxy and HTTPS in front

Use Caddy or Nginx as the public-facing layer. Caddy is the easy path: it fetches and renews a Let's Encrypt certificate automatically, so your vault is served over HTTPS with no manual cert wrangling. Point the proxy at Vaultwarden's internal port and you are done. A password manager should never be reachable over plain HTTP — the browser extensions will refuse to talk to it anyway.

4. Close the door behind you

Once your own account is created, set SIGNUPS_ALLOWED=false so nobody else can register on your instance. If you want family members, invite them explicitly or use the admin page (protected by its own token) to manage users. An open registration endpoint on a public vault is an invitation you don't want to send.

Backups: the part people skip

Self-hosting means you are now the backup department. The good news is that Vaultwarden's entire state is that one data directory, and the database is a single SQLite file. A sound routine looks like this:

  • Take a nightly snapshot of the data directory — use the SQLite .backup command rather than copying the live file, so you never capture a half-written database.
  • Encrypt the backup before it leaves the server (age or GPG), because it contains your encrypted vault plus its keys.
  • Ship the encrypted archive off-box: a second HushVPS server, an object-storage bucket, or your own machine over SSH.
  • Test a restore at least once. A backup you have never restored is a hope, not a plan.

Because the vault itself is already encrypted with your master password, an off-site copy is not a new exposure as long as you encrypt the transport and storage too. Belt and braces.

Hardening the running service

A few habits keep a self-hosted vault boring, which is exactly what you want it to be:

  • Patch on a schedule. Pull the latest Vaultwarden image regularly and keep the host OS current. Unattended-upgrades handles the OS; a simple cron or Watchtower policy handles the container.
  • Enable two-factor auth on every account. Even a self-hosted instance benefits enormously — it turns a leaked master password from a catastrophe into a near-miss.
  • Consider hiding it behind a VPN. If only you and your household use the vault, you can bind it to a WireGuard interface so it is never reachable from the open internet at all. Pair this with a no-logs VPS that keeps no access records and the surface an attacker can even see shrinks to almost nothing.
  • Rate-limit and monitor. Vaultwarden supports login throttling; enable it. Watch the logs for repeated failed attempts.

Deploy the box for your vault in minutes

Vaultwarden fits our smallest plan. No ID, no card — pay in Monero and get root access on a server that isn't tied to your name.

Browse plans

Why doing this on an anonymous, no-KYC host matters

Here is the part ordinary self-hosting guides leave out. Moving your vault off a managed provider onto your own server improves the software side of privacy. But if you rented that server with your real name, a credit card and a home address, you have simply relocated the identity link one layer down. The hosting company beneath your vault now knows exactly whose passwords those encrypted blobs belong to.

An anonymous, no-KYC host closes that last gap. When there is no identity verification, no card on file and Monero settles the invoice, the provider running the metal cannot tie the server holding your most sensitive data back to you through a billing record. There is nothing in the account to subpoena, sell, leak or hand over — because it was never collected. That is the difference between privacy in the app and privacy across the whole stack. Our broader write-up on running your own private services on an anonymous VPS covers the same logic for mail and cloud storage.

To be clear about what this does and doesn't do: anonymous hosting protects you from the hosting layer becoming a paper trail. It does not make you invisible or excuse anything illegal — HushVPS is offshore-legal and data-minimising, and our acceptable-use policy still forbids malware, spam and network attacks. The goal is straightforward: keep your password vault yours, on hardware nobody can trivially connect to your identity, backed up and hardened so it stays boring for years.

The short version

Self-hosting Bitwarden — in practice, Vaultwarden — puts the most important account you own on a machine you control, running the same audited clients you already trust. Do it right: lock the box down, terminate TLS with a reverse proxy, disable open signups, back the data directory up off-site with encryption, and keep everything patched. Do it on a no-KYC, Monero-paid VPS and you also remove the billing trail that would otherwise link that vault to your name. Privacy on both ends of the stack, which is exactly where a password manager deserves to live.