Passwortmanager selbst hosten: 3 Optionen

Ein Passwortmanager ist der eine Dienst, bei dem „Das Backup mache ich später“ in Wahrheit heißt: „Später sperre ich mich selbst aus allem aus.“ Bevor du dich für Software entscheidest, klär deshalb erst, ob du überhaupt einen Server betreiben willst.

Kurz gesagt

Du hast drei Wege, die du selbst in der Hand hast. KeePassXC legt deine Passwörter in einer verschlüsselten Datei auf deinen eigenen Geräten ab und braucht keinen Server [16][17]. Vaultwarden ist ein inoffizieller, schlanker Server, mit dem die offiziellen Bitwarden-Apps sprechen können [1]. Der offizielle Bitwarden-Server kommt vom Hersteller, ist aber ein größeres Paket, und manche Funktionen brauchen eine bezahlte Lizenz [9][12]. Dazu kommt ein vierter Weg, und der ist oft der beste: nicht selbst hosten, sondern einen gehosteten Dienst nutzen. Unsere Einschätzung: Wenn du dir kein getestetes Backup und zügige Updates zutraust, bist du mit einem gehosteten Dienst oder einer lokalen KeePassXC-Datei sicherer unterwegs. Selbst hosten ändert nichts an der Verschlüsselung. Es ändert, wer den Server pflegt, wer das Backup macht und wer nachts um zwei schuld ist.

So funktioniert’s

1. Was Selbsthosten ändert und was nicht. Bei allen drei Wegen wird der Tresor auf deinem Gerät verschlüsselt, bevor er irgendwo liegt. Bitwarden nennt Zero-Knowledge-Verschlüsselung als Kerneigenschaft [14]. Eine KeePassXC-Datenbank ist immer vollständig verschlüsselt, unverschlüsselte Daten landen nie auf der Platte [16]. Ein selbst betriebener, Bitwarden-kompatibler Server hält also Chiffretext und nicht deine Passwörter. Zu dir wandert alles drumherum: Betriebssystem, Container-Image, TLS-Zertifikat, Backup und jedes Update. Verschwinden Server und Backup, verschwindet der Zugang zu deinen Konten, es sei denn, du hast irgendwo eine weitere Kopie.
2. Vaultwarden ist inoffiziell. Das Projekt beschreibt sich als „Unofficial Bitwarden compatible server written in Rust“ und stellt klar, dass es nicht mit Bitwarden oder Bitwarden, Inc. verbunden ist. Ein aktiver Maintainer arbeitet bei Bitwarden und trägt in seiner Freizeit unabhängig vom Unternehmen bei [1]. Die README bittet darum, Probleme beim Vaultwarden-Projekt zu melden und nicht beim offiziellen Bitwarden-Support [1]. Bitwarden sagt dasselbe von seiner Seite: Der Hersteller kann nicht garantieren, dass die offiziellen Clients mit inoffiziellen Servern wie Vaultwarden einwandfrei laufen, und der Support kann eingeschränkt sein. Er rät, so einen Server möglichst aktuell zu halten [13]. Die Sicherheitsaudits, die Bitwarden aufführt, betreffen Bitwardens eigene Apps, den Web-Tresor und die Bibliotheken [15]. Eine Aussage, dass sie auch Vaultwarden abdecken, haben wir nicht gefunden. Unsere Einschätzung: Nimm diese Audits nicht als Gütesiegel für die Serversoftware, die du betreibst.
3. Updates gehören zum Deal. Vaultwarden 1.37.4 erschien am 5. Okt. 2026 als Sicherheitsrelease. Die Hinweise nennen sieben Advisories: eines mit Einstufung „High“ (8,1), fünf „Medium“ und eines „Low“. Sie betreffen Organisationsmitgliedschaft, Zwei-Faktor-Anmeldung, Einladungen, Anhänge, Ereignisprotokolle, das Teilen von Einträgen und den API-Schlüssel der Organisation. Laut Projekt waren sie noch nicht öffentlich, weil die CVE-Vergabe aussteht [6]. Du musst nicht jeden Punkt verstehen. Die Lehre: Korrekturen erscheinen regelmäßig, und ein Tresor-Server, den du nie aktualisierst, driftet in ein Risiko. Bitwarden betont das für den eigenen Server genauso: Updates können wichtige Sicherheitskorrekturen enthalten, und neuere Clients unterstützen ältere Server womöglich nicht mehr [11].
4. HTTPS ist Pflicht, und der Proxy kommt zuerst. Der Vaultwarden-Web-Tresor braucht HTTPS und einen sicheren Kontext für die Web-Crypto-API des Browsers, er läuft also nur mit aktiviertem HTTPS. Das Projekt empfiehlt einen Reverse Proxy [1]. Sein Härtungsleitfaden rät von der eingebauten TLS-Unterstützung des Rocket-Webframeworks ab, weil Rocket sie selbst als nicht produktionsreif bezeichnet [4]. Im Container lauscht Vaultwarden auf Port 80, und das README-Beispiel veröffentlicht ihn nur auf der Loopback-Adresse 127.0.0.1:8000, damit der Proxy der einzige Weg hinein ist [1]. Auch Bitwardens eigener Server will einheitliche Protokolle: HTTPS für den Betrieb, HTTP nur zum Testen, und kein Mischen zwischen Proxy und Server [9]. Proxys erklären wir im Guide „Reverse Proxy im Homelab“ (verlinkt unter „Passt dazu“).
5. Das Admin-Token ist ein Passwort, behandle es so. Die Vaultwarden-Adminseite ist optional. Es gibt sie nur, wenn du ADMIN_TOKEN setzt, und das Token ist das Anmeldepasswort der Seite. Das Wiki empfiehlt einen langen Zufallswert und rät, vorher HTTPS einzurichten. Es zeigt auch, wie du das Token als Argon2id-Hash ablegst: vaultwarden hash gibt einen PHC-String aus (ein Standardformat für Passwort-Hashes), und diesen String trägst du statt des Klartextpassworts in ADMIN_TOKEN ein [2]. Mit Docker Compose musst du jedes $ als $$ schreiben oder den Wert in einer .env-Datei in einfachen Anführungszeichen halten [2]. Admin-Sitzungen laufen standardmäßig 20 Minuten [2]. Brauchst du die Seite nicht, lass ADMIN_TOKEN ungesetzt, dann bleibt sie aus [2][5]. Der Härtungsleitfaden nennt zwei weitere Schalter: die offene Registrierung abschalten, sobald deine Konten angelegt sind (SIGNUPS_ALLOWED=false), und Passwort-Hinweise nicht auf der Anmeldeseite anzeigen [4][5].
6. Backups: was genau hineingehört. Vaultwarden hält seinen Zustand im Ordner data. Bei der Standarddatenbank SQLite markiert das Wiki die Datenbankdatei und den Ordner attachments als erforderlich, config.json und die rsa_key*-Dateien als empfohlen, sends und icon_cache als optional [3]. Kopiere die laufende Datenbankdatei nicht blind. Das Wiki empfiehlt den SQLite-Befehl .backup, und seit Version 1.32.1 gibt es den eingebauten Befehl /vaultwarden backup. Es rät außerdem zu mindestens einer Kopie an einem anderen Ort, zu einer zusätzlichen Verschlüsselung (die Konfigurationsdatei enthält Admin-Token und Mail-Zugangsdaten im Klartext) und dazu, sich nicht allein auf VM- oder Dateisystem-Snapshots zu verlassen [3]. Zurückspielen heißt: Vaultwarden stoppen, Dateien ersetzen und vorher eine alte db.sqlite3-wal löschen [3]. Das Wiki empfiehlt ausdrücklich, die Wiederherstellung zu üben. Das Werkzeug dafür erklärt unser restic-Guide (verlinkt unter „Passt dazu“).
7. Der offizielle selbst gehostete Server. Bitwardens Standard-Deployment für Linux verlangt Docker Engine 26 oder neuer sowie mindestens 2 GB RAM und 12 GB Speicher, empfohlen sind 4 GB und 25 GB. Es bringt eine Microsoft-SQL-Server-Express-Datenbank und ein Installationsskript mit, und eine Installations-ID samt Schlüssel holst du unter bitwarden.com/host [9]. Updates laufen als ./bitwarden.sh updateself und danach ./bitwarden.sh update, und Bitwarden empfiehlt, vorher ein Backup anzulegen [11]. Im Standard-Deployment sichert der Datenbank-Container nachts und hebt die Dateien 30 Tage auf, der Hersteller bittet dich aber trotzdem, das ganze Verzeichnis ./bwdata als Notfallvorsorge zu kopieren [10]. Dazu gibt es Bitwarden Lite: ein Container, mindestens 200 MB RAM und 1 GB Speicher, gedacht für Privatgebrauch und Homelabs, wahlweise mit SQLite, PostgreSQL, MySQL/MariaDB oder MSSQL. Lite sichert nicht nachts, Datenbankpflege und Backups liegen bei dir [8][10]. Auch Lite braucht Installations-ID und -Schlüssel [8]. Selbst hosten kostet nichts, aber manche Funktionen schaltest du nur mit einer Lizenzdatei frei, die du aus einem bezahlten Cloud-Abo herunterlädst [12]. Premium kostet 19,80 US-Dollar im Jahr bei jährlicher Zahlung, zuzüglich Steuern (Preisseite, 24. Okt. 2026) [14].
8. KeePassXC: kein Server, andere Arbeit. Die Datenbank ist eine .kdbx-Datei. KeePassXC nutzt die Formate KDBX 3.1 und KDBX 4 und empfiehlt KDBX 4 mit Argon2, am besten Argon2id, als Schlüsselableitung. Es schlägt eine Entschlüsselungszeit von etwa einer Sekunde vor und warnt, dass ein Handy zwei- bis viermal länger brauchen kann als dein Rechner [16][17]. Als zusätzlichen Schutz kannst du eine Schlüsseldatei oder einen YubiKey beziehungsweise OnlyKey hinzufügen. Halte die Schlüsseldatei vom synchronisierten Datenbankordner getrennt, und verliere weder sie noch das Master-Passwort: Beides bedeutet, dass die Datenbank weg ist [16][17]. KeePassXC hat keine eigene Synchronisation. Laut Anleitung legst du die Datei in einen Cloud-Speicher oder synchronisierst sie mit Werkzeugen wie Syncthing oder Nextcloud, und das Projekt empfiehlt einen Dienst mit Versionsverlauf [16][17]. Version 2.8.0 brachte die Synchronisation mit entfernten Datenbanken über externe Werkzeuge wie rsync oder scp, die Anleitung warnt aber, dass das kein atomarer Vorgang ist und spätere Änderungen auf der Gegenseite überschrieben werden können [16][18]. Eine offizielle Mobil-App gibt es nicht. Das Team empfiehlt KeePassDX und KeePass2Android für Android sowie Strongbox und KeePassium für iOS, die eigenständige Projekte sind [17]. Das Release 2.8.0 vom 21. Okt. 2026 behebt außerdem mehrere Schwachstellen, die alle 2.7.x-Versionen und älter betreffen. Das Team stuft sie als niedrig bis mittel ein, keine betrifft die Kernverschlüsselung [18]. Aktualisiere deshalb auch den Desktop-Client.
9. Der gehostete Weg. Bitwardens kostenloser Tarif wird als „Always free“ beworben, Premium steht mit 19,80 US-Dollar im Jahr auf der Preisseite [14]. Gehostet heißt nicht sorglos, aber die Audit-Liste zeigt, dass externe Firmen die Software des Herstellers regelmäßig prüfen [15].
10. Eine kurze Entscheidungstabelle. Unsere Einschätzung, keine Vorschrift:

Ein Homelab-Beispiel

Das ist eine Skizze für deinen eigenen Server, kein Bericht über unseren. Welchen Passwortmanager Bytearium einsetzt, sagen wir hier nicht. Domain und Pfade sind ausgedacht.

Angenommen, du hast Docker mit dem Compose-Plugin und einen Reverse Proxy, der vault.example.net schon per HTTPS ausliefert (siehe Proxy-Guide). Zuerst hashst du das Admin-Token. Der Befehl fragt zweimal nach dem Passwort und gibt einen PHC-String aus [2]:

mkdir -p /srv/vaultwarden && cd /srv/vaultwarden
docker run --rm -it vaultwarden/server:1.37.4 /vaultwarden hash

Lege den ausgegebenen String in /srv/vaultwarden/.env in einfachen Anführungszeichen ab und beschränke die Datei mit chmod 600 .env:

VAULTWARDEN_ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$...'

Erstelle /srv/vaultwarden/compose.yaml. Den Image-Tag 1.37.4 gibt es laut Docker Hub am 24. Okt. 2026 [7]. Pinne ihn und ändere ihn bewusst, wenn du aktualisierst:

services:
  vaultwarden:
    image: vaultwarden/server:1.37.4
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.net"
      ADMIN_TOKEN: ${VAULTWARDEN_ADMIN_TOKEN}
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8000:80

Prüfe das Ergebnis des Escapings mit docker compose config und starte mit docker compose up -d. Für den Proxy nimmst du eine der Beispielkonfigurationen, die das Projekt aufführt (Caddy, nginx und weitere), und richtest sie auf 127.0.0.1:8000 aus [1][4]. Öffne die Seite, lege dein Konto an, trage dann unter environment die Zeile SIGNUPS_ALLOWED: "false" ein und führe docker compose up -d erneut aus, damit der Container neu erstellt wird [2][4][5].

Das Backup läuft täglich per Cron auf dem Host (installiere dort das Paket sqlite3, denn das Image enthält keins [3]):

#!/bin/sh
set -eu
D=/srv/vaultwarden
mkdir -p "$D/backup"
sqlite3 "$D/vw-data/db.sqlite3" ".backup '$D/backup/db-$(date +%Y%m%d-%H%M).sqlite3'"
find "$D/backup" -name 'db-*.sqlite3' -mtime +14 -delete
restic -r /mnt/backup/restic-vault backup "$D/backup" "$D/vw-data" \
  --exclude "$D/vw-data/icon_cache" --exclude "$D/vw-data/db.sqlite3*"

Das restic-Repository muss schon existieren (restic init), und eine Kopie sollte das Haus verlassen. Wie das geht, erklären die Guides zu 3-2-1 und zu restic. Dann übst du: in ein leeres Verzeichnis zurückspielen, auf der wiederhergestellten Datenbank sqlite3 <Datei> "PRAGMA integrity_check;" laufen lassen und auf einem Ersatzrechner einen Wegwerf-Container hinter einem Testnamen mit HTTPS starten. Melde dich einmal an. Klappt das, hast du ein Backup. Probierst du es nie aus, hast du eine Hoffnung.

Als letzte Rückfallebene, unabhängig von jedem Server, exportierst du deinen Tresor hin und wieder. Bitwarden führt einen verschlüsselten Export unter seinen Funktionen auf [14], und KeePassXC hat ein Kapitel zum Import aus anderen Anwendungen [16]. Halte Exporte verschlüsselt und lösche unverschlüsselte.

Prüfliste

• Entscheide zuerst, ob du überhaupt einen Server betreiben willst, und schreib auf, wer den Tresor wiederherstellt, wenn du nicht erreichbar bist.
• Prüfe, dass der Web-Tresor nur über HTTPS erreichbar ist und der Container-Port hinter deinem Proxy auf 127.0.0.1 veröffentlicht wird.
• Pinne einen genauen Image-Tag wie vaultwarden/server:1.37.4, lies vor jeder Änderung die Release-Hinweise und aktualisiere nach Sicherheitsreleases zügig.
• Lass ADMIN_TOKEN ungesetzt, wenn du die Adminseite nicht brauchst. Nutzt du sie, lege einen mit vaultwarden hash erzeugten Argon2id-Hash ab.
• Schalte die offene Registrierung ab, sobald deine Konten existieren, und halte Passwort-Hinweise von der Anmeldeseite fern.
• Sichere die Datenbank mit .backup oder /vaultwarden backup, dazu attachments, config.json und die rsa_key*-Dateien. Verschlüssele die Kopie und bewahre eine außer Haus auf.
• Spiele alle drei Monate ein Backup auf einem anderen Rechner zurück und notiere Datum und Ergebnis.
• Bewahre eine KeePassXC-Schlüsseldatei oder ein YubiKey-Backup getrennt von der Datenbank auf und aktualisiere KeePassXC auf 2.8.0 oder neuer.
• Nimm den gehosteten Weg, wenn du die Schritte oben nicht in verlässlichem Rhythmus schaffst.