Vaultwarden 2026 selbst hosten: Domains, SMTP und sichere Backups
Ein praxisnaher Leitfaden zum Self-Hosting von Vaultwarden mit Docker, Ports, persistenten Daten, TLS, Sicherheit, Backups und den Fehlern, die den Produktiveinsatz verhindern.
Es gibt zwei Varianten, „Vaultwarden zu betreiben“: Ein Container existiert, oder der Service erfüllt tatsächlich seine Aufgabe. Nur die zweite zählt. Der Nachweis besteht hier darin, sich über eine Browser-Erweiterung anzumelden, ein Element zu erstellen, einen zweiten Client zu synchronisieren, einen Anhang hochzuladen und nach einem Neustart ein Send abzurufen.
Vaultwarden erfüllt diesen Zweck als kompakter, zu Bitwarden kompatibler Passwortserver. Das Deployment muss die Komponenten erhalten, die dieses Verhalten ermöglichen. Ein Port, ein Volume und ein Zertifikat sind Voraussetzungen, nicht das Ergebnis.
Volumes sind nur die erste Recovery-Ebene
Zum dauerhaften Recovery-Set gehören die Datenbank, Anhänge, Sends, Schlüssel und die Konfiguration in /data. Binde /data vor dem Bootstrap ein, schreibe harmlose Testdaten und ersetze den Container, um zu prüfen, ob dieser Pfad tatsächlich persistent ist. Ein Volume schützt Daten vor dem Ersetzen des Containers, aber nicht vor dem Verlust des Hosts, versehentlichem Löschen oder einer Beschädigung auf Anwendungsebene.
Erstelle Backups, die die Datenquelle berücksichtigen: Verwende bei laufenden Datenbanken bei Bedarf logische Dumps und kopiere Dateien nur aus einem konsistenten Zustand. Bewahre eine verschlüsselte Kopie getrennt vom Vaultwarden-Host auf. Das Abnahmekriterium für ein Restore ist eindeutig: Vault-Elemente, Anhänge, Sends und die Organisationsmitgliedschaft werden nach dem Restore korrekt mit einem sauberen Client synchronisiert. Der Leitfaden zu getesteten Restores von Backups erklärt, warum ein erfolgreicher Job allein nicht ausreicht.
Vaultwarden starten, ohne die beweglichen Teile zu verbergen
Starte Vaultwarden so, dass der Zugriffspfad privat bleibt, bis das Bootstrap abgeschlossen ist.
docker run -d \
--name vaultwarden \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v vaultwarden-data:/data \
-e ADMIN_TOKEN=replace-with-a-long-random-value \
vaultwarden/server:latest
Wenn der Prozess in einer Schleife läuft, vergleiche den vom Image erwarteten User mit dem Besitzer jedes eingebundenen Pfads. Wenn der Prozess aktiv bleibt, teste Port 80 lokal und gehe dann direkt zum Workflow über: Melde dich über eine Browser-Erweiterung an, erstelle ein Element, synchronisiere einen zweiten Client, lade einen Anhang hoch und rufe nach einem Neustart ein Send ab. Pinne die Image-Version erst, nachdem dieser End-to-End-Check erfolgreich war, und dokumentiere die exakte Konfiguration neben dem Service.
Die Laufzeitgrenzen von Vaultwarden festlegen
Definiere für Vaultwarden drei Grenzen: den Ingress zu Port 80, den dauerhaften Zustand und die unterstützenden Anforderungen. Der Container ist austauschbar, aber die beiden anderen Bereiche brauchen klar benannte Verantwortliche. Die externe Voraussetzung für Vaultwarden ist funktionierendes SMTP, wenn Einladungen und E-Mails für den Notfallzugriff erforderlich sind. Teste ausgehendes DNS, TLS und das Verhalten des Providers, ohne einen weiteren eingehenden Service zu veröffentlichen.
Das Diagramm ist vollständig, wenn sich ein sauberer Client über eine Browser-Erweiterung anmelden, ein Element erstellen, einen zweiten Client synchronisieren, einen Anhang hochladen und nach einem Neustart ein Send abrufen kann. Erfasse Timing- und Ressourcendaten für das Anhangsvolumen, SQLite-Schreibkonflikte oder Limits des Database-Pools sowie die SMTP-Latenz bei Einladungen. Wenn die Transaktion fehlschlägt, zeigt die erste Grenze, die sich nicht wie dokumentiert verhält, ob Routing, lokale Kapazität oder ein unterstützender Service untersucht werden muss.
Interne und externe URLs korrekt auseinanderhalten
Vermeide temporäre und dauerhafte öffentliche Origins für Vaultwarden. Setze stattdessen DOMAIN auf die exakte externe HTTPS-Origin, richte den gewählten DNS-Namen auf die Platform-Route und leite ausschließlich an Port 80 weiter.
Führe diesen Vorgang außerhalb des Hosts aus: Melde dich über eine Browser-Erweiterung an, erstelle ein Element, synchronisiere einen zweiten Client, lade einen Anhang hoch und rufe nach einem Neustart ein Send ab. Wenn der Ingress fehlschlägt, behandelt der Leitfaden zur 502-Fehlerbehebung Fehler bei Ports und Listenern. Wenn Vaultwarden die Anfrage empfängt, DOMAIN jedoch auf HTTP gesetzt ist, während der Browser für Vault-Funktionen eine sichere Origin verlangt, deutet die Evidenz nun auf eine Ursache jenseits des Proxys hin.
Ein Production-Acceptance-Run für Vaultwarden
Ein Production-Gate für Vaultwarden sollte von jemandem ausführbar sein, der das Deployment nicht erstellt hat. Gib dieser Person die gepinnte Version, ein nicht sensibles Testkonto und diese Aufgabe: über eine Browser-Erweiterung anmelden, ein Element erstellen, einen zweiten Client synchronisieren, einen Anhang hochladen und nach einem Neustart ein Send abrufen. Wenn die Anleitung undokumentierten Shell-Zugriff erfordert, ist der Service noch nicht operativ bereit.
Wiederhole das Gate, nachdem du ausschließlich den Container ersetzt hast. Stelle anschließend die Datenbank, Anhänge, Sends, Schlüssel und die Konfiguration in /data in einer leeren Infrastruktur wieder her und weise nach, dass Vault-Elemente, Anhänge, Sends und die Organisationsmitgliedschaft nach dem Restore korrekt mit einem sauberen Client synchronisiert werden. Miss während beider erfolgreichen Durchläufe das Anhangsvolumen, SQLite-Schreibkonflikte oder Limits des Database-Pools sowie die SMTP-Latenz bei Einladungen. Unerwartete Unterschiede weisen häufig auf einen fehlenden Cache, Index, Worker oder Daten-Mount hin.
Füge einen Failure-Drill hinzu: Verweigere vorübergehend den vom funktionierenden SMTP verwendeten Testpfad, wenn Einladungen und E-Mails für den Notfallzugriff erforderlich sind. Vaultwarden sollte einen hilfreichen Fehler ausgeben, den bestehenden Zustand bewahren und sich erholen, sobald die gültige Bedingung wieder erfüllt ist. Speichere die Zeitstempel und relevanten Logzeilen, wobei Secrets zu schwärzen sind. Diese Evidenz dient als Referenz für das nächste Image oder die nächste Konfigurationsänderung.
Den Workload überwachen, nicht nur den Container
Ein grüner Container ist notwendig, aber nicht ausreichend. Der Service-Level-Indikator ist der erfolgreiche Abschluss von „über eine Browser-Erweiterung anmelden, ein Element erstellen, einen zweiten Client synchronisieren, einen Anhang hochladen und nach einem Neustart ein Send abrufen“. Wahrscheinliche Belastungssignale sind dabei das Anhangsvolumen, SQLite-Schreibkonflikte oder Limits des Database-Pools sowie die SMTP-Latenz bei Einladungen.
Change Control ist wichtig, weil Vaultwarden-Datenbankmigrationen und die Kompatibilität mit Bitwarden-Clients gemeinsam geprüft werden müssen. Die Rotation von ADMIN_TOKEN ist eine Änderung des Administratorzugriffs, keine Migration von Vault-Daten. Bewahre das alte Image auf, teste Migrationen mit kopiertem Zustand und dokumentiere, ob ein Rollback nach der Schemaänderung unterstützt wird. Wenn DOMAIN auf HTTP gesetzt ist, während der Browser für Vault-Funktionen eine sichere Origin verlangt, untersuche die erste Grenze, die von der funktionierenden Umgebung abweicht.
Temporären Setup-Zugriff schließen
Ein sicheres Vaultwarden-Deployment beginnt damit, Berechtigungen zu entfernen. Verwende kein schwaches Admin-Token und lasse Registrierungen nicht geöffnet. Deaktiviere stattdessen offene Registrierungen, sobald die Anmeldung neuer Benutzer abgeschlossen ist, schütze die Admin-Seite mit einem starken Token und verlange HTTPS für jeden Vault-Client.
Ersetze das Beispiel für ADMIN_TOKEN sofort, speichere es außerhalb des Images und rotiere es wie ein Administrator-Credential, falls es offengelegt wurde. Beschränke administrative Routen, verwende private DNS-Einträge für Dependencies und überprüfe jeden Bind-Mount. Wenn Logs zentral ausgeliefert werden, filtere Secrets und private Inhalte, bevor sie den Server verlassen.
Dockup für die Platform-Ebene verwenden
Dockup beseitigt manuelle Arbeiten an Reverse-Proxy und Lifecycle rund um Vaultwarden. Der Service erhält während Ersetzungen eine stabile HTTPS-Route zu Port 80, injizierte Konfiguration und persistenten Storage. Ein angebundener Kundenserver folgt demselben Modell wie von Dockup gehostete Compute-Ressourcen.
Erfülle nach dem Launch den Application Contract: Setze DOMAIN auf die exakte externe HTTPS-Origin, erlaube und verifiziere funktionierendes SMTP, wenn Einladungen und E-Mails für den Notfallzugriff erforderlich sind, und führe diesen Nachweis aus: Melde dich über eine Browser-Erweiterung an, erstelle ein Element, synchronisiere einen zweiten Client, lade einen Anhang hoch und rufe nach einem Neustart ein Send ab. So bleibt die One-Click-Erfahrung nützlich, ohne die Details zu vereinfachen, die Vaultwarden wiederherstellbar und sicher machen.
Häufig gestellte Fragen
Was benötigt Vaultwarden für ein Production-Deployment?
Leite den Vaultwarden-Container über eine HTTPS-Origin an Port 80 weiter. Die externe Voraussetzung für die Zustellung ist funktionierendes SMTP, wenn Einladungen und E-Mails für den Notfallzugriff erforderlich sind. Erkläre Vaultwarden erst dann für bereit, wenn du dich über eine Browser-Erweiterung anmelden, ein Element erstellen, einen zweiten Client synchronisieren, einen Anhang hochladen und nach einem Neustart ein Send abrufen kannst.
Welche Vaultwarden-Daten gehören in ein Backup?
Mache /data persistent und nimm die Datenbank, Anhänge, Sends, Schlüssel und die Konfiguration in /data gemeinsam in dasselbe Recovery-Manifest auf. Ein sauberes Vaultwarden-Restore ist erst dann erfolgreich, wenn Vault-Elemente, Anhänge, Sends und die Organisationsmitgliedschaft nach dem Restore korrekt mit einem sauberen Client synchronisiert werden.
Benötigt Vaultwarden HTTPS hinter einem Reverse-Proxy?
Verwende HTTPS für die öffentliche Vaultwarden-Origin und halte Port 80 auf der internen Route. Setze die Vaultwarden-Einstellung korrekt: Setze DOMAIN auf die exakte externe HTTPS-Origin. Bei Vaultwarden schützt HTTPS Credentials oder Benutzerinhalte während der Übertragung und sorgt für ein konsistentes Client-Verhalten bei Origin-sensitiven Funktionen.
Wie sollte ein Vaultwarden-Upgrade getestet werden?
Stelle den aktuellen Vaultwarden-Zustand in einem isolierten Deployment wieder her, wende die geplante Version an und wiederhole die Abnahmetransaktion. Achte besonders darauf, dass Vaultwarden-Datenbankmigrationen und die Kompatibilität mit Bitwarden-Clients gemeinsam geprüft werden müssen. Die Rotation von ADMIN_TOKEN ist eine Änderung des Administratorzugriffs, keine Migration von Vault-Daten. Bewahre das vorherige Vaultwarden-Image auf, bis die Grenzen der Datenmigration und eines Rollbacks verstanden sind.