Vaultwarden is an independent Rust implementation of the Bitwarden server, compatible with the official clients and browser extensions but noticeably lighter on resources. For a team that does not want to keep passwords in a cloud service running on someone else's infrastructure, Vaultwarden on your own VDS is a workable option, provided the administrator is ready to take responsibility for backups, updates, and server access.
What Vaultwarden is and when it fits
Vaultwarden stores an encrypted password vault and syncs it with the official Bitwarden apps for desktop, mobile, and browsers — from the client's point of view there is no difference from cloud Bitwarden besides the server address entered on first login. Unlike the official Bitwarden server software written in .NET, Vaultwarden needs noticeably less memory and CPU time, so it fits on a small VDS alongside other services.
The self-hosted option fits when a team is ready to handle updates, monitoring, and backups on its own: unlike a cloud service, nobody here restores access if both the master password and the database backup are lost at once. Without that readiness, it is safer to stay with one of the password managers covered in the article "Secure passwords and password managers".
Running it in Docker
Vaultwarden is officially distributed as a Docker image, and running it through docker-compose is the most predictable way to deploy it on a VDS: an update comes down to changing the image tag and restarting the container rather than manually installing dependencies. The basic steps for setting up Docker on a server are described in the article "Docker on a VPS: installing and running containers".
The data — an encrypted SQLite database (or an external PostgreSQL for heavier loads) and a folder with attached files — must live in a volume mounted from the host, not inside the container layer: when the image is updated, the container layer is recreated, and anything left inside it rather than in the volume is lost.
TLS and a reverse proxy
Bitwarden clients refuse to work with a server that lacks valid HTTPS, so Vaultwarden is almost always deployed behind a reverse proxy that handles TLS while the service itself listens only on an internal port. Nginx with a Let's Encrypt certificate is the standard pairing; the issuance and renewal process is described in the article "Setting up SSL on Nginx with Certbot".
A separate rule applies to the WebSocket endpoint used for live notifications between devices: it must be explicitly proxied with the Upgrade and Connection headers, otherwise sync between clients only happens on a timer rather than instantly.
Admin token and limiting sign-ups
Vaultwarden's admin panel is available by default at /admin and is protected only by the token set through the ADMIN_TOKEN environment variable: if the token is unset or weak, the panel is open to practically anyone who learns the path. The token should be generated as a long random string and kept only in environment variables, not in a file that could end up in a repository.
By default the server allows anyone who knows the address to register a new account. For a team with a known roster, sign-ups should be closed with SIGNUPS_ALLOWED=false right after creating the needed accounts, otherwise the database stays open to outside registration.
Backups
Losing the Vaultwarden database without a backup means losing every stored password at once, not just one service — this sets a password manager apart from most other VDS services in terms of how severe a failure is. A backup of the database file and the attachments folder should be taken regularly and kept separately from the server itself, not just locally next to the data.
The encrypted database itself is useless without the user's master password, so the backup can be stored less strictly than, say, an unencrypted payment data dump, but access to it should still be restricted: an offline copy lets an attacker try to guess the master password without the attempt limits a live server enforces.
- HTTPS is enabled, and clients connect only over a secured address
- ADMIN_TOKEN is set to a long random string, not left empty
- SIGNUPS_ALLOWED is turned off after the needed accounts are created
- Data is moved into a volume rather than kept inside the container layer
- A backup of the database and files is set up and verified by a restore
| Parameter | Default value | Recommendation |
|---|---|---|
| ADMIN_TOKEN | not set | a long random string in environment variables |
| SIGNUPS_ALLOWED | true | false after accounts are created |
| Data storage | SQLite inside the container | a host volume, outside the image layer |
| RAM | — | usually 512 MB-1 GB is enough for a small team |
services:
vaultwarden:
image: vaultwarden/server:latest
restart: unless-stopped
environment:
- ADMIN_TOKEN=change-me-to-a-long-random-string
- SIGNUPS_ALLOWED=false
volumes:
- ./vw-data:/data
ports:
- "127.0.0.1:8080:80"Frequently asked questions
Should Vaultwarden be run without a reverse proxy and TLS even just for a test?
Bitwarden clients refuse by default to connect to a server without HTTPS, so even for a test it is simpler to set up a reverse proxy with a certificate right away than to use HTTP temporarily and later figure out why the client will not sync. A certificate can be issued in a few minutes, so there is no point in putting this off.
How much VDS capacity does Vaultwarden need?
For a small team, 1 vCPU and 512 MB-1 GB of RAM are usually enough — Vaultwarden is noticeably lighter than the official .NET-based Bitwarden server. The exact figure depends on the number of users, the size of attached files, and whatever other services run on the same VDS.
What if the ADMIN_TOKEN is forgotten?
Access to the admin panel cannot be recovered without the correct token — a new value for ADMIN_TOKEN has to be set in the configuration and the container restarted; this does not affect passwords users already saved. A user's master password is a separate secret, and losing the ADMIN_TOKEN has no effect on it.