Vaultwarden: Self-Hosted Password Manager for Teams

Passwords remain the weakest link in enterprise security — especially in teams where multiple people share access to systems. Cloud services like 1Password or LastPass are convenient, but they raise fundamental questions for privacy-conscious organizations: Where are the credentials stored? Who has theoretical access? What happens in a vendor breach? Vaultwarden answers these questions with a clear solution: full control, your own server, no third-party dependency.

Why a Self-Hosted Password Manager?

The decision to self-host a password manager is not ideological — it is pragmatic. For businesses that process personal data, the GDPR mandates technical and organizational measures to protect that data. A cloud-based password manager means that credentials to internal systems reside with a third party — often in a data center outside the EU.

Then there is the vendor lock-in problem: if pricing, ownership, or terms of service change, teams face a serious operational challenge. Migrating an entire organization’s password manager is a significant undertaking.

Feature	Vaultwarden (Self-Hosted)	Bitwarden Cloud	1Password Teams	KeePass
Data sovereignty	Full	Limited	Limited	Full
GDPR compliance	Yes (own server)	Conditional	Conditional	Yes
Browser extension	Yes (Bitwarden-compatible)	Yes	Yes	Plugins
Mobile apps	Yes (iOS + Android)	Yes	Yes	Yes (third-party)
Organizations / teams	Yes	Yes (paid)	Yes	No
2FA enforcement	Yes	Yes (Business)	Yes	No
Monthly cost	Server costs only	From $3/user	From $7/user	Free
API compatibility	Bitwarden API	Bitwarden API	Proprietary	No

Vaultwarden is a lightweight, unofficial implementation of the Bitwarden server protocol written in Rust. It is fully compatible with all official Bitwarden clients — browser extensions, desktop apps, and mobile apps work without any modifications. Unlike the official Bitwarden server, Vaultwarden does not require a Microsoft SQL Server instance. It runs on a single SQLite database, making it ideal for small VMs or even a Raspberry Pi.

Deploying Vaultwarden with Docker

The simplest and recommended approach is running Vaultwarden via Docker Compose. It requires only a volume for the database and — for production environments — a reverse proxy for HTTPS termination.

# docker-compose.yml
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "false"        # Disable open registration after setup
      ADMIN_TOKEN: "${VW_ADMIN_TOKEN}" # loaded from .env file
      SMTP_HOST: "mail.example.com"
      SMTP_FROM: "vault@example.com"
      SMTP_FROM_NAME: "Vaultwarden"
      SMTP_PORT: "587"
      SMTP_SECURITY: "starttls"
      SMTP_USERNAME: "${SMTP_USER}"
      SMTP_PASSWORD: "${SMTP_PASS}"
      PUSH_ENABLED: "true"            # Mobile push notifications
      LOG_LEVEL: "warn"
    volumes:
      - vaultwarden_data:/data
    ports:
      - "127.0.0.1:8080:80"           # Bind locally only, reverse proxy in front

volumes:
  vaultwarden_data:

The ADMIN_TOKEN should be a long, random string. Generate one with:

openssl rand -base64 48

Store it in a .env file alongside docker-compose.yml. The .env file must not be committed to any Git repository.

Reverse Proxy: nginx or OPNsense HAProxy

Vaultwarden must be accessible via HTTPS — Bitwarden clients reject unencrypted connections. You have two common options:

Option A: nginx with Let’s Encrypt

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;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    # WebSocket support for live sync
    location /notifications/hub {
        proxy_pass         http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection "upgrade";
    }

    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;
    }
}

Option B: OPNsense HAProxy

If you use OPNsense as your firewall, the built-in HAProxy can act as the SSL terminator. Create a backend (vaultwarden_backend, server 127.0.0.1:8080) and a frontend listener on port 443. The SSL certificate is managed via the ACME plugin directly in OPNsense and renews automatically. Enable WebSocket support in the frontend configuration (disable http-server-close, enable forwardfor).

Admin Panel and User Management

After starting, the admin panel is available at https://vault.example.com/admin, protected by the ADMIN_TOKEN. From here you configure:

• Invitations: Since SIGNUPS_ALLOWED: false is set, invite users manually by email
• Organizations: Teams can share password collections without exposing individual vault items
• 2FA enforcement: Under organization settings, you can require 2FA as a prerequisite for accessing shared collections

The recommended onboarding sequence:

1. Create the admin account and familiarize yourself with the admin panel
2. Create an organization and structure collections (e.g., by department or system)
3. Invite team members by email
4. Enable 2FA enforcement in the organization settings
5. Set SIGNUPS_ALLOWED permanently to false

Browser Extensions and Mobile Apps

Vaultwarden is fully compatible with the official Bitwarden clients. Users simply install the Bitwarden extension (Chrome, Firefox, Safari, Edge) or the mobile app (iOS, Android) and set the server URL to their own instance:

Server URL: https://vault.example.com

From that point, the complete Bitwarden experience works — auto-fill, password generator, secure notes, TOTP management — all against your own server. On company-managed devices, the server URL can be pre-configured via MDM, so employees only need to enter their credentials.

Backup Strategy: SQLite and Attachments

One of Vaultwarden’s greatest strengths is the simplicity of backups. The entire data directory consists of:

• data/db.sqlite3 — all passwords, users, organizations (encrypted at rest)
• data/attachments/ — file attachments
• data/sends/ — Bitwarden Send objects
• data/config.json — instance configuration

A straightforward backup script:

#!/bin/bash
BACKUP_DIR="/opt/backups/vaultwarden"
DATE=$(date +%Y-%m-%d_%H-%M)
mkdir -p "$BACKUP_DIR"

# SQLite online backup (consistent snapshot without downtime)
sqlite3 /opt/vaultwarden/data/db.sqlite3 \
  "VACUUM INTO '$BACKUP_DIR/db_$DATE.sqlite3'"

# Back up attachments
tar -czf "$BACKUP_DIR/attachments_$DATE.tar.gz" \
  -C /opt/vaultwarden/data attachments/ sends/

# Remove backups older than 30 days
find "$BACKUP_DIR" -mtime +30 -delete

Schedule this script as a cron job (e.g., hourly) and copy the backups to external storage as well — Proxmox Backup Server, S3-compatible object storage, or a separate NAS.

2FA Enforcement for the Entire Team

Vaultwarden supports all common 2FA methods: TOTP (Google Authenticator, Aegis), email OTP, WebAuthn/FIDO2, and Duo. For teams, TOTP or WebAuthn is recommended — both work without external dependencies.

The 2FA requirement is set at the organization level. Users who have not configured a second factor are automatically prompted to set one up when accessing organization collections. This behavior is enabled in the admin panel under Organization Policies.

Monitoring with DATAZONE Control

A self-hosted password manager is critical infrastructure — outages or certificate errors should be caught immediately. DATAZONE Control monitors the Vaultwarden container for health, uptime, and resource consumption. SSL certificate expiry, failed container restarts, and unusual memory usage are reported as automatic alerts. Combined with daily backup monitoring of the SQLite snapshot, administrators have full visibility into the operational status of their password manager.

Best Practices for Teams

• Compartmentalize collections: Use separate organization collections per project or client — this allows you to revoke access precisely when employees leave
• Separate service accounts: Technical credentials (server passwords, API keys) belong in dedicated collections, not in personal vaults
• Regular audits: The admin panel shows inactive users and unused collections — review and clean these up quarterly
• Fail2Ban: Configure Fail2Ban to block repeated failed login attempts against the Vaultwarden endpoint
• Updates: Vaultwarden releases regular security updates — automate docker pull and restarts using Watchtower or a scheduled cron job

---

Ready to run Vaultwarden in your organization’s infrastructure? Our team supports you with setup, hardening, and ongoing operations: Linux infrastructure and get in touch.