--- og_image: "/images/guides/vaultwarden-self-host-bitwarden-2026.webp" title: "Vaultwarden: Self-Host Bitwarden in 5 Minutes 2026" description: "Vaultwarden runs the full Bitwarden server in a single Docker container using under 50MB RAM. Raspberry Pi setup, HTTPS config, and team sharing guide." date: "2026-03-16" author: "OSSAlt Team" tags: ["vaultwarden", "bitwarden", "password-manager", "self-hosting", "raspberry-pi", "docker", "security"] --- # Vaultwarden: Self-Host Bitwarden in 5 Minutes Bitwarden is the best open-source password manager. The official server, however, requires 11 Docker containers and 3–4GB of RAM to run. Vaultwarden is a single Rust container that does everything the official server does — browser extensions, mobile apps, desktop clients, team sharing, TOTP, and emergency access — using under 50MB of RAM at idle. It runs on a Raspberry Pi Zero 2W. It runs on a $4/month VPS. It runs on a NAS. Anywhere Docker runs, Vaultwarden runs. Vaultwarden has 42,000+ GitHub stars, is licensed AGPL-3.0, and is compatible with every official Bitwarden client — iOS, Android, Chrome, Firefox, Safari, the lot. ## Quick Verdict If you're paying for 1Password Teams ($7.99/user/month) or Bitwarden Premium ($10/year per user), self-hosting Vaultwarden eliminates that cost entirely. For a team of 10, that's ~$960/year saved. For a team of 50, it's $4,800/year. --- ## Prerequisites - A server running Docker (Raspberry Pi 4, VPS, NAS, mini PC) - A domain or subdomain (HTTPS is required — browsers block password managers on HTTP) - 10 minutes For the Raspberry Pi: use the **64-bit version** of Raspberry Pi OS (Raspberry Pi Imager → Raspberry Pi OS Lite 64-bit). Vaultwarden's Docker image supports ARM64. --- ## Step 1: Create the Data Directory ```bash sudo mkdir -p /opt/vaultwarden/data ``` --- ## Step 2: Run Vaultwarden ```bash docker run -d \ --name vaultwarden \ -v /opt/vaultwarden/data/:/data/ \ -p 80:80 \ -e DOMAIN="https://vault.yourdomain.com" \ -e SIGNUPS_ALLOWED=true \ --restart unless-stopped \ vaultwarden/server:latest ``` Vaultwarden is now running at `http://your-server-ip:80`. You can't use it yet — browsers require HTTPS for password manager extensions to function. Proceed to Step 3. --- ## Step 3: Set Up HTTPS with Caddy (Easiest) Caddy is the simplest reverse proxy with automatic Let's Encrypt SSL. One file, zero configuration headaches. Install Caddy: ```bash sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list sudo apt update && sudo apt install caddy ``` Configure `/etc/caddy/Caddyfile`: ``` vault.yourdomain.com { reverse_proxy localhost:80 } ``` Restart Caddy: ```bash sudo systemctl restart caddy ``` Caddy automatically obtains and renews your Let's Encrypt certificate. That's it — no certbot, no nginx config, no certificate renewal cron jobs. --- ## Alternative: Docker Compose with Nginx Proxy Manager If you already use Nginx Proxy Manager (common on NAS or homelab setups): ```yaml # docker-compose.yml version: "3" services: vaultwarden: image: vaultwarden/server:latest container_name: vaultwarden volumes: - ./data:/data environment: - DOMAIN=https://vault.yourdomain.com - SIGNUPS_ALLOWED=true - WEBSOCKET_ENABLED=true restart: unless-stopped networks: - proxy nginx-proxy-manager: image: jc21/nginx-proxy-manager:latest container_name: nginx-proxy-manager ports: - "80:80" - "443:443" - "81:81" volumes: - ./npm/data:/data - ./npm/letsencrypt:/etc/letsencrypt restart: unless-stopped networks: - proxy networks: proxy: driver: bridge ``` ```bash docker compose up -d ``` In Nginx Proxy Manager (port 81): 1. Add Proxy Host → Domain: `vault.yourdomain.com` 2. Forward to: `vaultwarden` container, port 80 3. SSL → Request Let's Encrypt Certificate 4. Enable WebSocket support --- ## Step 4: Create Your Admin Account Navigate to `https://vault.yourdomain.com`. The first account you create is a regular user. To access the admin panel: 1. Stop signups after creating your accounts (security best practice): ```bash docker stop vaultwarden docker run -d \ --name vaultwarden \ -v /opt/vaultwarden/data/:/data/ \ -e DOMAIN="https://vault.yourdomain.com" \ -e SIGNUPS_ALLOWED=false \ -e ADMIN_TOKEN=$(openssl rand -base64 48) \ -p 80:80 \ --restart unless-stopped \ vaultwarden/server:latest ``` Note the `ADMIN_TOKEN` output — you'll need it to access `/admin`. 2. Save the admin token securely (ironically, in your password vault). 3. Access the admin panel: `https://vault.yourdomain.com/admin` --- ## Step 5: Install Bitwarden Clients Vaultwarden works with all official Bitwarden clients. No modifications needed. **Browser extensions:** - [Chrome/Edge](https://chromewebstore.google.com/detail/bitwarden/nngceckbapebfimnlniiiahkandclblb) - [Firefox](https://addons.mozilla.org/en-US/firefox/addon/bitwarden-password-manager/) - [Safari](https://apps.apple.com/app/bitwarden/id1352778147) **Mobile:** - [iOS](https://apps.apple.com/app/bitwarden-password-manager/id1137397744) - [Android](https://play.google.com/store/apps/details?id=com.x8bit.bitwarden) **Configure server in the client:** In the browser extension or mobile app: 1. Click the gear/settings icon before logging in 2. Select **Self-hosted** under Environment 3. Enter your server URL: `https://vault.yourdomain.com` 4. Save and log in with your account --- ## Team Sharing and Organizations Vaultwarden supports Bitwarden Organizations — the team sharing feature that costs $3/user/month on Bitwarden Cloud. Self-hosted: free. **Create an organization:** 1. Web vault → New Organization 2. Set organization name 3. Invite team members via email 4. Create Collections (shared folders) 5. Assign credentials to Collections **Share a credential:** - In any Bitwarden client, right-click an item → Move to Organization - Select the organization and collection - Set permissions (View only / Can edit) Email invites work if you configure SMTP in Vaultwarden. For teams, set up SMTP via your email provider: ```bash -e SMTP_HOST=smtp.yourprovider.com \ -e SMTP_PORT=587 \ -e SMTP_SECURITY=starttls \ -e SMTP_USERNAME=your@email.com \ -e SMTP_PASSWORD=yourpassword \ -e SMTP_FROM=vault@yourdomain.com \ ``` --- ## Security Hardening **Disable signups after setup:** ```bash SIGNUPS_ALLOWED=false ``` **Enable 2FA for admin (in admin panel):** The admin panel has its own 2FA separate from user accounts. Enable it. **Require 2FA for all users (optional):** ```bash SIGNUPS_ALLOWED=true SIGNUPS_VERIFY=true REQUIRE_DEVICE_EMAIL=true ``` **Rate limiting:** Vaultwarden has built-in rate limiting. Add Fail2Ban for additional protection: ```bash # /etc/fail2ban/filter.d/vaultwarden.conf [Definition] failregex = ^.*Username or password is incorrect\. Try again\. IP: \. Username:.*$ ignoreregex = ``` **Enable WebSocket notifications (recommended):** ```bash WEBSOCKET_ENABLED=true ``` WebSocket enables real-time vault sync across clients — when you add a password on mobile, it appears immediately on desktop. --- ## Backups Your entire Vaultwarden instance is in the `/data` directory. Back it up daily: ```bash # Simple daily backup script #!/bin/bash BACKUP_DIR="/opt/backups/vaultwarden" DATE=$(date +%Y-%m-%d) mkdir -p $BACKUP_DIR # Stop vaultwarden briefly for consistent backup docker stop vaultwarden cp -r /opt/vaultwarden/data/ "$BACKUP_DIR/$DATE/" docker start vaultwarden # Delete backups older than 30 days find $BACKUP_DIR -type d -mtime +30 -exec rm -rf {} + ``` Add to cron: ```bash 0 3 * * * /opt/scripts/backup-vaultwarden.sh ``` **Off-site:** Sync the backup directory to Backblaze B2 or an external drive with rclone. A Vaultwarden data directory is typically under 100MB even for large teams — trivially cheap to store off-site. --- ## Raspberry Pi-Specific Notes **Use 64-bit OS:** The ARM64 image is required for Vaultwarden on Pi 4/5. Pi Zero 2W also supports ARM64 but is slower for initial setup. **USB storage > SD card:** Run Vaultwarden's `/data` directory from a USB drive or SSD, not the SD card. SD cards fail under constant write load. ```bash # Mount USB drive sudo mount /dev/sda1 /opt/vaultwarden/data # Add to /etc/fstab for persistence ``` **RAM usage:** Vaultwarden uses <50MB RAM at idle, <100MB under load. A Pi 4 with 2GB RAM handles it effortlessly. A Pi Zero 2W (512MB) also works fine. **Power:** A Pi running 24/7 as a Vaultwarden server costs ~$3–5/year in electricity — less than one month of 1Password. --- ## Migrating from 1Password, LastPass, or Bitwarden Cloud All major password managers export to CSV. Bitwarden's import tool handles all formats: 1. Export from your current manager (CSV or proprietary format) 2. Log into your Vaultwarden instance → Tools → Import Data 3. Select format and upload file 4. Verify import (check item count matches) For Bitwarden Cloud migration specifically: 1. Bitwarden Cloud → Account Settings → Security → Encryption Key → Export Vault → `.json` (encrypted) 2. On Vaultwarden → Import → Bitwarden (encrypted JSON) 3. Your passwords, folders, and organizations transfer with zero data loss --- ## What You Get vs What You Lose vs Bitwarden Cloud | Feature | Vaultwarden (self-hosted) | Bitwarden Cloud | |---------|--------------------------|-----------------| | **Cost** | Free (+ server costs) | $10/year personal, $3/user/month teams | | **All clients** | ✅ | ✅ | | **Organizations/sharing** | ✅ | ✅ | | **2FA (TOTP)** | ✅ | ✅ | | **Emergency access** | ✅ | ✅ | | **Secure notes** | ✅ | ✅ | | **File attachments** | ✅ | ✅ (limited on free) | | **Bitwarden authenticator** | ✅ | ✅ | | **Official support** | Community only | ✅ | | **Uptime SLA** | You manage it | 99.9%+ | | **SOC 2 compliance** | No | ✅ | | **HIPAA** | No (your setup) | Business plans | For personal use and small teams that trust their own infrastructure, Vaultwarden is objectively the better deal. For enterprise compliance requirements (HIPAA, SOC 2), Bitwarden's official cloud plans are worth the cost. --- ## Keeping Vaultwarden Updated ```bash # Pull latest image and restart docker pull vaultwarden/server:latest docker stop vaultwarden docker rm vaultwarden docker run -d \ --name vaultwarden \ -v /opt/vaultwarden/data/:/data/ \ -e DOMAIN="https://vault.yourdomain.com" \ -e SIGNUPS_ALLOWED=false \ -p 80:80 \ --restart unless-stopped \ vaultwarden/server:latest ``` Or with Docker Compose, simply: ```bash docker compose pull && docker compose up -d ``` Vaultwarden releases are stable. Update monthly or whenever a security patch is announced on their [GitHub releases page](https://github.com/dani-garcia/vaultwarden/releases). --- ## Advanced Configuration Reference ### Full Environment Variables The most useful Vaultwarden configuration options: ```bash # Core DOMAIN=https://vault.yourdomain.com SIGNUPS_ALLOWED=false # Disable after initial setup ADMIN_TOKEN=your_token_here # Access /admin panel # Email (required for invites and 2FA recovery) SMTP_HOST=smtp.gmail.com SMTP_PORT=587 SMTP_SECURITY=starttls SMTP_USERNAME=your@gmail.com SMTP_PASSWORD=your_app_password # Use Gmail App Password SMTP_FROM=vault@yourdomain.com SMTP_FROM_NAME=Vaultwarden # Security DISABLE_2FA_REMEMBER=false # Allow 2FA remember-me LOGIN_RATELIMIT_MAX_BURST=10 # Max login attempts before throttle LOGIN_RATELIMIT_SECONDS=60 # Throttle window in seconds # Performance WEB_VAULT_ENABLED=true # Web UI (disable if clients-only) WEBSOCKET_ENABLED=true # Real-time sync notifications ``` ### Invitation-Only Registration For team setups, disable open registration and invite users via email: ```bash SIGNUPS_ALLOWED=false INVITATIONS_ALLOWED=true # Allow admin to invite users SMTP_HOST=... # SMTP required for invites ``` In the admin panel → Users → Invite User. --- ## Disaster Recovery Your password manager is critical infrastructure. Plan for failure: **What to back up:** ``` /opt/vaultwarden/data/ ├── db.sqlite3 # All vault data ├── rsa_key.pem # Encryption keys — CRITICAL ├── rsa_key.pub.pem ├── attachments/ # File attachments └── sends/ # Bitwarden Send files ``` The `rsa_key.pem` and `rsa_key.pub.pem` files are the most critical. Without them, encrypted vault data cannot be decrypted even if you have the SQLite database. Back these up separately from the rest of the data. **Recovery procedure:** 1. Deploy fresh Vaultwarden instance on new server 2. Restore `/data` directory from backup 3. Update DNS/proxy to point to new server 4. All clients reconnect automatically on next sync With good backups, full recovery takes under 30 minutes. --- ## Frequently Asked Questions **Is Vaultwarden officially supported by Bitwarden?** No. Vaultwarden is a community project that reimplements the Bitwarden server API. Bitwarden Inc. didn't create it and doesn't officially support it. The project has been running since 2018 (originally as bitwarden_rs) and is stable, but it's community-maintained. **Will official Bitwarden clients always work with Vaultwarden?** Generally yes, but there can be compatibility lag when Bitwarden adds new API endpoints. Vaultwarden's maintainers typically update within weeks of new Bitwarden client releases. Check the [Vaultwarden GitHub](https://github.com/dani-garcia/vaultwarden) before major client updates. **Can I use hardware security keys (YubiKey, FIDO2)?** Yes — Vaultwarden supports WebAuthn (FIDO2), which includes YubiKey, Apple Face ID, Windows Hello, and any FIDO2-compatible key. Configure in account settings → Security → Two-step Login. **What if I lose my admin token?** Restart the container with a new `ADMIN_TOKEN` environment variable. Changing the token doesn't affect user accounts or vault data. **Can I run Vaultwarden on a $4/month VPS?** Yes — Vaultwarden uses under 50MB RAM. A $4–5/month VPS (Hetzner CX11, DigitalOcean Droplet) handles it comfortably for small teams. Include Nginx or Caddy for SSL and you still have resources to spare. **Is it legal to use Vaultwarden?** Vaultwarden is open source and fully legal. It implements Bitwarden's open-source API specification. Bitwarden's clients are also open source. There's no legal issue with self-hosting your own password server. --- *See all password manager alternatives at [OSSAlt](https://ossalt.com).* *Related: [10 Open-Source Tools to Replace SaaS in 2026](/guides/open-source-saas-alternatives-2026) · [Self-Host Your AI: Ollama + Open WebUI 2026](/guides/ollama-open-webui-self-host-ai-2026)* *See open source alternatives to Vaultwarden on [OSSAlt](https://www.ossalt.com/alternatives/vaultwarden).* ## Security Gains Only Count If You Reduce Hidden Trust Self-hosting can improve security, but only when it reduces trust assumptions instead of moving them around. Bringing a service in-house is not automatically safer if the result is one unpatched VPS, a wide-open admin panel, and no log review. The real gain comes from shrinking who can read the data, who can change configuration, and how many external processors sit between your users and their information. That is why privacy and security articles need to focus on control boundaries. Ask which credentials unlock the system, where audit trails live, and how incident response changes when the software is on infrastructure you administer directly. Useful adjacent tools reinforce that boundary model. [Vaultwarden guide](/guides/how-to-self-host-vaultwarden-bitwarden-password-manager-2026) matters because weak shared secrets are still one of the fastest ways to negate every other security measure. [CrowdSec guide](/guides/how-to-self-host-crowdsec-collaborative-security-2026) belongs in the conversation because exposure without ban rules or log-based detection is just optimism. [Authelia guide](/guides/how-to-self-host-authelia-authentication-middleware-2026) is the missing layer when teams have multiple internal apps but no unified MFA and policy engine. None of those tools replaces process, but together they make a small-team security posture far more coherent. ## A Defensible Security Baseline for Small Teams For most organizations, the defensible baseline is surprisingly attainable. Put admin interfaces behind SSO or at least MFA, remove public exposure where a VPN or access gateway is enough, enforce automatic updates on the host OS, send logs somewhere durable, and test restores regularly. Then document one incident playbook that covers credential compromise, failed upgrades, and suspicious traffic spikes. That playbook does not have to be enterprise-grade to be valuable. It only has to exist before the bad day arrives. The practical advantage of open source here is inspectability and composability. You can audit default settings, place reverse proxies and WAF rules in front of services, and export metrics into your own monitoring stack. More importantly, you can keep sensitive workloads off third-party dashboards entirely. That combination of transparency and constrained trust is the strongest argument for self-hosted security-minded systems, and it is more persuasive than any simplistic claim that open source is inherently safer. ## Related Reading - [Vaultwarden guide](/guides/how-to-self-host-vaultwarden-bitwarden-password-manager-2026) - [CrowdSec guide](/guides/how-to-self-host-crowdsec-collaborative-security-2026) - [Authelia guide](/guides/how-to-self-host-authelia-authentication-middleware-2026) ## Security Gains Only Count If You Reduce Hidden Trust Self-hosting can improve security, but only when it reduces trust assumptions instead of moving them around. Bringing a service in-house is not automatically safer if the result is one unpatched VPS, a wide-open admin panel, and no log review. The real gain comes from shrinking who can read the data, who can change configuration, and how many external processors sit between your users and their information. That is why privacy and security articles need to focus on control boundaries. Ask which credentials unlock the system, where audit trails live, and how incident response changes when the software is on infrastructure you administer directly. Useful adjacent tools reinforce that boundary model. [Vaultwarden guide](/guides/how-to-self-host-vaultwarden-bitwarden-password-manager-2026) matters because weak shared secrets are still one of the fastest ways to negate every other security measure. [CrowdSec guide](/guides/how-to-self-host-crowdsec-collaborative-security-2026) belongs in the conversation because exposure without ban rules or log-based detection is just optimism. [Authelia guide](/guides/how-to-self-host-authelia-authentication-middleware-2026) is the missing layer when teams have multiple internal apps but no unified MFA and policy engine. None of those tools replaces process, but together they make a small-team security posture far more coherent. ## A Defensible Security Baseline for Small Teams For most organizations, the defensible baseline is surprisingly attainable. Put admin interfaces behind SSO or at least MFA, remove public exposure where a VPN or access gateway is enough, enforce automatic updates on the host OS, send logs somewhere durable, and test restores regularly. Then document one incident playbook that covers credential compromise, failed upgrades, and suspicious traffic spikes. That playbook does not have to be enterprise-grade to be valuable. It only has to exist before the bad day arrives. The practical advantage of open source here is inspectability and composability. You can audit default settings, place reverse proxies and WAF rules in front of services, and export metrics into your own monitoring stack. More importantly, you can keep sensitive workloads off third-party dashboards entirely. That combination of transparency and constrained trust is the strongest argument for self-hosted security-minded systems, and it is more persuasive than any simplistic claim that open source is inherently safer. ## Related Reading - [Vaultwarden guide](/guides/how-to-self-host-vaultwarden-bitwarden-password-manager-2026) - [CrowdSec guide](/guides/how-to-self-host-crowdsec-collaborative-security-2026) - [Authelia guide](/guides/how-to-self-host-authelia-authentication-middleware-2026) ## Security Gains Only Count If You Reduce Hidden Trust Self-hosting can improve security, but only when it reduces trust assumptions instead of moving them around. Bringing a service in-house is not automatically safer if the result is one unpatched VPS, a wide-open admin panel, and no log review. The real gain comes from shrinking who can read the data, who can change configuration, and how many external processors sit between your users and their information. That is why privacy and security articles need to focus on control boundaries. Ask which credentials unlock the system, where audit trails live, and how incident response changes when the software is on infrastructure you administer directly. Useful adjacent tools reinforce that boundary model. [Vaultwarden guide](/guides/how-to-self-host-vaultwarden-bitwarden-password-manager-2026) matters because weak shared secrets are still one of the fastest ways to negate every other security measure. [CrowdSec guide](/guides/how-to-self-host-crowdsec-collaborative-security-2026) belongs in the conversation because exposure without ban rules or log-based detection is just optimism. [Authelia guide](/guides/how-to-self-host-authelia-authentication-middleware-2026) is the missing layer when teams have multiple internal apps but no unified MFA and policy engine. None of those tools replaces process, but together they make a small-team security posture far more coherent. ## A Defensible Security Baseline for Small Teams For most organizations, the defensible baseline is surprisingly attainable. Put admin interfaces behind SSO or at least MFA, remove public exposure where a VPN or access gateway is enough, enforce automatic updates on the host OS, send logs somewhere durable, and test restores regularly. Then document one incident playbook that covers credential compromise, failed upgrades, and suspicious traffic spikes. That playbook does not have to be enterprise-grade to be valuable. It only has to exist before the bad day arrives. The practical advantage of open source here is inspectability and composability. You can audit default settings, place reverse proxies and WAF rules in front of services, and export metrics into your own monitoring stack. More importantly, you can keep sensitive workloads off third-party dashboards entirely. That combination of transparency and constrained trust is the strongest argument for self-hosted security-minded systems, and it is more persuasive than any simplistic claim that open source is inherently safer. ## Related Reading - [Vaultwarden guide](/guides/how-to-self-host-vaultwarden-bitwarden-password-manager-2026) - [CrowdSec guide](/guides/how-to-self-host-crowdsec-collaborative-security-2026) - [Authelia guide](/guides/how-to-self-host-authelia-authentication-middleware-2026)