Why Run Your Own Password Manager?
Password managers have become standard practice for anyone serious about digital security. The problem with most popular services is simple: your encrypted vault lives on someone else’s server, managed by a company whose security practices, business decisions, and data retention policies you cannot audit. When that company gets acquired, changes its pricing, or suffers a breach, you find out after the fact. Vaultwarden flips that model entirely – it is a lightweight, open-source reimplementation of the Bitwarden server API that runs on your own hardware, giving you full control over where your passwords live and who can access them.
Unlike running the official Bitwarden server, which requires significant memory and a more complex setup, Vaultwarden is built in Rust and runs comfortably on a Raspberry Pi or any low-spec machine. It supports the full Bitwarden client ecosystem – browser extensions, desktop apps, and mobile apps all connect to it without modification. This guide walks through setting up Vaultwarden using Docker, securing it with an SSL certificate, and connecting your Bitwarden clients to your own instance.
Prerequisites and What You Will Need
Before starting, you need a Linux-based server or VPS with Docker and Docker Compose installed. A domain name pointing to your server is required because Bitwarden clients refuse to connect over plain HTTP – HTTPS is enforced at the client level, not optional. If you are managing other Docker containers already, you may have a reverse proxy like Nginx Proxy Manager or Traefik in place, which will handle your SSL termination. If not, this guide uses Caddy as a straightforward option that handles certificate issuance automatically.
Make sure ports 80 and 443 are open on your server’s firewall and forwarded correctly if you are behind a home router. You will also want to set a strong admin token ahead of time – this token protects the Vaultwarden admin panel and should be treated like a root password. Generate one using openssl rand -base64 48 from your terminal before writing your compose file.
Setting Up Vaultwarden with Docker Compose
Create a project directory – something like /opt/vaultwarden – and inside it create a docker-compose.yml file. The core Vaultwarden service pulls from the official vaultwarden/server:latest image. You will map a local data directory into the container at /data, which is where Vaultwarden stores its SQLite database, attachments, and configuration. Set the DOMAIN environment variable to your full HTTPS URL, and set ADMIN_TOKEN to the value you generated earlier. Disable signups initially by setting SIGNUPS_ALLOWED to false unless you are specifically opening registration to others.
Alongside the Vaultwarden service, add a Caddy container to the same compose file. Caddy handles reverse proxying and automatic Let’s Encrypt certificate issuance. Create a Caddyfile in your project directory with a single block: your domain name as the site address, and a reverse_proxy vaultwarden:80 directive pointing at the Vaultwarden container. Because both containers are in the same Docker network defined in your compose file, Caddy can reach Vaultwarden by its service name directly.
Your final docker-compose.yml should define two services – vaultwarden and caddy – both attached to a shared network. Mount the Caddyfile into the Caddy container at /etc/caddy/Caddyfile, and mount a persistent volume for Caddy’s certificate data so certificates survive container restarts. Run docker compose up -d from your project directory. Caddy will request a certificate from Let’s Encrypt within seconds of starting, as long as your DNS is pointed correctly and port 80 is reachable for the ACME challenge.
Once the stack is running, visit https://yourdomain.com in a browser. You should see the Vaultwarden login screen. Navigate to https://yourdomain.com/admin and enter your admin token to access the admin panel, where you can invite users, review configuration, and monitor the instance. At this point, the server is live and ready to accept client connections. If you see a certificate warning, Caddy has not yet completed the ACME handshake – wait thirty seconds and refresh.
Connecting Bitwarden Clients to Your Instance
Because Vaultwarden implements the full Bitwarden API, every official Bitwarden client works with it without any modification or unofficial builds. On the browser extension, click the region selector on the login screen and choose “Self-hosted.” Enter your domain in the server URL field and save. The same process applies on iOS and Android – open the Bitwarden app, tap the region selector before logging in, switch to self-hosted, and enter your URL. Create your account on the web vault at your domain, then log in from any client using those credentials.
Two-factor authentication works the same way it does on the cloud version. Authenticator app TOTP, email codes, and Duo are all supported through the standard Bitwarden account security settings. Vault backup is straightforward since all data lives in a single SQLite file at your mapped data directory – a nightly cron job copying that file to off-site storage is all the disaster recovery you need.
Ongoing Maintenance and Security Hardening
Keeping Vaultwarden updated is a matter of pulling the latest image and restarting the stack. Run docker compose pull followed by docker compose up -d to update in place. The SQLite database schema updates automatically on startup when a new version requires it. Because Vaultwarden follows Bitwarden’s API closely, it is worth checking the Vaultwarden GitHub releases page after any major Bitwarden client update to confirm compatibility before updating the server.
Rate limiting and brute force protection are built into Vaultwarden by default, but exposing any authentication endpoint to the public internet warrants additional attention. Consider placing your admin panel behind an IP allowlist using Caddy’s remote_ip matcher, restricting access to the admin route to your home or VPN IP only. The admin token alone is a single factor – if your admin URL is guessable and your token is weak, the panel is a liability.
For organizations running multiple self-hosted services, Vaultwarden fits naturally alongside other Docker-based tools. If you are already running containers with a visual management interface like Portainer, you can monitor your Vaultwarden stack there directly. The data directory should be excluded from any container snapshots and backed up separately since it contains your actual credential database – losing it means losing every password stored in the vault.
