⚽ Live Match: how to set up vaultwarden

August 5, 2026

22 min read

Password manager breaches keep landing in the headlines, and every one of them makes the same case for a different approach: run your own. Vaultwarden, an unofficial Bitwarden-compatible server, lets you do exactly that on hardware you control, without paying for a hosted plan or trusting a third party with the one database that unlocks everything else. This guide walks through a full Vaultwarden setup, from a bare Linux server to a hardened, backed-up, two-factor-protected vault that every official Bitwarden client can connect to.

Google · Preferred Sources

Don't miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

Add Now

What Is Vaultwarden, and Why Self-Host Your Password Manager?

Vaultwarden is an unofficial, community-maintained rewrite of the Bitwarden server, built in Rust and formerly known as bitwarden_rs. It is not a Bitwarden Inc. product. The project, maintained by developer Dani García and a large group of contributors on GitHub, has passed more than 62,000 stars and ships under the AGPL-3.0 license, which keeps the code open and requires any hosted fork to publish its own source as well. Maintenance has stayed active through the update: the 1.33.0 release patched CVE-2025-24365 and CVE-2025-24364 on 25 January 2025, and the project has continued shipping regular version bumps roughly every few months since.

What makes Vaultwarden worth the extra setup time isn’t just that it’s free. The official Bitwarden self-hosted stack expects a heavier deployment, built around Microsoft SQL Server and several services running side by side. Vaultwarden collapses all of that into a single container that talks to SQLite by default, with MySQL and PostgreSQL available for bigger deployments through its Diesel-based storage layer. The practical result is a password vault that runs comfortably on a small VPS or a spare mini PC, while still connecting to every official Bitwarden app: the browser extension, the desktop client, the mobile apps, and the CLI.

There’s a second reason engineers reach for it. Vaultwarden includes organization support, TOTP code generation, encrypted file attachments, and other features that sit behind Bitwarden’s paid tiers on the hosted service, all included for free because you’re the one running the server. The gap has only widened since: version 1.35.0, released 27 December 2025, added OpenID Connect single sign-on support, a feature Bitwarden reserves for enterprise customers on its hosted plans.

None of that comes free of responsibility, though. A hosted password manager service handles patching, uptime monitoring, and disaster recovery as part of what you pay for. A self-hosted password manager shifts every one of those jobs onto you. That’s a fair trade for a lot of technically comfortable users and a bad one for people who’d rather not think about server maintenance at all, and it’s worth being clear-eyed about which camp you’re in before you start Step 1.

Self-hosting has picked up through 2025 and into 2026 as more engineers move the software that touches their most sensitive data onto infrastructure they control. A password vault is about as sensitive as it gets. It holds the keys to your email, your bank, and every account behind those two. Running Vaultwarden puts that vault on a server you can inspect, back up on your own schedule, and move whenever you want. That control comes with a trade-off worth naming upfront: you take on the updates, backups, and uptime that a hosted provider would otherwise handle for you, and the stakes are real. A Censys scan from May 2026 found roughly 1,700 internet-facing Vaultwarden hosts, about 9% of all instances it could identify, still running vulnerable versions at or below 1.32.5. This tutorial covers updates, backups, and uptime, along with a production-ready Docker Compose stack, a real TLS certificate, two-factor authentication, and hardening against brute-force login attempts. Budget around 80 minutes for the full walkthrough if this is your first self-hosted deployment, less if your server and domain are already in place.

Prerequisites: Server, Domain, and Software Versions You’ll Need

Before touching a terminal, get these four things sorted: a Linux server you control (a cheap VPS, a home server, or a mini PC all work), a domain name or subdomain you can point at that server’s IP address, root or sudo access over SSH, and roughly an hour and a half of uninterrupted time. Vaultwarden itself is light on resources, but the reverse proxy, TLS certificate, and Docker runtime around it need a baseline of CPU and memory to run comfortably.

Component	Minimum	Recommended	Notes
Server OS	Any 64-bit Linux	Ubuntu 24.04 LTS	Debian 12 and Ubuntu 22.04 also work fine
CPU	1 vCPU	2 vCPU	Vaultwarden itself is a single lightweight process
RAM	512 MB	1 GB or more	Leaves headroom for the reverse proxy and OS
Disk	10 GB	20 GB or more	Vault data is small, and space mostly covers OS, logs, and backups
Docker Engine	24.x	28.2.2	Installed via the official get.docker.com script
Docker Compose	v2.x	v2.39.1	Ships as a plugin with modern Docker Engine installs
Vaultwarden image	vaultwarden/server:latest	vaultwarden/server:1.36.0	Pin an exact version tag in production
Reverse proxy	Nginx 1.30 or Caddy 2.11	Caddy 2.11.4	Caddy automates certificate issuance and renewal
Domain name	1 registered domain	A dedicated subdomain, e.g. vault.example.com	Needs a DNS A record pointed at your server

One more decision to make now: SQLite is the right backend for a single user or a small family, and it’s what this tutorial uses throughout. If you’re planning a Vaultwarden setup for a team or an organization with dozens of accounts, skip ahead to the advanced tips section for notes on switching to PostgreSQL before you have real data to migrate.

Step 1: Prepare Your Server and Install Docker

Start by pointing your domain at the server. Log into your DNS provider and create an A record for something like vault.example.com that resolves to your server’s public IP address. DNS changes can take anywhere from a few minutes to a few hours to propagate, so do this first and let it work in the background while you finish the rest of the setup.

Next, SSH into the server and make sure the two ports Vaultwarden needs are open on your firewall: 80 for the HTTP-to-HTTPS redirect and certificate validation, and 443 for encrypted traffic. If you’re using ufw, that’s a two-line job.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

With the firewall sorted, install Docker using the official convenience script. It handles the repository setup, package installation, and the Compose plugin in one pass.

curl -fsSL https://get.docker.com -o install-docker.sh
sudo sh install-docker.sh
sudo usermod -aG docker $USER
newgrp docker
docker --version
docker compose version

The two version commands should print something close to Docker Engine 28.2.2 and Docker Compose v2.39.1 if you’re installing fresh in 2026. Older LTS installs running Docker Engine 24.x will still work through this entire tutorial without issue.

Step 2: Generate a Secure Admin Token

Vaultwarden ships with a web-based admin panel for managing users, checking diagnostics, and adjusting settings without touching the command line. That panel is protected by a single secret, the ADMIN_TOKEN, and it’s worth generating a long, random one now rather than typing something memorable.

openssl rand -base64 48

Copy the output somewhere safe. You’ll paste it into the environment file in the next step. If you want an extra layer of protection, Vaultwarden also supports Argon2-hashed admin tokens instead of a plain string, documented on the project’s official wiki. For a personal or small-team deployment, a 48-byte random token stored in a file with restricted permissions is more than sufficient.

Step 3: Write Your docker-compose.yml and .env Files

Create a project directory, then two files inside it: docker-compose.yml and .env. Keeping secrets in a separate .env file means you can commit the compose file to a private repo without leaking credentials, as long as you remember to exclude the .env file itself.

mkdir -p ~/vaultwarden/vw-data
cd ~/vaultwarden

Now write the compose file. This defines a single service, maps a local data folder into the container so your vault survives restarts and upgrades, and binds the container to localhost only, since the reverse proxy you’ll configure in the next step is what actually faces the internet.

services:
  vaultwarden:
    image: vaultwarden/server:1.36.0
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      - DOMAIN=https://vault.example.com
      - ADMIN_TOKEN=${ADMIN_TOKEN}
      - SIGNUPS_ALLOWED=false
      - WEBSOCKET_ENABLED=true
      - LOG_FILE=/data/vaultwarden.log
      - LOG_LEVEL=warn
      - SMTP_HOST=${SMTP_HOST}
      - SMTP_FROM=${SMTP_FROM}
      - SMTP_PORT=587
      - SMTP_SECURITY=starttls
      - SMTP_USERNAME=${SMTP_USERNAME}
      - SMTP_PASSWORD=${SMTP_PASSWORD}
    volumes:
      - ./vw-data:/data
    ports:
      - "127.0.0.1:8080:80"

And the matching .env file, using the token you generated in Step 2 and your own mail provider’s SMTP credentials for account invitations and password-reset emails.

ADMIN_TOKEN=paste_your_openssl_output_here
SMTP_HOST=smtp.yourprovider.com
[email protected]
[email protected]
SMTP_PASSWORD=your_smtp_password

Notice SIGNUPS_ALLOWED is already set to false. That’s deliberate, and it’s the single most common security misstep in a self-hosted Vaultwarden instance: leaving public registration open on a server anyone on the internet can reach. Set it to false from the start and invite users manually through the admin panel once the stack is running.

Step 4: Put Vaultwarden Behind a Reverse Proxy With HTTPS

Bitwarden’s official clients refuse to talk to a server without valid HTTPS, and for good reason: this is a password vault, not a blog. You have two solid options here. Caddy handles certificate issuance and renewal automatically with almost no configuration. Nginx paired with Certbot gives you more manual control if you’re already running Nginx for other sites on the same box. Pick whichever fits your existing setup.

Option A: Caddy (Automatic HTTPS)

Install Caddy 2.11.4 or later using your distribution’s package manager, then replace the contents of /etc/caddy/Caddyfile with this block.

vault.example.com {
    reverse_proxy 127.0.0.1:8080
}

Reload Caddy with sudo systemctl reload caddy and it requests a certificate from Let’s Encrypt automatically the moment it sees traffic on port 80 for that domain, including renewal every 60 days without any cron job on your part. That’s the entire configuration. Caddy also proxies WebSocket connections transparently, so live sync works without any extra directives.

Option B: Nginx and Certbot

If you’d rather stick with Nginx 1.30, first issue a certificate with Certbot’s webroot method, then drop in a config block that proxies both regular traffic and the WebSocket notification endpoint Vaultwarden uses for real-time sync.

sudo certbot certonly --webroot -w /var/www/certbot -d vault.example.com

server {
    listen 80;
    server_name vault.example.com;
    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }
    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl http2;
    server_name vault.example.com;

    ssl_certificate /etc/letsencrypt/live/vault.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/vault.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /notifications/hub {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    }
}

That second location /notifications/hub block is easy to miss and it’s the reason so many Nginx-based Vaultwarden setups sync fine on first load but never update in real time afterward. Without it, the WebSocket upgrade request never reaches the container. Test the config and reload once both blocks are in place.

sudo nginx -t && sudo systemctl reload nginx

Step 5: Launch the Stack and Confirm It’s Running

With the compose file, environment variables, and reverse proxy all in place, bring the container up.

docker compose up -d
docker compose ps

You should see output close to this, with the container listed as running and healthy within a few seconds of the initial pull finishing.

NAME          IMAGE                       STATUS
vaultwarden   vaultwarden/server:1.36.0   Up 12 seconds (healthy)

Then confirm the reverse proxy and certificate are both working end to end from outside the server.

curl -I https://vault.example.com/alive

A working setup returns a clean 200 response.

HTTP/2 200
content-type: text/plain; charset=utf-8

If that curl command times out or returns a connection error, stop here and check DNS propagation and firewall rules before moving on. Every step after this one assumes the domain resolves and HTTPS terminates correctly.

Step 6: Create Your Account and Disable Public Registration

Since SIGNUPS_ALLOWED is still true by default until your first restart picks up the environment file, visit https://vault.example.com right after the container comes up and create your own account before anyone else can find the server. If you’re running version 1.34.0 or later, released 26 May 2025, that first signup also goes through Vaultwarden’s email-verified registration flow, so account creation now confirms you control the inbox before the vault is usable. Use a strong, unique master password here, since it’s the one credential protecting every other credential in the vault. A password manager is only as strong as the single password that unlocks it.

Once your account exists, confirm SIGNUPS_ALLOWED=false is active by restarting the stack (docker compose up -d again picks up any environment changes) and trying to load the registration page. It should refuse new signups from that point forward. Any additional users you want on this instance get invited individually through the admin panel in the next step, which is both more secure and easier to audit than open registration ever was.

Step 7: Configure the Admin Panel, SMTP, and Organization Policies

Navigate to https://vault.example.com/admin and log in with the admin token from Step 2. This panel is where you invite new users, check server diagnostics, review background jobs, and adjust global settings without editing environment variables and restarting containers for every small change.

If you configured SMTP credentials in your .env file, test them from the admin panel’s diagnostics page before relying on them. Invitation emails, password-reset links, and new-device notifications all depend on outbound mail working correctly, and it’s much easier to catch a typo’d SMTP password here than to debug why a family member never received their invite.

If you’re setting this up for more than yourself, create an organization from within the vault (not the admin panel) and invite members into it. Organizations in Vaultwarden support shared collections, so a household or small team can keep shared logins (the family streaming account, the office Wi-Fi password) separate from everyone’s personal items, with permissions controlled per collection.

Step 8: Turn On Two-Factor Authentication

A self-hosted vault without two-factor authentication on the account itself is a single point of failure wearing a disguise. Vaultwarden supports several second factors straight out of the box: TOTP authenticator apps, email codes, WebAuthn/FIDO2 security keys, YubiKey OTP, and Duo. The NIST digital identity guidelines treat a hardware security key or authenticator app as meaningfully stronger than SMS-based codes, and Vaultwarden’s option list lines up with that guidance well.

From your account settings, open the security section and enable at least one factor beyond your master password. TOTP is the fastest to set up and works with any standard authenticator app. If you own a hardware key, WebAuthn is the strongest option available and pairs naturally with the passkey support already built into modern Bitwarden clients. Whichever you choose, save the recovery code Vaultwarden generates during setup somewhere outside the vault itself. Losing both your second factor and your recovery code locks you out permanently, since there’s no vendor support line to call for a self-hosted instance.

Step 9: Connect Every Bitwarden Client to Your Server

This is where a Vaultwarden setup pays off: every official Bitwarden client works against it unmodified, because Vaultwarden implements the same API surface. On the browser extension, desktop app, and mobile app, look for a gear icon or “Self-hosted” toggle on the login screen before entering your email and password, and point it at https://vault.example.com.

Full setup instructions for each platform live in Bitwarden’s official help center, since the client apps themselves are unchanged from what connects to the hosted service. The one setting that trips people up is on mobile: the self-hosted server URL field is sometimes hidden behind an “advanced” or “environment” toggle rather than sitting on the main login screen.

For the CLI, install it through npm and log in with the same server flag.

npm install -g @bitwarden/cli
bw config server https://vault.example.com
bw login

Once you’ve confirmed sync works on at least two clients (say, the browser extension and your phone), you have a fully functioning self-hosted password manager. Everything from here on is about keeping it that way.

Step 10: Automate Backups and Prove You Can Restore

A vault you can’t restore isn’t a backup, it’s a false sense of security. Vaultwarden’s entire state lives in the ./vw-data folder you mapped into the container: the SQLite database, attachments, sends, and icons cache all sit there. Back up the whole folder, not just the database file.

#!/usr/bin/env bash
set -euo pipefail
BACKUP_DIR="/home/deploy/vw-backups"
STAMP=$(date +%F-%H%M)
mkdir -p "$BACKUP_DIR"
docker compose exec -T vaultwarden sqlite3 /data/db.sqlite3 ".backup /data/backup-$STAMP.sqlite3"
tar -czf "$BACKUP_DIR/vaultwarden-$STAMP.tar.gz" -C ./vw-data .
find "$BACKUP_DIR" -type f -mtime +30 -delete

Save that as backup-vaultwarden.sh, make it executable, and schedule it with cron to run nightly.

chmod +x backup-vaultwarden.sh
crontab -e
# add this line:
0 3 * * * /home/deploy/vaultwarden/backup-vaultwarden.sh >> /var/log/vw-backup.log 2>&1

Then copy at least one backup archive off the server entirely, whether that’s an object storage bucket, a second machine, or an encrypted external drive. A backup that lives on the same disk as the thing it’s backing up doesn’t survive a dead drive. Finally, actually test a restore on a spare machine or a throwaway container once, before you need it for real. Confirming you can decompress the archive, drop it into a fresh vw-data folder, and bring up a working Vaultwarden container against it turns “we have backups” into something you know is true rather than something you hope is true.

Step 11: Harden Vaultwarden Against Brute-Force and Abuse

With signups closed, HTTPS enforced, and two-factor authentication on, the remaining exposure is repeated login attempts against your master password. Vaultwarden’s LOG_FILE and LOG_LEVEL=warn settings from Step 3 write failed login attempts to /data/vaultwarden.log, which gives Fail2ban something concrete to watch.

Create a filter that matches Vaultwarden’s failed-login log line.

# /etc/fail2ban/filter.d/vaultwarden.conf
[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <HOST>\.$
ignoreregex =

Then wire it into a jail that bans an IP address after five failed attempts within ten minutes.

# /etc/fail2ban/jail.d/vaultwarden.conf
[vaultwarden]
enabled = true
filter = vaultwarden
logpath = /home/deploy/vaultwarden/vw-data/vaultwarden.log
maxretry = 5
findtime = 600
bantime = 3600
action = iptables-allports[name=vaultwarden]

Restart Fail2ban to load the new jail, then check its status to confirm it’s watching the right file.

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

This pattern mirrors the same approach covered in our Fail2ban setup guide for protecting SSH, applied here to the vault’s login endpoint instead. It’s also worth reviewing the OWASP Top 10 guidance on authentication failures, since a rate-limited, two-factor-protected login endpoint addresses most of what that list flags as the most common way credential-based attacks succeed.

Step 12: Keep It Updated: Patching and Maintenance Cadence

Self-hosting trades convenience for control, and the update process is where that trade shows up most directly. There’s no automatic patch cycle handling this for you, so build a habit around it. Updating is a two-command job.

docker compose pull
docker compose up -d
docker image prune -f

Run that monthly at minimum, and immediately whenever the project publishes a security-relevant release on its GitHub releases page. Recent history shows why that cadence matters: 1.33.0 closed CVE-2025-24365 and CVE-2025-24364 in January 2025, and the web vault UI bundled with each release has kept pace too, moving from v2025.1.1 in that same January 2025 release to v2025.12.0 by the December 2025 1.35.0 build, which also switched to immutable releases with release attestation so you can verify an image wasn’t tampered with before you pull it. Before pulling a new version tag in production, skim the changelog for breaking environment variable changes, and take a fresh backup first using the script from Step 10. That backup takes thirty seconds to run and turns a bad update into a five-minute rollback instead of a lost vault.

Putting It All Together: The Complete Working Vaultwarden Project

By this point, the pieces from Steps 1 through 12 add up to a complete, working project rather than a pile of disconnected configuration. It helps to see the final shape of it in one place, especially if you’re rebuilding this Vaultwarden setup on a second server later and want a checklist instead of twelve separate sections.

~/vaultwarden/
├── docker-compose.yml
├── .env
├── backup-vaultwarden.sh
└── vw-data/
    ├── db.sqlite3
    ├── attachments/
    ├── sends/
    ├── icon_cache/
    └── vaultwarden.log

/etc/caddy/Caddyfile
/etc/fail2ban/filter.d/vaultwarden.conf
/etc/fail2ban/jail.d/vaultwarden.conf

Each piece maps back to a specific step: docker-compose.yml and .env come from Step 3, the Caddyfile from Step 4, backup-vaultwarden.sh from Step 10, and the two Fail2ban files from Step 11. Nothing in this project depends on a database server, a message queue, or any service beyond the single Vaultwarden container and whichever reverse proxy you chose. That’s the whole point of choosing Vaultwarden over the official self-hosted Bitwarden stack: the entire recovery plan for this self-hosted password manager fits in one directory tree and three config files outside it.

Assuming every file above is already written, bringing the whole project up from a freshly provisioned server is a short, ordered sequence.

cd ~/vaultwarden
docker compose up -d
sudo systemctl reload caddy
docker compose ps
curl -I https://vault.example.com/alive
sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

If any single command in that sequence fails, the troubleshooting table further down maps most of those failures straight back to one of these six files. That’s exactly why keeping this project in a private version control repository, excluding the .env file and everything under vw-data, pays off the first time you need to rebuild it under pressure rather than from memory.

Vaultwarden vs Bitwarden vs 1Password vs KeePassXC: Cost and Feature Comparison

Vaultwarden isn’t the only way to manage passwords, and it isn’t the right fit for everyone. Here’s how it stacks up against the official self-hosted Bitwarden server and two of the most common alternatives people compare it to.

Factor	Vaultwarden (self-hosted)	Official Bitwarden self-host	1Password	KeePassXC
Hosting model	You run it yourself, one container	You run it yourself, heavier multi-service stack	Vendor-hosted cloud only	Local encrypted file, no server required
Cost	Free and open source	Free tier available, plus your own infrastructure cost	Paid subscription required	Free and open source
License	AGPL-3.0	Mixed open and proprietary components	Proprietary	GPL-3.0
Backend database	SQLite, MySQL, or PostgreSQL	Requires MSSQL plus several supporting services	Vendor-managed, not user-facing	Local encrypted .kdbx file
Client apps	Official Bitwarden apps, unmodified	Official Bitwarden apps	1Password apps	Community apps and browser plugins
2FA support	TOTP, WebAuthn/FIDO2, email, YubiKey, Duo	Same, plus enterprise SSO on paid tiers	TOTP, hardware security key	TOTP via plugin
Real-time sync	Yes, via WebSocket on your own server	Yes, via your own server	Yes, via 1Password’s cloud	Manual or self-managed sync only
Best fit	Self-hosters who want Bitwarden compatibility on minimal hardware	Teams wanting official support who can run a heavier stack	Users who want zero maintenance and vendor support	Offline-first users who don’t need multi-device sync

If the idea of running any server yourself sounds like more than you want to take on, our comparisons of 1Password vs Bitwarden and Proton Pass vs Bitwarden vs 1Password cover the hosted alternatives in more depth. Vaultwarden earns its place specifically for people who want Bitwarden’s client experience with none of the recurring subscription cost and full control over where the data physically sits.

5 Common Pitfalls When Self-Hosting Vaultwarden

Exposing the admin panel to the open internet. The /admin path is protected only by your token. Consider restricting it further with an IP allowlist in your reverse proxy config, or disabling it entirely with DISABLE_ADMIN_TOKEN=true once initial setup is finished, re-enabling it only when you need it.
Skipping HTTPS or using a self-signed certificate. Mobile Bitwarden clients in particular refuse untrusted certificates outright, and you’ll spend an hour debugging “cannot connect to server” errors that a real Let’s Encrypt certificate would have avoided entirely.
Backing up only the database file. Attachments, sent items, and the icon cache all live alongside db.sqlite3 in the data folder. A backup script that only copies the database silently drops everything else.
Leaving SIGNUPS_ALLOWED=true after initial setup. This is the single most common misconfiguration in public Vaultwarden deployments, and it turns a private vault into an open invitation the moment your domain gets indexed or scanned.
Running :latest instead of a pinned version tag in production. An unannounced breaking change in a new release can take your vault down with no warning. Pin a specific tag like 1.36.0 and upgrade deliberately using the process from Step 12.
Forgetting the WebSocket proxy block. Skipping the /notifications/hub location in Nginx, or trusting that proxying alone covers it without testing, leaves you with a vault that loads fine but never syncs changes across devices in real time.

Troubleshooting: 9 Vaultwarden Problems and Their Fixes

Even a clean Vaultwarden setup runs into the same handful of issues often enough that it’s worth having the fixes on hand before you need them.

Symptom	Likely cause	Fix
“Invalid admin token” at /admin	Token mismatch between .env and running container	Regenerate the token, update .env, run docker compose up -d again
Vault doesn’t sync in real time	WebSocket traffic blocked by the reverse proxy	Confirm WEBSOCKET_ENABLED=true and add the /notifications/hub proxy block
Clients say “cannot connect to server”	Wrong server URL or an untrusted certificate	Double-check the HTTPS URL and confirm the cert chain with curl -I
502 Bad Gateway from the reverse proxy	Container isn’t listening where the proxy expects	Verify the port mapping in docker-compose.yml matches your proxy_pass target
Certificate renewal fails silently	Port 80 blocked, or DNS no longer points at this server	Reopen port 80 temporarily and confirm the A record is current
Can’t create a new account	SIGNUPS_ALLOWED is set to false, as intended	Invite the user from the admin panel instead of the public signup page
Invitation or reset emails never arrive	SMTP credentials wrong or blocked by the provider	Test SMTP from the admin panel diagnostics page and check spam folders
Attachments fail to upload	Data volume not writable or disk is full	Check the volume mapping permissions and available disk space
Restored backup shows an empty vault	Restored to the wrong data path or container wasn’t stopped first	Stop the stack, replace the entire vw-data folder, then start it again

If none of these match what you’re seeing, check the container’s own logs before assuming the problem is external.

docker compose logs -f vaultwarden

Most connection and sync issues show a clear error line within the first few seconds of a client trying to reach the server, and that log line usually points straight at the misconfigured piece.

Advanced Tips: Organizations, Migration, and Scaling Past One User

Once the base install is solid, a few extensions turn a personal vault into infrastructure other people can depend on. If you’re migrating from an existing hosted Bitwarden account, export your vault as an encrypted JSON file from the hosted service first, then import it from within your new Vaultwarden account’s settings. The import runs entirely client-side against your new server, so the plaintext export never touches disk on either end for longer than the import takes.

For anything beyond a handful of users, move off SQLite before you have data worth losing rather than after. SQLite handles single-user and small-household loads without any trouble, but concurrent writes from a real team benefit from PostgreSQL’s better locking behavior. Switching the DATABASE_URL environment variable to a PostgreSQL connection string and running Vaultwarden’s built-in migration on an empty database is far simpler than migrating a database that’s already accumulated months of vault items.

For visibility into uptime, a lightweight monitoring container like Uptime Kuma checking the same /alive endpoint from Step 5 on a five-minute interval catches an outage long before a locked-out user does. And if you manage more than one self-hosted service on the same box, our Docker Compose tutorial covers running multiple stacks side by side cleanly, worth reading before your homelab turns into a tangle of one-off containers with no shared structure.

Finally, treat organizations as the default rather than an afterthought, even for a single household. Splitting a shared streaming password or a home network’s Wi-Fi key into an organization collection, separate from anyone’s personal items, means revoking one person’s access later doesn’t mean resetting passwords for everyone else too.

If you’re running several self-hosted services on the same box, whatever tool already aggregates their logs is worth pointing at Vaultwarden’s vaultwarden.log too, rather than leaving it as a file only Fail2ban ever reads. A single dashboard showing failed logins, certificate expiry dates, and container restarts across every service you self-host catches drift long before a client complains that sync has quietly stopped working.

Frequently Asked Questions About Vaultwarden

Is Vaultwarden affiliated with or endorsed by Bitwarden Inc.?
No. Vaultwarden is an independent, community-built project that reimplements the Bitwarden server API. It is not developed, reviewed, or supported by Bitwarden Inc., though it’s built specifically to work with Bitwarden’s official client apps.

Is Vaultwarden safe enough for real passwords, or just for testing?
Used correctly, meaning HTTPS enforced, signups disabled, two-factor authentication on, and regular backups in place, Vaultwarden is widely used in production by individuals and small teams. The security of your data depends far more on how you configure and maintain the server than on the software itself.

Can I migrate from a paid Bitwarden or 1Password account to Vaultwarden?
Yes. Export your existing vault in its encrypted export format and import it from inside your new Vaultwarden account. Both Bitwarden and 1Password support standard export formats designed for exactly this kind of move.

Does Vaultwarden support Bitwarden Send or passkey login?
Vaultwarden tracks the official Bitwarden API closely and has historically added support for features like Send and passkeys within a release or two of the official rollout. Check the current release notes on GitHub if a specific feature is essential for your setup.

What happens if I lose access to my server? Do I lose my vault forever?
Only if you also lose your backups. This is exactly why Step 10 isn’t optional: a backup stored off the server, tested at least once, is what separates a hardware failure from a catastrophe.

Can multiple people share one Vaultwarden instance as separate users?
Yes. Each person gets their own account with their own master password and private vault. Shared items go into an organization collection instead, so personal and shared passwords stay properly separated.

Do I need a paid domain name for this to work?
You need a domain Bitwarden clients can request a valid HTTPS certificate for, which usually means a real registered domain or subdomain. Dynamic DNS services work as long as they support standard DNS records for certificate validation.

How often should I update Vaultwarden?
Monthly at a minimum, and immediately for any release flagged as a security fix. Follow the update process in Step 12, and always take a backup first.

How much server capacity does Vaultwarden actually need?
Far less than the official self-hosted Bitwarden server, which runs Microsoft SQL Server alongside several supporting services. Vaultwarden runs as one lightweight container backed by SQLite, which is why the smallest tier of most VPS providers, or a low-power device already running other self-hosted services, handles it without strain.

Related Coverage

For the broader landscape of breaches and defensive tools this Vaultwarden setup sits alongside, see our full cybersecurity coverage.

Sofia Lindström

Editor-in-Chief

Sofia Lindström is the Editor-in-Chief at Tech Insider, where she leads editorial strategy and oversees coverage across AI, cybersecurity, and enterprise technology. With over a decade in Swedish tech journalism, she previously served as technology editor at Dagens Industri and covered the Nordic startup ecosystem for Breakit. Sofia holds an MSc in Media Technology from KTH Royal Institute of Technology and is a frequent speaker at Web Summit and Slush. She is passionate about making complex technology accessible to business leaders.

View all articles

How to Set Up Vaultwarden: 12 Steps, 80 Min [2026]