Deploy Vaultwarden on a VPS: self-hosted password manager

Why self-host your password manager?

Key benefits

• 100% compatible with all official Bitwarden clients — no fork, no custom app, nothing to relearn
• End-to-end AES-256 encryption: your master password never leaves your device
• Under 50 MB of RAM at rest — runs comfortably on a 512 MB VPS alongside other services
• All users and organization vaults, with encrypted sharing and role-based access
• Built-in TOTP authenticator: replace Google Authenticator with a self-hosted alternative
• Emergency access — grant a trusted contact read access after a configurable waiting period

Prerequisites

Deploy Vaultwarden in 5 steps

1. 01

   Install Docker

   If Docker is not already installed: curl -fsSL https://get.docker.com | sh && systemctl enable --now docker. Verify with docker --version.

2. 02

   Start Vaultwarden

   Launch the container: docker run -d --name vaultwarden --restart=always -v vaultwarden:/data -p 127.0.0.1:8000:80 -e WEBSOCKET_ENABLED=true vaultwarden/server:latest. The server starts in under a second and listens on port 8000 on localhost.

3. 03

   Configure HTTPS with Caddy

   Install Caddy: apt install -y caddy. Create /etc/caddy/Caddyfile with: passwords.your-domain.com { reverse_proxy localhost:8000 }. Reload Caddy: systemctl reload caddy. A Let's Encrypt TLS certificate is provisioned automatically and renewed indefinitely — zero configuration.

4. 04

   Create your account

   Open https://passwords.your-domain.com in your browser. Click "Create Account", choose a strong master password (it encrypts everything locally before anything is sent to the server), and your vault is active immediately.

5. 05

   Lock down registrations

   Once all accounts are created, stop the container and relaunch it adding -e SIGNUPS_ALLOWED=false to the docker run command. Your instance is now invite-only. For ongoing user management, enable the admin panel by adding -e ADMIN_TOKEN=$(openssl rand -base64 48).

6. 06

   First login

   When you first open the URL, Vaultwarden displays the Bitwarden web vault: click "Create account" and set your own email and master password (it is not recoverable by anyone, not even by us). Do this IMMEDIATELY: registration is open.

Configure SMTP and email-based 2FA

Configure SMTP correctly

1. 07

   Choose port and security based on your provider

   Check the documentation of your SMTP relay (Gmail, Brevo, Postmark, SendGrid…). Practical rule: if your provider specifies port 465 → SMTP_SECURITY=force_tls; if it specifies port 587 → SMTP_SECURITY=starttls. Never mix the two.

2. 08

   Pass SMTP variables to the container

   Relaunch the container with the required variables:

   docker run -d --name vaultwarden --restart=always \
     -v vaultwarden:/data \
     -p 127.0.0.1:8000:80 \
     -e SMTP_HOST=smtp.your-provider.com \
     -e [email protected] \
     -e SMTP_PORT=587 \
     -e SMTP_SECURITY=starttls \
     -e SMTP_USERNAME=your_login \
     -e SMTP_PASSWORD=your_password \
     vaultwarden/server:latest

3. 09

   Test sending from the admin panel

   Open https://passwords.your-domain.com/admin, scroll to the SMTP Email Settings section and use the Send test email button. If the email doesn't arrive within 60 seconds, check the container logs: docker logs vaultwarden 2>&1 | grep -i smtp. A Connection refused message indicates the wrong port; a TLS handshake error indicates a security mismatch.

4. 10

   Enable email 2FA only after validating sending

   Only enable _ENABLE_EMAIL_2FA=true once the test send is confirmed. If you enable it first, users whose client requests a code receive nothing and get locked out. To unblock a locked account: open /admin, locate the user and click Deactivate TOTP to temporarily disable 2FA.

Client/server compatibility and silent errors

Symptoms of a client/server version mismatch

• Cannot log in on a new device or browser, while existing devices work normally
• Generic error message with no cause indicated ("An error has occurred" or "Invalid username or password")
• Freshly installed Chrome or Firefox extension fails, but the same version on another machine works
• The Bitwarden web vault hosted on your instance returns 404 on /identity/accounts/prelogin/password
• No errors in server-side Vaultwarden logs — the endpoint doesn't exist, there's nothing to log
• The problem appeared after an automatic Bitwarden client update on the new device

Diagnose and resolve the mismatch

1. 11

   Check your server version

   Query the version endpoint: curl https://your-domain.com/api/version. If the response shows a version earlier than 1.36.0, your server doesn't support the new authentication flow used by recent clients.

2. 12

   Update to the latest image

   The safest approach is to always use vaultwarden/server:latest and keep the image up to date. To update: docker pull vaultwarden/server:latest && docker stop vaultwarden && docker rm vaultwarden, then rerun the same docker run command as at installation. Vaultwarden preserves data in the volume — no manual migration needed.

3. 13

   Verify the update took effect

   After restarting, query curl https://your-domain.com/api/version again and confirm the version is 1.36.0 or higher. Then test login from a new private browsing tab.

4. 14

   Pin a version if stability is the priority

   If you prefer to control updates manually, use a versioned tag: vaultwarden/server:1.37.2 for example. In that case, monitor releases on GitHub and update whenever a new Bitwarden client version is deployed — the two are coupled.

Empty vault after updating to Bitwarden clients 2026.8.0: diagnosis and fix

Symptoms of this compatibility gap

• Login is accepted, but the vault is empty or never finishes loading after sync
• No autofill suggestions, a desktop app that crashes, or an extension showing "failed to fetch"
• In the browser console, the error RangeError: Invalid time value in toSdkPolicyView (seen in issue #7612)
• No error in the Vaultwarden server logs
• Mostly reported on accounts that belong to an organization with at least one configured policy, even a disabled one; the web vault served by Vaultwarden works

Diagnose and repair an empty vault

1. 15

   Check the server version

   Open /admin/diagnostics or run docker exec vaultwarden /vaultwarden --version. You need 1.37.2 at minimum for 2026.8.0+ clients. Also make sure only one instance is running: a duplicated compose file has caused identical symptoms before.

2. 16

   Update the server if needed

   Use the same procedure as for any update (pull the image, recreate the container on the same volume). Aim straight for the latest version: see the 1.37.4 section below.

3. 17

   Clean the client's local state

   Log out completely, then log back in. If the vault stays empty, clearing the extension storage (the policies entries) or uninstalling and reinstalling it fixes most cases. On macOS, some users had to delete the desktop app's container data before signing in again.

4. 18

   Check the environment before downgrading

   Look at /admin/diagnostics for missing headers (a TOTP failure was fixed that way), keep the admin panel and the vault on the same domain, and test with ad blockers disabled. Only as a last resort, roll clients back to 2026.7.0, the version that worked for the first reporters, until the server is updated.

Update 1.37.4: seven security fixes and breaking changes to know

The seven security advisories in 1.37.4

• Organization member revocation: high severity, 8.1 (GHSA-69q9-v8p6-xvx3)
• Two-factor authentication: medium severity, 6.8 (GHSA-7jg8-8m5x-6j9r)
• Organization invitations: medium severity, 6.8 (GHSA-v576-3wvq-xh3c)
• Attachments: medium severity, 6.5 (GHSA-q5x6-grh5-fqgc)
• Organization event logs: medium severity, 4.3 (GHSA-64mc-4p6f-r7x9)
• Cipher sharing: medium severity, 4.3 (GHSA-7ccc-c43j-4p36)
• Organization API key: low severity, 3.8 (GHSA-qwx4-wcv4-mpcv)

Before moving to 1.37.4: what can break

1. 19

   Reverse proxy and client IP

   With IP_HEADER=X-Forwarded-For, the retained address is now the rightmost one that is not listed in IP_HEADER_TRUSTED_PROXIES (it used to be the leftmost). If several proxies sit in a row in front of Vaultwarden, list them all in IP_HEADER_TRUSTED_PROXIES, otherwise your logs and rate limits will see the wrong address.

2. 20

   Sends and the CLI

   bw send receive no longer works with CLI 2026.4.2 and older. Creating and managing Sends still works on all clients: update the CLI if you receive Sends on the command line.

3. 21

   MariaDB or MySQL without TLS

   If your database server does not support native TLS connections, the Alpine image may fail to connect to it. Add MARIADB_TLS_DISABLE_PEER_VERIFICATION=1 to Vaultwarden's environment. With SQLite, the default in this guide, you are not affected.

4. 22

   Removed options and endpoints

   Several experimental flags (for example ssh-agent or mutual-tls) were removed: if they are still listed in EXPERIMENTAL_CLIENT_FEATURE_FLAGS, startup logs a warning and saving admin panel settings fails until you remove them. DUO_USE_IFRAME is removed and ignored. The legacy POST /identity/accounts/register and POST /api/accounts/prelogin endpoints are gone; the notes say no current client uses them.

5. 23

   Rotate the organization API key

   Before this release, an organization's Admins could also view its API key. If some of them are not fully trusted, rotate the key after updating (Admin Console, Settings, Rotate API key).

Bitwarden moves to dual licensing: what changes, what does not

What changes and what does not for Vaultwarden

• Does not change: Bitwarden states there is no change to self-hosting; the Vaultwarden server is an independent project under the AGPL-3.0 license and is not affected by the clients' license
• Does not change: current features remain available in both client versions, free plan included; existing users are asked to do nothing
• Watch: Bitwarden warns that some future components will only be published under the commercial license, and that each new feature will be judged case by case; store clients and the GPLv3 build could diverge
• Watch: if a future feature exists only in the commercial build, nothing guarantees it works with a third-party server; test each client update on a secondary account before rolling it out
• If you want to stay on GPLv3 code, you can build the clients from the GitHub repository, at the cost of maintaining them yourself