Vaultwarden auf VPS selbst hosten mit Docker

Was Sie aufbauen

Ein Passwortmanager, den Sie vollständig selbst betreiben: Vaultwarden läuft in einem kleinen Container hinter einem Reverse Proxy, der HTTPS terminiert. Die offiziellen Bitwarden-Apps auf Ihrem Smartphone, Laptop und in Ihrem Browser greifen darauf zu. Vaultwarden implementiert die Bitwarden-Server-API in Rust neu und verwendet dasselbe Protokoll wie bitwarden.com. Daher funktionieren alle offiziellen Clients unverändert damit. Gleichzeitig benötigt Vaultwarden etwa 100 MB RAM statt des offiziellen Stacks mit mehreren Containern.

Die Installation selbst umfasst ein Dutzend Compose-Zeilen. Entscheidend sind drei Punkte, an denen die Einrichtung häufig scheitert: TLS muss eingerichtet sein, bevor Sie das Web-Vault zum ersten Mal laden. Öffentliche Registrierungen müssen geschlossen werden, sobald Ihr eigenes Konto existiert. Das Daten-Volume muss gesichert und testweise wiederhergestellt werden, weil dieses eine Verzeichnis alle Ihre Passwörter enthält.

Voraussetzungen und wichtige Einschränkungen

• Eine VPS mit Docker Engine und dem Compose-Plugin auf einer frisch installierten Ubuntu-24.04-KVM-Instanz mit root oder sudo. 512 MB RAM sind tatsächlich ausreichend; 1 GB bietet komfortable Reserven. Dies gehört zu den ressourcenschonendsten Diensten, die Sie betreiben können, und steht weit oben auf der Auswahlliste sinnvoller Dienste für Self-Hosting. Dimensionieren Sie die Instanz trotzdem für alle weiteren Dienste, die darauf laufen: Wenn Sie eine selbst gehostete Fotobibliothek wie PhotoPrism oder Immich auf derselben VPS betreiben, steigt der erforderliche Arbeitsspeicher auf mehrere Gigabyte, während Vaultwarden den Bedarf kaum erhöht. Dasselbe gilt für Medien-Frontends, die Sie später ergänzen, denn eine Jellyfin-Bibliothek wie eine begehbare Videothek aus den 90er-Jahren zu gestalten bedeutet einen weiteren dauerhaft laufenden Container sowie Reserven für Transcoding aus demselben Budget.
• Eine Domain mit einem A-Record (und einem AAAA-Record, falls Sie IPv6 verwenden), der vault.example.com auf die VPS verweist. Das TLS-Zertifikat wird für genau diesen Namen ausgestellt. Daher muss DNS vor dem Start korrekt aufgelöst werden.
• Die Ports 80 und 443 müssen aus dem Internet erreichbar sein und von Ihrem Reverse Proxy terminiert werden, niemals direkt von Vaultwarden. Port 80 wird ausschließlich für die ACME-Zertifikatsprüfung und die Weiterleitung von HTTP auf HTTPS verwendet.
• Der wichtigste Punkt vorab: Die Bitwarden-Clients verweigern die Verbindung zu einem Server ohne HTTPS. Es gibt keinen funktionierenden Weg, den Dienst zunächst über http zu testen. Der konkrete Grund wird im nächsten Abschnitt erklärt.

Warum Vaultwarden statt des offiziellen Bitwarden-Stacks

Gleiche Clients, deutlich geringerer Ressourcenbedarf. Bitwarden wird für das offizielle Self-Hosting als Bundle mehrerer Container ausgeliefert (MSSQL, Nginx, Identity, Api, Admin und weitere) und benötigt ungefähr 2 GB RAM. Vaultwarden ist eine einzelne Binärdatei und speichert standardmäßig alle Daten in einer SQLite-Datenbank. Im Leerlauf benötigt es nur einige Dutzend Megabyte. Für eine einzelne Person, eine Familie oder ein kleines Team ist es daher die naheliegende Wahl. Da Vaultwarden die Bitwarden API originalgetreu implementiert, bleiben Ihre Daten zwischen Vaultwarden und bitwarden.com portierbar.

Sie verzichten auf den größten Teil der Enterprise-Funktionen: Es gibt kein SCIM-Provisioning, auch wenn experimentelles OpenID Connect SSO in 1.35.0 hinzugekommen ist. Außerdem sind Sie selbst für den Betrieb verantwortlich. Patches, HTTPS und Backups müssen Sie selbst verwalten. Dieser Leitfaden behandelt genau diese drei Aufgaben.

Warum HTTPS nicht optional ist

Der Bitwarden-Webtresor und die Browser-Erweiterungen leiten Ihre Verschlüsselungsschlüssel im Browser mithilfe der Web Crypto API (window.crypto.subtle) ab. Browser stellen crypto.subtle nur in einem sicheren Kontext, über HTTPS oder im Sonderfall von http://localhost bereit. Über unverschlüsseltes http://vault.example.com ist dies undefined. Sobald die Anwendung einen Schlüssel ableitet, tritt daher eine Ausnahme auf. In der Konsole wird Folgendes angezeigt:

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'importKey')

Die Seite hängt oder zeigt einen allgemeinen Kryptografiefehler an. Eine Anmeldung ist nicht möglich. Die Desktop-, Mobil- und Browser-Clients prüfen die selbst gehostete URL ebenfalls eigenständig. Bei einem http- oder nicht erreichbaren Endpunkt verweigern sie die Verbindung mit:

This is not a recognized Bitwarden server. You may need to check with your provider or update your server.

Beide Fälle haben dieselbe Ursache: Es ist kein gültiges HTTPS vorhanden. Deshalb richten wir zuerst TLS ein und öffnen den Tresor niemals über http, auch nicht einmal kurz zur Kontrolle.

Schritt 1, DNS und der Reverse Proxy (zuerst TLS)

Verweisen Sie den Record auf Ihre VPS-Adresse und prüfen Sie, ob er zur richtigen Adresse aufgelöst wird:

dig +short vault.example.com

Die ausgegebene Zeile muss die IP-Adresse Ihrer VPS enthalten. Wenn sie leer oder falsch ist, korrigieren Sie DNS und warten Sie das TTL-Intervall ab. Die Zertifikatsausstellung schlägt fehl, wenn der Name nicht aufgelöst werden kann.

Für das HTTPS-Frontend verwendet diese Anleitung Traefik. Traefik stellt Let's Encrypt-Zertifikate automatisch aus und erneuert sie. Außerdem lässt es sich direkt in Compose integrieren. Wenn Traefik noch nicht läuft, befolgen Sie zuerst die Anleitung zum Traefik-Reverse-Proxy und zur automatischen TLS-Konfiguration. Dabei werden ein externes Docker-Netzwerk (proxy weiter unten) und ein ACME-Resolver (letsencrypt) erstellt, an den der Vaultwarden-Dienst angebunden wird. Reines nginx mit einem manuell ausgestellten Zertifikat funktioniert aus Sicht von Vaultwarden identisch.

Bevorzugen Sie nginx und Certbot statt Traefik? Binden Sie Vaultwarden an 127.0.0.1:8080 an (fügen Sie ports: ["127.0.0.1:8080:80"] zum Dienst hinzu und entfernen Sie die Traefik-Labels). Stellen Sie anschließend ein Zertifikat aus und richten Sie den Proxy auf Vaultwarden. Der Zertifikatsteil wird in Let's Encrypt-Zertifikate mit Certbot und nginx ausstellen beschrieben. Wichtig ist zusätzlich das WebSocket-Upgrade für den Benachrichtigungspfad:

server {
    listen 443 ssl;
    server_name vault.example.com;

    client_max_body_size 525M;

    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;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Beachten Sie die Zeile X-Real-IP. Sie sorgt dafür, dass Fail2ban später die echte Angreiferadresse statt 127.0.0.1 erkennt. Alles andere in dieser Anleitung ist identisch, unabhängig davon, ob Traefik oder nginx vorgeschaltet ist.

Schritt 2: Die Compose-Datei

Erstellen Sie zuerst das Projektverzeichnis. Diese Anleitung verwendet /opt/vaultwarden. Dadurch bleiben der Compose-Projektname und damit das Daten-Volume vaultwarden_vw-data vorhersehbar. Die folgenden Schritte für Fail2ban und Backups hängen von diesem exakten Namen ab.

sudo mkdir -p /opt/vaultwarden
cd /opt/vaultwarden

Erstellen Sie in diesem Verzeichnis eine .env für das Administrationsgeheimnis und die Compose-Datei.

# .env
ADMIN_TOKEN=paste-a-strong-token-here

Generieren Sie dieses Token mit openssl rand -base64 48 und fügen Sie es ein. Eine stärker gehashte Form wird im nächsten Abschnitt behandelt. Für den Anfang genügt eine lange zufällige Zeichenfolge.

# docker-compose.yml
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"          # closed in Step 4, keep true just to register
      ADMIN_TOKEN: "${ADMIN_TOKEN}"
      IP_HEADER: "X-Forwarded-For"     # X-Real-IP if your proxy sends that instead
      LOG_FILE: "/data/vaultwarden.log"
      LOG_LEVEL: "warn"
    volumes:
      - vw-data:/data
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.vw.rule=Host(`vault.example.com`)"
      - "traefik.http.routers.vw.entrypoints=websecure"
      - "traefik.http.routers.vw.tls.certresolver=letsencrypt"
      - "traefik.http.services.vw.loadbalancer.server.port=80"

volumes:
  vw-data:

networks:
  proxy:
    external: true

Zwei Aspekte dieser Datei tragen das gesamte Konzept. Es gibt kein ports:-Mapping. Vaultwarden ist daher nur über Traefik und dessen TLS erreichbar. Wenn Sie den Port auf dem Host veröffentlichen, kann der Tresor versehentlich über HTTP bereitgestellt werden. Außerdem muss DOMAIN die vollständige öffentliche HTTPS-URL sein. Dieser Wert wird in Anhang-Links, WebAuthn-2FA und den Benachrichtigungsendpunkt übernommen. Ein falscher Wert oder eine HTTP-URL führt daher dazu, dass diese Funktionen nicht funktionieren, obwohl die Website geladen wird. Das Tag latest ist eine bewusste Ausnahme von der üblichen Regel, niemals latest zu verwenden. Vaultwarden veröffentlicht seine stabilen Versionen als ein fortlaufend aktualisiertes Image. :testing ist der separate Kanal für Vorabversionen. Aktualisieren Sie daher bewusst und überfliegen Sie die Release-Hinweise, bevor Sie das Image abrufen. Diese Ausnahme ist jedoch begrenzt: Die meisten langlebigen Container sollten besser auf ein exaktes Tag festgelegt werden. Dadurch bleibt ein dauerhaft aktiver, selbst gehosteter Agent auf demselben VPS auch bei Reboots und dem Abrufen von Images vorhersehbar.

Starten Sie den Stack und überwachen Sie das Log:

docker compose up -d
docker compose logs -f vaultwarden

Ein korrekter Start endet mit einer Zeile wie Rocket has launched from http://0.0.0.0:80. Warten Sie einige Sekunden, damit Traefik das Zertifikat abrufen kann. Laden Sie anschließend https://vault.example.com. Sie sollten den Bitwarden-Webtresor mit einem gültigen Schlosssymbol und ohne Zertifikatswarnung sehen.

Schritt 3: ein starkes ADMIN_TOKEN und die $$-Falle

ADMIN_TOKEN schützt /admin, das Panel, das jeden Benutzer und jede Einstellung Ihrer Instanz lesen kann. Behandeln Sie es daher wie ein root-Passwort. Zwei Formen funktionieren.

Die einfache Form ist die Zufallszeichenfolge, die Sie bereits mit openssl rand -base64 48 erzeugt haben. Da Base64 niemals ein $ enthält, kann die Zeichenfolge ohne Escaping direkt in .env übernommen werden.

Die gehärtete Form ist ein Argon2-PHC-Hash. Dadurch wird das Token im Klartext nie auf der Festplatte gespeichert. Erzeugen Sie ihn mit demselben Image:

docker run --rm -it vaultwarden/server /vaultwarden hash --preset owasp

Der Befehl fordert Sie zweimal zur Eingabe auf und gibt eine Zeichenfolge aus, die mit $argon2id$v=19$... beginnt. Hier liegt die Falle, die viele eine Stunde kostet: Docker Compose behandelt $ als Variableninterpolation. Deshalb müssen Sie beim Einfügen des Hashes in die Compose-Datei jedes $ zu $$ verdoppeln. Setzen Sie den Hash direkt unter environment:, nicht über .env, und schließen Sie ihn nicht in Anführungszeichen ein:

    environment:
      ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$c29tZXNhbHQ$$RdescudvJCsgt3ub+b+dWRWJTmaaJObG

Wenn Sie die einzelnen $-Zeichen unverändert lassen, gibt Compose The "argon2id" variable is not set aus und setzt das Token auf einen leeren Wert. Anschließend weist /admin Ihr korrektes Passwort zurück. Führen Sie docker compose up -d aus und bewahren Sie den an der Eingabeaufforderung eingegebenen Klartext in Ihrem eigenen Passwort-Manager auf.

Schritt 4: Registrieren Sie Ihr Konto und schließen Sie anschließend die Tür

Öffnen Sie mit SIGNUPS_ALLOWED: "true" die Seite https://vault.example.com, klicken Sie auf Create account und registrieren Sie sich mit Ihrer E-Mail-Adresse und einem starken Master-Passwort. Dieses Master-Passwort kann nicht wiederhergestellt werden. Es gibt keine Möglichkeit zum Zurücksetzen. Speichern Sie es daher vorher an einem dauerhaften Ort.

Schließen Sie jetzt die Tür. Bearbeiten Sie die Compose-Datei, um Registrierungen zu deaktivieren:

      SIGNUPS_ALLOWED: "false"

Wenden Sie die Änderung mit docker compose up -d erneut an. Diese Absicherung sollten Sie nicht aufschieben. Wenn die Registrierung offen bleibt, kann jeder, der die URL findet, ein Konto auf Ihrem Server erstellen. Das gilt auch für Crawler. Sie können Ihren Tresor nicht lesen, verbrauchen aber Ressourcen und machen Ihre private Instanz zu einem offenen Dienst. Daran erkennen Sie, dass die Einstellung noch aktiv ist: /admin listet Konten auf, die Sie nicht erstellt haben.

Um später Familienmitglieder oder Teammitglieder hinzuzufügen, ohne öffentliche Registrierungen wieder zu aktivieren, verwenden Sie die Schaltfläche Invite User in /admin. Dafür muss SMTP konfiguriert sein, damit die eingeladene Person ihren Link erhält.

Schritt 5: /admin aufrufen

Rufen Sie https://vault.example.com/admin auf und geben Sie das unverschlüsselte Admin-Token ein (die zufällige Zeichenfolge oder das Passwort, dessen Hash Sie erstellt haben, nicht den Hash selbst). Im Panel können Sie Benutzer auflisten, Einstellungen anpassen, eine Test-E-Mail senden und einen Datenbank-Snapshot erstellen.

Wenn die Seite 404 Not Found zurückgibt, ist ADMIN_TOKEN leer oder nicht gesetzt. Dadurch wird das Panel vollständig deaktiviert. Das ist eine gültige Wahl, wenn Sie es nie benötigen. Wird das Panel geladen, weist Ihr Token aber zurück, beachten Sie den $$-Escaping-Fehler in der folgenden Fehlerliste. Token vergessen? Es gibt keine Wiederherstellungsabfrage. Bearbeiten Sie .env oder die Compose-Datei, setzen Sie ein neues Token und docker compose up -d.

Schritt 6: Bitwarden-Clients verbinden

Jeder offizielle Client kann eine Verbindung zu einem selbst gehosteten Server herstellen. Installieren Sie den Bitwarden-Desktop-, Mobil- oder Browser-Client aus den regulären Stores. Sie benötigen keinen speziellen Vaultwarden-Build.

Öffnen Sie vor der Anmeldung das Einstellungszahnrad auf dem Anmeldebildschirm (mit Self-hosted oder Region → Self-hosted beschriftet), setzen Sie Server URL auf https://vault.example.com und speichern Sie die Einstellung. Melden Sie sich anschließend mit der registrierten E-Mail-Adresse und dem Master-Passwort an. Der Client sollte sofort eine Verbindung herstellen und anbieten, Zugangsdaten auszufüllen und zu speichern.

Wenn ein Client This is not a recognized Bitwarden server. You may need to check with your provider or update your server. anzeigt, ist die URL falsch, verwendet http oder das Zertifikat wird nicht als vertrauenswürdig eingestuft. Prüfen Sie erneut, ob https://vault.example.com zuerst in einem Browser problemlos geladen wird. Verzögerte Aktualisierungen auf anderen Geräten werden durch WebSocket-Push verursacht und weiter unten behandelt.

Schritt 7: Ein Fail2ban-Jail für den Login-Endpunkt

Vaultwarden protokolliert jeden fehlgeschlagenen Login in die durch LOG_FILE festgelegte Datei. Genau diese Information benötigt ein Schutzmechanismus gegen Brute-Force-Angriffe. Wenn Fail2ban noch nicht läuft, finden Sie die Installation und die Grundlagen im Leitfaden zur Absicherung von SSH mit Fail2ban. Hier fügen wir ein Jail für den Vault hinzu.

Ermitteln Sie zunächst, wo das benannte Volume auf dem Host liegt, damit Fail2ban das Log lesen kann:

docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}'

Der Befehl gibt etwa /var/lib/docker/volumes/vaultwarden_vw-data/_data aus. Das Log liegt darin unter vaultwarden.log. Erstellen Sie den Filter:

# /etc/fail2ban/filter.d/vaultwarden.conf
[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Und das Jail:

# /etc/fail2ban/jail.d/vaultwarden.local
[vaultwarden]
enabled   = true
filter    = vaultwarden
logpath   = /var/lib/docker/volumes/vaultwarden_vw-data/_data/vaultwarden.log
banaction = iptables-allports
chain     = DOCKER-USER
maxretry  = 5
findtime  = 600
bantime   = 3600

Laden Sie die Konfiguration mit sudo systemctl restart fail2ban neu und prüfen Sie sie mit sudo fail2ban-client status vaultwarden.

Drei Docker-Details entscheiden darüber, ob dieser Schutz wirksam ist. Wenn das Log bei jedem fehlgeschlagenen Versuch IP: 127.0.0.1 oder die Adresse Ihres Proxy anzeigt, sperrt Vaultwarden den Proxy. Setzen Sie IP_HEADER auf den Header, den Ihr Proxy tatsächlich sendet: X-Forwarded-For für Traefik, X-Real-IP für den oben gezeigten nginx-Block und CF-Connecting-IP hinter Cloudflare. Zweitens hängt die richtige iptables-Kette von Ihrem Proxy ab. Wenn Traefik als Container mit veröffentlichten Ports läuft, durchläuft der Datenverkehr den Docker-Pfad FORWARD. Die Sperre muss daher wie oben in DOCKER-USER platziert werden. Wenn Sie dagegen die host-nginx-Option aus Schritt 1 gewählt haben, werden die Verbindungen von nginx in der Kette INPUT des Hosts beendet. Eine Sperre in DOCKER-USER erfasst sie dann nicht. Löschen Sie in diesem Fall die Zeile chain = DOCKER-USER, damit Fail2ban die Standardkette INPUT verwendet. Verwenden Sie drittens banaction = iptables-allports anstelle der portbasierten Standardeinstellung. Dieses Jail definiert keinen Port. Eine Sperre für alle Ports in DOCKER-USER blockiert den Angreifer zuverlässig für jeden auf dem Host veröffentlichten Dienst.

Schritt 8: Sichern Sie den Tresor und stellen Sie ihn anschließend tatsächlich wieder her

Das Volume vw-data ist Ihr Passwortmanager. Es enthält db.sqlite3 (jeden Eintrag), die Verzeichnisse attachments/ und sends/, die rsa_key.*-Dateien zum Signieren von Anmeldesitzungen sowie config.json aus dem Admin-Panel. Wenn eine Sicherung einen dieser Bestandteile auslässt, schlägt sie im Ernstfall fehl.

Wenn Sie db.sqlite3 kopieren, während Vaultwarden Schreibvorgänge ausführt, kann die Kopie eine unvollständig geschriebene und beschädigte Datei enthalten. Erstellen Sie daher einen Cold-Snapshot. Die Ausfallzeit beträgt nur wenige Sekunden:

#!/usr/bin/env bash
set -euo pipefail
STAMP=$(date +%F)
DEST=/root/vw-backups
VOL=$(docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}')
mkdir -p "$DEST"
docker compose -f /opt/vaultwarden/docker-compose.yml stop vaultwarden
tar czf "$DEST/vw-$STAMP.tgz" -C "$VOL" .
docker compose -f /opt/vaultwarden/docker-compose.yml start vaultwarden

Führen Sie dies jede Nacht über cron aus und kopieren Sie .tgz vom Server weg. Eine Sicherung, die nur auf dem Server liegt, den Sie schützen, ist keine Sicherung. Der saubere Weg dafür ist eine nächtliche restic-Sicherung auf einen anderen Server oder in einen Objektspeicher. Dabei wird das Archiv verschlüsselt und wiederholte Snapshots werden automatisch dedupliziert. Die Schaltfläche Backup Database im Admin-Panel erstellt einen praktischen Snapshot ausschließlich der SQLite-Datei. Anhänge und Schlüssel sind darin jedoch nicht enthalten.

Jetzt folgt der Schritt, der eine echte Sicherung von einer bloßen Hoffnung unterscheidet: Stellen Sie sie einmal wieder her und prüfen Sie, ob sie funktioniert:

mkdir -p /tmp/vw-restore
tar xzf /root/vw-backups/vw-2026-07-15.tgz -C /tmp/vw-restore
docker run --rm -p 127.0.0.1:8888:80 -v /tmp/vw-restore:/data vaultwarden/server

Bauen Sie von Ihrem Laptop aus mit ssh -L 8888:127.0.0.1:8888 you@your-vps einen Tunnel dorthin auf und öffnen Sie http://localhost:8888. Da localhost ein sicherer Kontext ist, ist crypto.subtle verfügbar und der Tresor hier über unverschlüsseltes http entschlüsselt wird, ist dies der eine zulässige Ort dafür. Melden Sie sich mit Ihrem Masterpasswort an und prüfen Sie, ob Ihre Einträge vorhanden sind. Wenn das der Fall ist, funktionieren Ihre Datenbank, die RSA-Schlüssel und das Masterpasswort vollständig bei der Sicherung und Wiederherstellung. Sie können den Dienst auf einem neuen VPS innerhalb weniger Minuten wieder aufbauen. Beenden Sie den Container mit Ctrl-C und löschen Sie /tmp/vw-restore. Verwenden Sie diese Tunnel-Methode auch für alle anderen Admin-UIs auf dem Server, die niemals aus dem Internet erreichbar sein sollten. Auf diese Weise erreichen Sie beispielsweise auch einen selbst gehosteten Open-Kritt-Sicherheitsscanner auf Port 5173.

Fehlerbilder und die angezeigten Meldungen

Cannot read properties of undefined (reading 'importKey') in der Browserkonsole. Der Tresor wurde über http geladen. Daher ist crypto.subtle nicht definiert. Rufen Sie ihn nur über https:// auf und richten Sie am Proxy eine Weiterleitung von HTTP auf HTTPS ein.

This is not a recognized Bitwarden server... in einem Client. Die Server-URL verwendet http, enthält einen Tippfehler oder das Zertifikat wird nicht als vertrauenswürdig eingestuft. Prüfen Sie, ob https://vault.example.com ein gültiges Schlosssymbol anzeigt. Geben Sie die URL anschließend in den Self-Hosted-Einstellungen des Clients erneut ein.

/admin weist das korrekte Passwort zurück. Der Argon2-Hash wurde beim Escaping verändert. Jedes $ muss in Compose als $$ geschrieben werden. Alternativ haben Sie den Hash statt des zugehörigen Klartextwerts eingegeben.

Langsame Synchronisierung zwischen Geräten; die Konsole zeigt WebSocket connection to 'wss://vault.example.com/notifications/hub' failed. Der Proxy leitet die Header Upgrade und Connection nicht weiter. Traefik erledigt das automatisch. Bei nginx benötigen Sie die beiden Upgrade-Zeilen aus Schritt 1. Der Tresor funktioniert weiterhin, synchronisiert aber erst beim Öffnen. Der alte dedizierte Port 3012 wird seit v1.31.0 nicht mehr verwendet. Daher ist keine separate WebSocket-Route erforderlich.

Fail2ban meldet eine Sperre, aber der Angreifer verbindet sich weiterhin. Die Sperre betrifft 127.0.0.1, weil IP_HEADER falsch ist, oder sie befindet sich in der falschen iptables-Kette. Setzen Sie chain = DOCKER-USER und banaction = iptables-allports.

Upgrades

Laden Sie das neue Image herunter und erstellen Sie den Container neu. Das benannte Volume und alle Ihre Daten bleiben erhalten:

docker compose pull
docker compose up -d

Vaultwarden veröffentlicht häufig neue Versionen. Beobachten Sie die Release Notes des Projekts, statt eine Patch-Version festzulegen, da einige Releases Hinweise zu Migrationen enthalten. Erstellen Sie vor jedem größeren Versionssprung ein aktuelles Backup. Sie können ein Rollback durchführen, indem Sie das Tarball in ein neues Volume zurückspielen.

FAQ

Ist Vaultwarden dasselbe wie Bitwarden?

Es handelt sich um einen kompatiblen, unabhängigen Server, nicht um den offiziellen Server. Vaultwarden implementiert die Bitwarden-Server-API in Rust neu. Daher funktionieren die offiziellen Desktop-, Mobil-, Browser- und CLI-Clients damit, wobei nur ein Bruchteil der Ressourcen des offiziellen Stacks benötigt wird. Das Tresorformat ist identisch. Sie können daher in beide Richtungen migrieren, indem Sie exportieren und importieren.

Brauche ich wirklich HTTPS, oder kann ich es über http in meinem LAN betreiben?

Sie benötigen für alles außer einem localhost-Test HTTPS. Der Bitwarden-Webtresor und die Erweiterungen verwenden die Web Crypto API des Browsers. Diese ist nur in einem sicheren Kontext verfügbar. Über einfaches http gibt der Client daher Cannot read properties of undefined aus und meldet sich nie an. Die einzige funktionierende http-Adresse ist http://localhost. Deshalb verwendet der Wiederherstellungstest in Schritt 8 einen SSH-Tunnel.

Wie verhindere ich, dass sich Fremde auf meinem Server registrieren?

Setzen Sie SIGNUPS_ALLOWED: "false" in der Compose-Datei und führen Sie docker compose up -d unmittelbar nach dem Erstellen Ihres eigenen Kontos aus. Fügen Sie neue Personen anschließend über die Schaltfläche Invite User in /admin hinzu. Dafür muss SMTP konfiguriert sein, damit sie den Einladungslink erhalten. Prüfen Sie die Liste der Administratorkonten gelegentlich, um unerwartete Konten zu erkennen.

Wie sichere ich meinen Vaultwarden-Tresor?

Stoppen Sie den Container kurz und archivieren Sie das gesamte vw-data-Volume, db.sqlite3, attachments/, sends/, config.json sowie die rsa_key.*-Dateien. Kopieren Sie das Archiv anschließend vom Server, idealerweise jede Nacht über einen Cronjob. Wenn Sie die aktive SQLite-Datei kopieren, während der Server läuft, kann der Snapshot beschädigt sein. Erstellen Sie die Sicherung daher bei angehaltenem Dienst. Stellen Sie sie vor allem einmal in einem Wegwerf-Container wieder her und melden Sie sich an. So wissen Sie, dass die Sicherung tatsächlich funktioniert, bevor Sie sich darauf verlassen.

Ist es wirklich sicher, meine Passwörter selbst zu hosten?

Ja, wenn Sie die drei Punkte aus dieser Anleitung umsetzen: echtes HTTPS, geschlossene Registrierungen mit einem starken Administratortoken und getestete Sicherungen. Ihr Tresor wird clientseitig mit Ihrem Master-Passwort verschlüsselt. Selbst der Server sieht Ihre Passwörter daher nie im Klartext. Ein gestohlenes db.sqlite3 ist ohne dieses Passwort nutzlos. Der Nachteil besteht darin, dass Sie nun für Patches und Sicherungen verantwortlich sind. Deshalb sind Fail2ban und das Wiederherstellungsverfahren hier nicht optional. Sobald diese Maßnahmen umgesetzt sind, ist eine genauere Betrachtung der tatsächlichen Angriffsmöglichkeiten eines selbst gehosteten Tresors der nächste sinnvolle Schritt. Da die Einträge selbst im Client verschlüsselt werden, müssen Sie vor allem das Administratortoken und das Sicherungsarchiv schützen.