Vaultwarden selbst hosten: Dein Passwort-Manager im Proxmox-LXC
Du willst deine Passwörter auf deinem eigenen Server haben und trotzdem die gewohnten Bitwarden-Apps auf Handy, Browser und Rechner nutzen? In diesem Guide richtest du Vaultwarden in einem LXC auf Proxmox ein, machst es über einen Caddy-Reverse-Proxy per HTTPS erreichbar und setzt die Einstellungen und Backups, auf die es wirklich ankommt. Bei mir läuft genau dieses Setup seit über einem Jahr.
Warum solltest du einen Passwort-Manager selbst hosten?
Der wichtigste Grund: Du weißt, wo deine Daten liegen. Dazu kommt, dass Vaultwarden Features wie Organisationen, geteilte Sammlungen und TOTP-Codes ohne Abo mitbringt. Für Familie oder ein kleines Team ist das praktisch.
Self-Hosting hat hier aber auch Risiken, die du kennen solltest:
- Wenn dein Server ausfällt und du kein Backup hast, sind alle Passwörter weg. Die Apps halten zwar eine lokale, verschlüsselte Kopie, darauf solltest du dich aber nicht verlassen.
- Updates und Absicherung sind dein Job. Niemand patcht für dich.
- Wenn der Server aus dem Internet erreichbar ist, ist er ein Ziel. Die Daten im Tresor sind clientseitig mit deinem Master-Passwort verschlüsselt, ein schwaches Master-Passwort hilft dir dann aber wenig.
Was ist Vaultwarden?
Vaultwarden ist eine schlanke, in Rust geschriebene Server-Implementierung der Bitwarden-API. Es ist kein offizielles Bitwarden-Projekt, die offiziellen Bitwarden-Clients funktionieren aber damit: Browser-Extension, Desktop-App, iOS, Android und CLI. Du stellst in der App nur die Server-URL um. Als Datenbank reicht für den Heimgebrauch SQLite, deshalb braucht Vaultwarden kaum Ressourcen.
Das brauchst du
Du brauchst einen Proxmox-Host, einen Reverse Proxy mit gültigem Zertifikat und ein Ziel für Backups. Die Tabelle zeigt, wie das bei mir aussieht. Vaultwarden läuft bei mir auf dem Proxmox-Host am französischen Standort. Wie die beiden Standorte zusammenhängen, habe ich in Mein Homelab an zwei Standorten beschrieben.
| Baustein | Bei mir |
|---|---|
| Container | Unprivilegierter LXC, Debian 12, erstellt mit dem Community-Script |
| Installation | Natives Binary unter /opt/vaultwarden, als systemd-Service |
| Version | Vaultwarden 1.37.4 |
| Datenbank | SQLite in /opt/vaultwarden/data |
| Port | 8000 mit selbstsigniertem Zertifikat |
| Reverse Proxy | Caddy in einem eigenen LXC, holt Let’s-Encrypt-Zertifikate per DNS-Challenge |
| Backup | Wöchentlicher vzdump aller Gäste auf mein NAS |
Schritt 1: Leg den LXC mit dem Community-Script an
Am schnellsten installierst du Vaultwarden über die Proxmox VE Helper-Scripts der Community. Das Script legt einen Debian-LXC an, baut Vaultwarden und den Web-Vault ein und richtet einen systemd-Service ein. Du führst es auf der Proxmox-Shell des Hosts aus:
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/vaultwarden.sh)"Bevor du fremde Scripts als root ausführst, lohnt sich ein Blick in den Code auf GitHub. Fragt dich das Script nach dem Betriebssystem für den Container, wähl Debian, denn die Pfade in diesem Guide gelten für die Debian-Variante. Im Dialog legst du CPU, RAM, Disk und Netzwerk fest. Danach läuft der Service im Container, und du kannst ihn so prüfen:
systemctl status vaultwarden
/opt/vaultwarden/bin/vaultwarden --versionDie Konfiguration liegt in /opt/vaultwarden/.env, der systemd-Service liest sie per EnvironmentFile ein. Die Daten, also Datenbank, Anhänge, Icon-Cache und der RSA-Key, liegen in /opt/vaultwarden/data. Gib dem LXC per DHCP-Reservierung oder statisch eine feste IP, sonst zeigt dein Reverse Proxy irgendwann ins Leere.
Schritt 2: Richte HTTPS über Caddy ein
Die Bitwarden-Clients und der Web-Vault brauchen HTTPS, weil die Verschlüsselung im Browser über die Web Crypto API läuft und die nur in einem sicheren Kontext verfügbar ist. Das Community-Script richtet Vaultwarden mit einem selbstsignierten Zertifikat auf Port 8000 ein. Lass Caddy deshalb per HTTPS mit dem Container sprechen und das Zertifikat intern nicht prüfen. Nach außen liefert Caddy ein gültiges Let’s-Encrypt-Zertifikat aus.
(hsts) {
header Strict-Transport-Security "max-age=63072000"
}
(insecure_upstream) {
transport http {
tls_insecure_skip_verify
}
}
vault.example.de {
import hsts
reverse_proxy https://192.168.1.x:8000 {
import insecure_upstream
}
}tls_insecure_skip_verify ist vertretbar, solange die Strecke nur durch dein LAN geht. Websockets für Live-Sync musst du nicht extra konfigurieren: Seit Version 1.29 laufen die Notifications über denselben Port, und Caddy reicht Websocket-Verbindungen automatisch durch. Damit Vaultwarden die echte Client-IP sieht, trägst du in der .env außerdem IP_HEADER=X-Forwarded-For ein.
Wenn dein Vaultwarden öffentlich erreichbar ist, lohnt sich ein Filter für Scanner und Bruteforce-Versuche. Bei mir übernimmt das CrowdSec auf dem Proxy. Wie das aufgebaut ist, steht in CrowdSec mit Caddy.
Schritt 3: Setz die wichtigen Einstellungen
Den Admin-Bereich erreichst du unter https://vault.example.de/admin. Der Zugang läuft über den ADMIN_TOKEN. Speicher ihn als Argon2-Hash, damit er im Klartext nirgends auf der Platte liegt. Vaultwarden bringt dafür einen eigenen Befehl mit:
/opt/vaultwarden/bin/vaultwarden hashDen ausgegebenen String trägst du in der .env in einfachen Anführungszeichen ein, damit die $-Zeichen nicht als Variablen interpretiert werden:
ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$DEIN-HASH'
DOMAIN=https://vault.example.de
SIGNUPS_ALLOWED=falseAchtung, wichtiger Pitfall: Sobald du im Admin-Panel auf Speichern klickst, schreibt Vaultwarden eine config.json in den Data-Ordner. Werte darin haben Vorrang vor der .env. Wenn eine Änderung in der .env scheinbar ignoriert wird, liegt es fast immer daran. Entscheide dich am besten für einen Weg.
Diese Punkte gehst du im Admin-Panel durch:
- Domain URL auf die echte HTTPS-Adresse setzen. Links in Mails und einige Features wie WebAuthn hängen davon ab.
- Allow new signups abschalten, sobald dein eigener Account existiert. Weitere Leute lädst du danach per Einladung ein.
- SMTP einrichten. Ich nutze das Postfach meines Hosters mit STARTTLS auf Port 587. Ohne SMTP funktionieren Einladungen und Notfallzugriff nur eingeschränkt.
- Zwei-Faktor für den eigenen Account aktivieren, am besten per Authenticator-App oder Hardware-Key.
Schritt 4: Sichere deine Daten richtig
Das ist der wichtigste Teil. Die Basis ist ein Proxmox-Backup-Job, der den Vaultwarden-LXC regelmäßig sichert. Bei mir läuft er jeden Sonntag um 3 Uhr für alle Gäste am Standort, im Snapshot-Modus mit zstd-Kompression, schreibt auf mein NAS und behält die letzten vier Sicherungen. Vor Updates lege ich zusätzlich einen Proxmox-Snapshot an.
Für einen Passwort-Manager reicht das auf Dauer nicht. Wöchentlich bedeutet im schlimmsten Fall sieben Tage verlorene Einträge, und bei mir stehen NAS und Server im selben Haus. Meine Empfehlung, die ich selbst noch umsetzen will: Sichere zusätzlich täglich die SQLite-Datenbank konsistent und kopier sie verschlüsselt an einen zweiten Ort. Für die Datenbank geht das mit dem sqlite3-Paket so:
sqlite3 /opt/vaultwarden/data/db.sqlite3 ".backup '/root/vw-backup/db-$(date +%F).sqlite3'"Kopiere die Datei db.sqlite3 nicht einfach im laufenden Betrieb, weil im WAL-Modus noch Änderungen in db.sqlite3-wal stecken können. Neben der Datenbank gehören rsa_key.pem, der Ordner attachments (falls vorhanden) und die config.json ins Backup. Und mach regelmäßig einen Export aus dem Web-Vault als verschlüsselte JSON-Datei. Den kannst du im Notfall in jede Bitwarden-kompatible Instanz importieren.
Schritt 5: Verbinde Apps und Browser-Extension
Installiere die offizielle Bitwarden-App oder -Extension. Auf dem Login-Screen wählst du bei der Region bzw. dem Server „Self-hosted“ aus und trägst https://vault.example.de als Server-URL ein. Danach meldest du dich mit E-Mail und Master-Passwort an wie gewohnt. So prüfst du den Live-Sync: Änder im Web-Vault einen Eintrag. Taucht er kurz darauf in der Extension auf, funktionieren auch die Websockets.
Updates und typische Fehler
Das Community-Script legt im Container den Befehl update an. Der lädt das Script erneut und aktualisiert Vaultwarden und den Web-Vault. Mein Tipp: Leg vorher auf dem Host einen Snapshot an. So bin ich bei meinem letzten Update von 1.34.3 auf 1.37.4 vorgegangen:
pct snapshot 117 pre-vw-update
pct exec 117 -- update- config.json schlägt .env: Siehe oben.
- Admin-Token ohne Anführungszeichen: Der Argon2-Hash enthält
$-Zeichen. In der.envgehört er in einfache Anführungszeichen. - Domain vergessen: Steht dort noch
http://localhost, zeigen Links in Einladungsmails ins Leere. - Signups offen gelassen: Nach dem Anlegen des eigenen Accounts sofort abschalten. Bei mir selbst war das beim Schreiben dieses Guides noch offen, ich habe es dann direkt geschlossen.
Zum Schluss noch Monitoring: Vaultwarden hat unter /alive einen Endpoint, den du gut als HTTP-Check nutzen kannst. Wie du solche Checks mit Benachrichtigung aufs Handy umsetzt, zeige ich in Uptime Kuma und ntfy.
Fazit
Vaultwarden im LXC braucht wenig Pflege, bei mir läuft es seit über einem Jahr. Das Community-Script nimmt dir die Installation ab, Caddy kümmert sich um HTTPS, und die Bitwarden-Apps funktionieren ohne Einschränkungen. Die Arbeit steckt in den Details: Signups schließen, die Domain richtig setzen, den Admin-Token hashen und vor allem Backups, die du auch schon einmal zurückgespielt hast. Bei mir steht die tägliche Offsite-Sicherung der Datenbank als Nächstes auf der Liste.
Hat dir der Guide geholfen? Dann spendier mir gern einen Kaffee auf Ko-fi. Damit bleibt MappleBox werbefrei.
