Vaultwarden: Installation mit Docker Compose

Aus maxTechCorner

Auf einen Blick

Gilt fürVaultwarden 1.37.x als Docker-Container (Image vaultwarden/server bzw. ghcr.io/dani-garcia/vaultwarden) auf Linux, z. B. Debian 13 oder Ubuntu 24.04 mit Docker Engine und Compose-Plugin
BereichIT-Security
Dauerca. 45–60 Minuten
RechteRoot bzw. Mitglied der Gruppe docker
StandOktober 2026

Vaultwarden mit Docker Compose installieren ist der übliche Weg, einen eigenen Bitwarden-kompatiblen Passwortserver aufzusetzen: ein Container, ein Datenordner, eine Konfigurationsdatei. Diese Anleitung richtet Vaultwarden so ein, dass es nur lokal lauscht und ein Reverse Proxy die HTTPS-Verbindungen übernimmt. Sie zeigt, wie das Admin-Panel mit einem gehashten Token geschützt wird, wie Benutzer ohne offene Registrierung eingeladen werden und wie E-Mail-Versand, Push-Benachrichtigungen und Updates funktionieren.

Installation von Vaultwarden mit Docker Compose: Verzeichnis /opt/vaultwarden mit compose.yaml, .env und Datenordner data; Container lauscht nur auf 127.0.0.1:8000, der Reverse Proxy übernimmt HTTPS; Admin-Token als Argon2-Hash mit vaultwarden hash erzeugen; SIGNUPS_ALLOWED=false, Benutzer über das Admin-Panel einladen; SMTP für Einladungen und 2FA-Mails; Push für mobile Apps über bitwarden.com/host (EU-Region); Update mit docker compose pull und up -d.

Voraussetzungen

  • Linux-Server oder VM mit Docker Engine und dem Compose-Plugin, siehe Docker. Für bis zu einigen Hundert Benutzern reichen 1–2 vCPU und 1–2 GB RAM.
  • Ein DNS-Name wie vault.firma.de und ein Reverse Proxy mit gültigem Zertifikat, siehe Vaultwarden: HTTPS mit Reverse Proxy (Caddy, nginx, OPNsense). Ohne HTTPS funktionieren Web-Tresor und Apps nicht, weil Browser die Web-Crypto-Funktionen nur in sicheren Verbindungen bereitstellen.
  • Ein SMTP-Konto für den Versand von Einladungen, Bestätigungen und Zwei-Faktor-Codes, siehe SMTP.
  • Ausgehender Internetzugang des Servers für Website-Icons und optional Push.

Datenbank wählen

Das Image enthält Treiber für SQLite, MySQL/MariaDB und PostgreSQL. Das Projekt empfiehlt SQLite für die meisten Installationen: Es ist am besten getestet, braucht keinen eigenen Datenbankserver und liegt als Datei im Datenordner. PostgreSQL oder MariaDB lohnen sich, wenn ohnehin ein betreuter Datenbankcluster existiert oder Vaultwarden hochverfügbar betrieben werden soll. Die Datenbank wird über DATABASE_URL gewählt.

Schritt 1: Verzeichnis und Admin-Token

sudo mkdir -p /opt/vaultwarden/data && cd /opt/vaultwarden
# Argon2-Hash für das Admin-Token erzeugen (fragt zweimal nach dem Passwort)
docker run --rm -it vaultwarden/server:latest /vaultwarden hash
  • Das Passwort für das Admin-Panel lang und zufällig wählen, z. B. mit openssl rand -base64 32, und im Passworttresor der IT ablegen.
  • Die Ausgabe ist ein PHC-String der Form $argon2id$v=19$m=65540,t=3,p=4$…. Vaultwarden speichert damit nur den Hash, nicht das Passwort. Mit --preset owasp nutzt der Befehl die schwächeren OWASP-Mindestwerte; die Standardwerte von Bitwarden sind vorzuziehen.

Schritt 2: Vaultwarden mit Docker Compose konfigurieren

.env (Rechte chmod 600, gehört nicht in ein Git-Repository):

VW_DOMAIN=https://vault.firma.de
# Einfache Anführungszeichen verhindern, dass Compose die $-Zeichen auswertet
VW_ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$…'
VW_SMTP_PASSWORD='…'

compose.yaml:

services:
  vaultwarden:
    image: vaultwarden/server:1.37.4
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: ${VW_DOMAIN}
      ADMIN_TOKEN: ${VW_ADMIN_TOKEN}
      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "true"
      SHOW_PASSWORD_HINT: "false"
      PASSWORD_HINTS_ALLOWED: "false"
      ORG_EVENTS_ENABLED: "true"
      EVENTS_DAYS_RETAIN: "365"
      SMTP_HOST: smtp.firma.de
      SMTP_FROM: vaultwarden@firma.de
      SMTP_FROM_NAME: Passwortmanager
      SMTP_SECURITY: starttls
      SMTP_PORT: "587"
      SMTP_USERNAME: vaultwarden@firma.de
      SMTP_PASSWORD: ${VW_SMTP_PASSWORD}
      LOG_FILE: /data/vaultwarden.log
      TZ: Europe/Berlin
    volumes:
      - ./data:/data
    ports:
      - 127.0.0.1:8000:80
  • DOMAIN muss die vollständige HTTPS-Adresse enthalten. Vaultwarden erzeugt daraus Links in E-Mails, die Anhang-URLs und die SSO-Rücksprungadresse.
  • Port nur an 127.0.0.1 binden, wenn der Reverse Proxy auf demselben Host läuft. Läuft er auf einem anderen System, die Freigabe per Host-Firewall auf dessen Adresse beschränken.
  • Version festschreiben (1.37.4 statt latest), damit Updates bewusst und nach Lesen der Release Notes erfolgen. Das Tag testing ist für den Produktivbetrieb nicht gedacht.
  • Wer das ADMIN_TOKEN direkt in die compose.yaml schreibt statt in die .env, muss jedes $ als $$ schreiben.
  • Ereignisprotokolle sind standardmäßig aus und werden ohne EVENTS_DAYS_RETAIN unbegrenzt aufbewahrt. Die Frist vorher mit Datenschutz und Betriebsrat abstimmen, siehe Vaultwarden: Datenschutz und Betrieb im Unternehmen.

Starten und Log prüfen:

docker compose up -d && docker compose logs -f

Schritt 3: Admin-Panel und erstes Konto

  1. Den Reverse Proxy einrichten und https://vault.firma.de/admin aufrufen, mit dem Passwort aus Schritt 1 anmelden.
  2. Unter Diagnostics prüfen: Version, Domäne, Uhrzeit, DNS- und Internetzugang, HTTPS-Erkennung. Abweichungen dort zuerst beheben.
  3. Unter General Settings › SMTP Email Settings mit Send test email den Versand testen.
  4. Unter Users die eigene Adresse mit Invite User einladen und das Konto über den Link in der E-Mail anlegen. Ohne E-Mail-Versand ruft der Eingeladene https://vault.firma.de/#/signup auf und registriert sich mit der eingeladenen Adresse.
  5. Ein starkes Master-Passwort wählen und den Wiederherstellungscode für die Zwei-Faktor-Anmeldung offline ablegen. Das Master-Passwort kann niemand zurücksetzen – auch der Administrator nicht.

Wichtig: Werden Einstellungen im Admin-Panel gespeichert, schreibt Vaultwarden sie in data/config.json. Diese Werte haben Vorrang vor den Umgebungsvariablen. Spätere Änderungen in der compose.yaml wirken dann nicht mehr für diese Einstellungen. Am besten eine Quelle festlegen – entweder Admin-Panel oder Umgebungsvariablen.

Schritt 4: Push-Benachrichtigungen für mobile Apps

Browser-Erweiterung und Desktop-App synchronisieren sich per WebSocket automatisch. Die Android- und iOS-App brauchen dafür das Push-Relay von Bitwarden:

  1. Auf https://bitwarden.com/host/ mit einer Firmenadresse eine Installation ID und einen Key anfordern; als Datenregion EU wählen.
  2. In der compose.yaml ergänzen:
      PUSH_ENABLED: "true"
      PUSH_INSTALLATION_ID: ${VW_PUSH_ID}
      PUSH_INSTALLATION_KEY: ${VW_PUSH_KEY}
      PUSH_RELAY_URI: https://api.bitwarden.eu
      PUSH_IDENTITY_URI: https://identity.bitwarden.eu
  1. Container neu erstellen (docker compose up -d) und in den Apps einmal ab- und wieder anmelden.
  • Push funktioniert nur mit Apps aus App Store und Google Play, nicht mit der F-Droid-Version.
  • Über das Relay laufen Gerätekennungen, aber keine Tresorinhalte. Datenschutzrechtlich bewerten, siehe Vaultwarden: Datenschutz und Betrieb im Unternehmen. Ohne Push synchronisieren die Apps beim Öffnen und manuell.

Updates

cd /opt/vaultwarden
# Vorher sichern, siehe Backup-Artikel
docker exec vaultwarden /vaultwarden backup
# Tag in compose.yaml auf die neue Version setzen, dann:
docker compose pull && docker compose up -d && docker compose logs --tail 50
  • Release Notes auf GitHub lesen: Sie enthalten Sicherheitsfixes und Hinweise zu geänderten Einstellungen. Bei 1.37.4 betraf das z. B. die Auswertung von X-Forwarded-For.
  • Die Bitwarden-Apps aktualisieren sich selbst. Neue App-Versionen brauchen oft eine aktuelle Vaultwarden-Version – Vaultwarden deshalb nicht monatelang auf altem Stand lassen.
  • Automatische Updates mit Watchtower sind möglich, für einen Passwortserver aber nur mit Backup davor und Überwachung danach sinnvoll.

Hinweise

  • Ohne Docker: Vaultwarden gibt es auch als Paket einiger Distributionen oder als selbst gebautes Programm mit systemd-Dienst. Die Docker-Variante ist am besten dokumentiert.
  • Fehlersuche: Bei Anmeldeproblemen in den Apps liegt die Ursache meist am Zertifikat (fehlende Zwischenzertifikate) oder an einer falschen DOMAIN.
  • Bei Aufbau und Betrieb von Linux-Servern und Containern unterstützt Sie das Linux-Consulting von m.a.x. it.

Siehe auch

Links und Quellen


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen