Vaultwarden auf einem Managed VPS hosten: Ihre Passwörter auf Ihrem Server

Was Vaultwarden kann

Vaultwarden ist ein in Rust geschriebener Passwortmanager-Server, gemacht für das Selbsthosting. Sein Wiki richtet ihn an Privatpersonen, Familien und Organisationen von überschaubarer Größe. Der Web-Tresor ist in seinen Docker-Images enthalten.

Es setzt eine API um, die mit den offiziellen Bitwarden-Clients im Browser, auf dem Computer und auf dem Telefon kompatibel ist. Das README stellt klar, dass das Projekt weder mit Bitwarden noch mit Bitwarden, Inc. verbunden ist, und bittet darum, jedes Problem, gleich mit welchem Client, direkt dort zu melden statt bei den offiziellen Supportkanälen.

• Der Tresor: persönlicher Tresor, Anhänge, Website-Symbole, persönlicher API-Schlüssel und Send, um einen Text oder eine Datei weiterzugeben.
• Die Organisationen: Sammlungen, Passwort-Freigabe, Rollen, Gruppen, Ereignisprotokolle und Richtlinien.
• Die Zwei-Faktor-Authentifizierung: Authenticator-App, E-Mail, FIDO2 WebAuthn, YubiKey und Duo.
• Die Notfallwege: Notfallzugriff und Kontowiederherstellung, wobei Letztere eine eingerichtete E-Mail voraussetzt.
• Die Verwaltung: eine Seite /admin für Einstellungen, Konten und Diagnose.

Das Wiki listet auch auf, was gegenüber dem offiziellen Server fehlt, etwa die Anmeldung mit Passkey, benutzerdefinierte Rollen und manche Unternehmensrichtlinien. Es stellt klar, dass Funktionen, die vor allem großen Organisationen nützen, für das Projekt keine Priorität haben: Lesen Sie diese Liste, wenn Sie darauf angewiesen sind.

Was die AGPL-3.0 erlaubt

Vaultwarden wird unter der GNU Affero General Public License, Version 3, veröffentlicht. Der Text gewährt eine uneingeschränkte Erlaubnis, das unveränderte Programm auszuführen. Sie können also das vom Projekt veröffentlichte Image für Ihr Unternehmen und Ihr Team nutzen, ohne eine Lizenz zu kaufen.

Artikel 13 fügt eine Bedingung hinzu, die der AGPL eigen ist: Wenn Sie das Programm ändern, muss Ihre Version allen, die sie aus der Ferne über das Netzwerk nutzen, die Möglichkeit bieten, ihren Quellcode kostenlos zu erhalten.

Die Installation mit Docker Compose

Das README empfiehlt die Container-Images. Legen Sie auf einem Server, auf dem Docker installiert ist, einen Ordner an und speichern Sie darin diese compose.yaml, entnommen aus dem README und dem Wiki:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8000:80

docker compose up -d

• Ein auf 127.0.0.1 veröffentlichter Port: Wie im README ist Vaultwarden nur über den Reverse Proxy erreichbar, der auf demselben Server läuft.
• DOMAIN: die Basisadresse Ihrer Instanz, mit https. Das Wiki warnt, dass ohne sie Funktionen kaputtgehen, darunter die Anhänge und die Einladungslinks.
• Ein Ordner vw-data auf einer lokalen Festplatte: Er enthält alle Daten. Das Wiki weist auf die Probleme von SQLite auf einem CIFS- oder Samba-Volume hin, das keine Dateisperren unterstützt.
• Das Tag latest folgt der zuletzt veröffentlichten Version, und das Wiki empfiehlt es für die meisten Einsätze. Ein Tag wie 1.37.5 legt eine Version fest, und latest-alpine liefert dasselbe auf einer Alpine-Basis.

Ihr Domainname zeigt mit A- und AAAA-Einträgen auf den Server, und die Besucher kommen über die Ports 80 und 443. Solange der Reverse Proxy nicht steht, bleibt der Web-Tresor unbenutzbar: Gehen Sie direkt zum nächsten Abschnitt.

Das Projekt nennt weder Arbeitsspeicher noch Prozessor; es versteht sich nur als Lösung für die Fälle, in denen der ressourcenhungrige offizielle Dienst nicht passt. Die Größe hängt von der Zahl der Konten und vom Umfang der Anhänge ab. Auf einem Managed VPS beschreiben Sie uns Ihren Einsatz, und wir empfehlen Ihnen die passende Größe.

HTTPS und WebSocket: der Reverse Proxy

Der Web-Tresor stützt sich auf die Web-Crypto-API, die Browser sicheren Kontexten vorbehalten: Das README gibt an, dass er nur mit aktiviertem HTTPS funktioniert, und das Wiki hält HTTPS für „pretty much required“, also so gut wie zwingend. Das Projekt empfiehlt einen Reverse Proxy vor Vaultwarden und rät vom TLS ab, das in sein Framework Rocket integriert ist.

Nehmen Sie ein anerkanntes Zertifikat, etwa von Let’s Encrypt, das auch das Wiki empfiehlt: Mit einem selbstsignierten Zertifikat verweigern manche Plattformen die Verbindung. Das Zertifikat muss seine vollständige Kette enthalten, sonst verbinden sich Android-Geräte nicht.

Die WebSocket-Benachrichtigungen, standardmäßig aktiv, melden dem Browser, der Desktop-App und der Erweiterung, dass sich ein Eintrag geändert hat. Sie laufen über den Haupt-HTTP-Port, und der Proxy muss die Header Upgrade und Connection weitergeben. Die mobilen Apps nutzen die nativen Benachrichtigungen ihres Systems, die separat eingerichtet werden.

Mit Caddy

Das Wiki rät, wenn Sie keine Präferenz haben, zuerst Caddy anzusehen: Es aktiviert HTTPS selbstständig, bezieht das Zertifikat von Let’s Encrypt und unterstützt WebSocket. Die Einstellung aus dem Wiki gibt außerdem die echte Adresse des Besuchers für die Protokolle an Vaultwarden weiter:

vault.example.com {
  reverse_proxy 127.0.0.1:8000 {
    header_up X-Real-IP {remote_host}
  }
}

Mit Nginx und Certbot

Dieser Block übernimmt das Nginx-Beispiel aus dem Wiki, auf Port 80 reduziert, damit Certbot HTTPS einrichten kann:

upstream vaultwarden-default {
  zone vaultwarden-default 64k;
  server 127.0.0.1:8000;
  keepalive 2;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      "";
}

server {
    listen 80;
    listen [::]:80;
    server_name vault.example.com;

    client_max_body_size 525M;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    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;

    location / {
      proxy_pass http://vaultwarden-default;
    }
}

Certbot richtet anschließend das Zertifikat ein und kümmert sich um die Erneuerung:

sudo certbot --nginx

WebSocket prüfen

Öffnen Sie die Entwicklerwerkzeuge des Browsers, Reiter Netzwerk, Filter WS, und melden Sie sich dann erneut am Tresor an: Eine Antwort 101 auf /notifications/hub bestätigt die Verbindung. Ein weiterer Test aus dem Wiki: Öffnen Sie den Tresor in zwei Browsern, benennen Sie in einem einen Eintrag um, und die Änderung erscheint sofort im anderen.

Die Registrierungen schließen

Standardmäßig kann jeder, der Ihre Instanz erreicht, dort ein Konto anlegen. Für Ihr erstes Konto ist das nützlich, und das Wiki empfiehlt, danach zu schließen, damit kein Angreifer eines anlegen kann.

1. Öffnen Sie Ihre HTTPS-Adresse, legen Sie Ihr Konto an und verbinden Sie dann Ihre Apps mit dieser Adresse.
2. Setzen Sie SIGNUPS_ALLOWED in der compose.yaml auf "false".
3. Starten Sie mit docker compose up -d neu: Eine Umgebungsvariable ist an den Container gebunden, der neu erstellt werden muss, damit sie gilt.

SIGNUPS_ALLOWED: "false"

• Die Einladungen bleiben offen, auch nach dem Schließen: Die Eigentümer und Administratoren einer Organisation können neue Personen einladen. INVITATIONS_ALLOWED auf "false" nimmt diese Möglichkeit weg, und das Wiki überlässt diese Entscheidung dem Vertrauen, das Sie Ihren Nutzern schenken.
• Eine Domainliste: SIGNUPS_DOMAINS_WHITELIST beschränkt die Registrierung auf bestimmte E-Mail-Domains, und SIGNUPS_VERIFY auf true verlangt dann die Prüfung der Adresse. Ist diese Liste gesetzt, wird SIGNUPS_ALLOWED ignoriert.
• Die Admin-Seite erlaubt es, jeden einzuladen, unabhängig von diesen Beschränkungen.

Sobald Sie die Konfiguration über die Admin-Seite speichern, entsteht im Datenordner eine Datei config.json, die Vorrang vor den Umgebungsvariablen hat. Die betroffenen Einstellungen ändern Sie dann über diese Seite: Die compose.yaml anzupassen genügt nicht mehr.

Die Admin-Seite und ihr Token

Die Seite /admin dient dazu, Vaultwarden zu konfigurieren, Konten und Organisationen einzusehen und zu löschen, die Zwei-Faktor-Authentifizierung eines Nutzers zu entfernen, einzuladen und die Diagnose zu lesen. Ohne ADMIN_TOKEN bleibt sie deaktiviert: Wenn Sie sie nicht brauchen, lassen Sie sie so.

Das Wiki empfiehlt dringend, vor dieser Seite HTTPS zu aktivieren. Das Token dient als Passwort und lässt sich als Hash mit argon2id aufbewahren statt im Klartext in der Konfiguration. Vaultwarden liefert dafür den Befehl: Er fragt das Passwort zweimal ab und gibt dann eine PHC-Zeichenkette zurück.

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

Legen Sie diese Zeichenkette in eine Datei .env neben der compose.yaml, in Hochkommas, und rufen Sie sie dann im Dienst auf:

VAULTWARDEN_ADMIN_TOKEN='$argon2id$...'

ADMIN_TOKEN: ${VAULTWARDEN_ADMIN_TOKEN}

Prüfen Sie das Ergebnis, starten Sie neu und melden Sie sich dann auf /admin mit Ihrem Passwort an, nicht mit der PHC-Zeichenkette:

docker compose config
docker compose up -d

• Die Sitzung dauert standardmäßig 20 Minuten, einstellbar mit ADMIN_SESSION_LIFETIME. Eine geöffnete Sitzung bleibt nach einem Token-Wechsel gültig. Um alle zu beenden, löschen Sie rsa_key.pem im Datenordner und starten neu; das meldet auch die Nutzer ab und macht laufende Einladungen ungültig.
• Ein eingeschränkter Zugang: Die Proxy-Beispiele des Wikis zeigen, wie Sie /admin nur für bestimmte Adressen öffnen oder eine HTTP-Authentifizierung davorsetzen.
• DISABLE_ADMIN_TOKEN entfernt jede Kontrolle: Es ist für eine separate Authentifizierungsschicht davor gedacht, und das Wiki reserviert es für alle, die wissen, was sie tun.

Was den Tresor schützt

Der erste Schutz ist das Master-Passwort. Die Daten des Tresors sind mit persönlichen oder Organisationsschlüsseln verschlüsselt: Wer eine Kopie der Datenbank erhält oder eine Sitzung erzwingt, muss dieses Passwort noch knacken, um sie zu lesen. Seine Stärke zählt also vor allem. Eine Admin-Sitzung selbst erlaubt, ein Konto zu löschen oder eine Zwei-Faktor-Authentifizierung zu entfernen, ohne Zugriff auf die Daten des Tresors zu geben.

Bereiten Sie sich auf das Vergessen des Master-Passworts vor, bevor es passiert: Aktivieren Sie den Notfallzugriff Ihres Kontos und, in einer Organisation, die Kontowiederherstellung, die eine eingerichtete E-Mail voraussetzt.

Drei weitere Einstellungen aus dem Härtungsleitfaden

• Ein Konto ohne Root-Rechte: Das Image läuft standardmäßig als root, und das Wiki hält es für besser, ihm die geringsten Rechte zu geben. Ergänzen Sie den Dienst um user: 1000:1000, mit einem Ordner vw-data, der diesem Benutzer gehört.
• Die Protokolle des Proxys: Die WebSocket-Verbindung übergibt ein Token in der Adresse, als access_token. Wenn Ihr Proxy seine Protokolle aufbewahrt oder an einen externen Dienst schickt, empfiehlt das Wiki, diesen Wert dort zu maskieren.
• So wenige Einbindungen wie möglich: Binden Sie den Datenordner ein und sonst nichts, weder Ihren persönlichen Ordner noch /var/run/docker.sock.

SQLite, MariaDB oder PostgreSQL

Dasselbe Image unterstützt alle drei Datenbanken. Das Wiki beschreibt SQLite als die am häufigsten genutzte und am besten getestete und empfiehlt sie für die meisten Einsätze, sofern Sie nicht gezielt eine andere brauchen.

DATABASE_URL: "postgresql://user_name:user_password@db_host:5432/vaultwarden"

Legen Sie eine leere Datenbank und ihren Benutzer an: Beim Start erzeugt Vaultwarden sein Schema selbst darin. Ein Passwort mit Sonderzeichen wird in dieser Adresse prozentkodiert geschrieben.

Treffen Sie diese Wahl, bevor Sie den Tresor füllen. Das Wiki beschreibt einen Wechsel von SQLite zu PostgreSQL mit pgloader und stellt klar, dass das Projekt diesen Weg nicht unterstützt, dass er auf Ihr eigenes Risiko geht und mit einem Backup beginnt.

Die E-Mails: die SMTP-Konfiguration

Vaultwarden startet ohne E-Mail, aber mehrere Funktionen hängen davon ab: die Einladungen, die Prüfung der Adressen, der Versand von Passwort-Hinweisen, die Zwei-Faktor-Authentifizierung per E-Mail und die Kontowiederherstellung.

Auf einem Simafri-VPS läuft der Versand über ein authentifiziertes SMTP-Relay auf Port 587: die Adresse eines Postfachs, das Sie bereits haben, oder Simafri Suite. Das Passwort kommt in die Datei .env, wie das Admin-Token:

SMTP_HOST: "smtp.example.com"
SMTP_FROM: "vault@example.com"
SMTP_PORT: "587"
SMTP_SECURITY: "starttls"
SMTP_USERNAME: "vault@example.com"
SMTP_PASSWORD: ${VAULTWARDEN_SMTP_PASSWORD}

• Die Einladungslinks werden aus DOMAIN gebildet und bleiben 5 Tage gültig.
• Microsoft: Das Wiki gibt an, dass Hotmail, Outlook und Office 365 inzwischen OAuth2 verlangen, das Vaultwarden noch nicht unterstützt. Der Fehler, an dem Sie das erkennen, lautet No compatible authentication mechanism was found.
• Gmail: Planen Sie laut Wiki ein App-Passwort ein.
• Der Test: Die Admin-Seite sendet eine Test-E-Mail. Wenn Sie dort eine SMTP-Einstellung ändern, speichern Sie zuerst, denn der Test nutzt die gespeicherten Einstellungen, und dieses Speichern erzeugt config.json.

Wenn nichts ankommt, schlägt das Wiki vor, die Verbindung zum Relay vom Server aus zu testen. Der Befehl gibt 0 zurück, wenn das Relay antwortet:

timeout 5 bash -c 'cat < /dev/null > /dev/tcp/smtp.example.com/587'; echo $?

Die Backups

Das README weist darauf hin, dass das Projekt für Datenverlust nicht haftbar gemacht werden kann, und empfiehlt dringend regelmäßige Backups. Das Wiki rät zu automatischen, mit mindestens einer Kopie an einem anderen Ort. Das enthält der Datenordner mit SQLite:

Die Datenbank, bei laufendem Dienst

Seit Version 1.32.1 kann Vaultwarden seine SQLite-Datenbank selbst sichern, ohne den Dienst anzuhalten:

docker exec -it vaultwarden /vaultwarden backup

Der Befehl schreibt eine Datei db_JJJJMMTT_HHMMSS.sqlite3 neben die Datenbank, in vw-data. Das Image enthält weder sqlite3 noch cron: Das Wiki rät, die Aufgabe auf dem Server zu planen, mindestens einmal täglich. Lassen Sie dabei -it weg, denn eine geplante Aufgabe hat kein Terminal, und räumen Sie diese Dateien auf, die sich ansammeln.

Der ganze Ordner, bei gestopptem Dienst

Wenn die Datenbank nicht in Gebrauch ist, genügt eine einfache Kopie aller ihrer Dateien. Das ist die Methode bei gestopptem Dienst, die das Wiki als Docker-Beispiel gibt, und sie nimmt auch die Anhänge mit:

docker compose down
tar -czf vaultwarden-$(date +%F).tar.gz vw-data
docker compose up -d

Das Wiki hält eine Verschlüsselungsschicht für nützlich, vor allem wenn das Backup das Admin-Token und die SMTP-Zugangsdaten enthält, und nennt rclone, restic und rustic, um die Kopien an einen entfernten Ort zu schicken. Mit MariaDB oder PostgreSQL ergänzen Sie den Ordner vw-data um einen Export der Datenbank.

Das Wiki bittet darum, sich nicht allein auf Festplatten-Snapshots zu verlassen, die schwieriger wiederherzustellen sind. Behalten Sie also diese anwendungseigenen Kopien: Auf der Festplatte des Servers abgelegt, fließen sie auch in dessen nächtliche Backups ein.

Wiederherstellen

1. Stoppen Sie Vaultwarden.
2. Ersetzen Sie jede Datei und jeden Ordner von vw-data durch die gesicherte Version.
3. Stammt die Datenbank aus /vaultwarden backup, benennen Sie sie db.sqlite3 und löschen Sie zuvor jede vorhandene Datei db.sqlite3-wal: Ein nicht passendes Journal kann die Datenbank beschädigen. Stammt sie aus einer direkten Kopie, stellen Sie db.sqlite3 und ihre db.sqlite3-wal gemeinsam wieder her.
4. Starten Sie neu und prüfen Sie, ob Sie den Tresor öffnen können.

Das Wiki rät, diese Übung von Zeit zu Zeit zu wiederholen und dabei eine Kopie der laufenden Daten zu behalten: So prüfen Sie, dass ein Backup funktioniert.

Die Updates

Das Wiki nennt zwei Befehle, auszuführen im Ordner der compose.yaml. Der Datenordner bleibt dabei erhalten:

docker compose pull
docker compose up -d

Diese Updates zählen mehr als anderswo. Die mobilen Apps und die Browser-Erweiterungen aktualisieren sich selbst, und das Wiki warnt, dass ein Versionsunterschied zum Server plötzliche Ausfälle verursachen kann. Der im Image mitgelieferte Web-Tresor bleibt dagegen immer auf seinen Server abgestimmt.

Das Projekt hat keinen Veröffentlichungskalender: Verfolgen Sie seine Release Notes und lösen Sie unmittelbar vor jedem Update ein Backup aus. Manche enthalten Sicherheitskorrekturen, wie die Version 1.37.5 vom 1. November 2026, deren Notizen ein möglichst rasches Update empfehlen. Diese Notizen warnen zudem, dass seit 1.37.5 ein ungültiger Konfigurationswert den Start von Vaultwarden verhindert: Lesen Sie Ihre Umgebungsdatei vor dem Update noch einmal durch. Die Diagnoseseite von /admin zeigt an, ob es eine neuere Version gibt.

Wer was tut auf einem Managed VPS

Beim Selbsthosting müssen Sie neben der Anwendung auch den Server betreuen. Auf einem Managed VPS übernehmen unsere Teams den Server und betreuen Ihre Instanz proaktiv; Vaultwarden bleibt Ihre Software, mit ihren Einstellungen und Daten.

Wenn unsere Teams lieber in der Anwendung selbst eingreifen sollen, wird diese Leistung nach Stunden oder pauschal abgerechnet, mit einem Kostenvoranschlag vor dem Eingriff.