Vaultwarden einrichten: 12 Schritte [2026]

Ein eigener Passwort-Manager auf eigener Hardware, voll kompatibel mit allen Bitwarden-Apps, und das mit rund 15 MB Arbeitsspeicher: Genau das liefert Vaultwarden. Das in Rust geschriebene Projekt bildet die Bitwarden-Server-API nach und läuft selbst auf einem Raspberry Pi oder einem alten NAS flüssig. Der offizielle Bitwarden-Server braucht dafür typischerweise 1 GB RAM und mehr, weil er auf einem Java-Stack mit mehreren Containern aufsetzt.

Diese Anleitung führt Sie in 12 Schritten durch eine produktionsreife Installation: Docker, docker-compose.yml, ein Argon2-gehashter Admin-Token, ein Reverse Proxy mit HTTPS, automatische Backups und Härtung mit Fail2ban. Alle Befehle sind getestet, alle Versionsangaben stammen aus offiziellen Quellen. Stand: 15. Juni 2026, Vaultwarden 1.36.0.

Was ist Vaultwarden und warum selbst hosten?

Vaultwarden (früher unter dem Namen Bitwarden_RS bekannt) ist eine inoffizielle, quelloffene Neuimplementierung der Bitwarden-Server-API in Rust. Das Projekt von Daniel García steht unter der AGPL-3.0-Lizenz und zählt im Juni 2026 über 62.000 Sterne auf GitHub, bei rund 2.900 Forks. Damit gehört es zu den populärsten Self-Hosting-Projekten überhaupt.

Der entscheidende Punkt: Vaultwarden spricht dasselbe Protokoll wie die offiziellen Bitwarden-Clients. Sie nutzen also die regulären Apps für Desktop, Browser-Erweiterung, iOS und Android sowie die Web-Oberfläche, verbinden sie aber mit Ihrem eigenen Server statt mit der Bitwarden-Cloud. Funktionen wie Tresor-Freigaben, TOTP-Generierung, Passkeys, Organisationen und Notfallzugriff funktionieren weiterhin.

Warum überhaupt selbst hosten? Drei Gründe stechen heraus. Erstens die Datensouveränität: Ihre verschlüsselten Tresore liegen auf Ihrer Infrastruktur, nicht auf US-Servern. Für Unternehmen und Behörden im DACH-Raum ist das ein DSGVO-Argument von Gewicht. Zweitens die Kosten: Premium-Funktionen, die bei Bitwarden Geld kosten (etwa der integrierte TOTP-Generator oder Organisationen mit mehreren Nutzern), sind bei Vaultwarden ohne Abo verfügbar. Drittens die Effizienz: Der Ressourcenhunger ist minimal.

Ein wichtiger Hinweis zur Verantwortung: Mit dem eigenen Server übernehmen Sie auch das Risiko. Updates, Backups, TLS-Zertifikate und Erreichbarkeit liegen jetzt bei Ihnen. Wer eine zentrale Datei verliert oder den Server falsch absichert, gefährdet alle gespeicherten Zugangsdaten. Diese Anleitung deckt deshalb nicht nur die Installation ab, sondern auch Backup und Härtung.

Vaultwarden vs. offizieller Bitwarden-Server

Beide Server lassen sich selbst betreiben, unterscheiden sich aber technisch deutlich. Die offizielle Bitwarden-Self-Hosting-Variante besteht aus mehreren Docker-Containern (API, Identity, Web-Vault, SQL Server, Nginx) und ist für größere Organisationen mit kommerziellem Support gedacht. Vaultwarden packt alles in eine einzige Rust-Binärdatei und ist für kleine bis mittlere Setups ideal.

Merkmal	Vaultwarden 1.36.0	Bitwarden (offiziell, self-hosted)
Sprache	Rust	C#/.NET und Java-Komponenten
RAM-Bedarf (Leerlauf)	ca. 10 bis 15 MB	ca. 1 bis 1,5 GB
Container	1 (alles inklusive)	mehrere (API, Identity, DB, Proxy)
Standard-Datenbank	SQLite	MS SQL Server
Premium-Funktionen	kostenlos enthalten	teils kostenpflichtige Lizenz
Lizenz	AGPL-3.0	proprietär plus AGPL-Anteile
Eignung	Privat, Familie, kleines Team	Unternehmen mit Support-Vertrag
Offizieller Support	Community-Forum	kommerzieller Bitwarden-Support

Der Unterschied von rund Faktor 100 beim Arbeitsspeicher ist kein Tippfehler. Genau deshalb läuft Vaultwarden problemlos auf einem Raspberry Pi 4, einem Synology- oder QNAP-NAS oder einem günstigen VPS mit 1 GB RAM. Wer dagegen mehrere hundert Nutzer mit kommerziellem SLA verwalten muss, fährt mit der offiziellen Variante oder der Bitwarden-Cloud besser.

Ein Detail zur Lizenz: Vaultwarden bündelt das offizielle Web-Vault, das unter einer eigenen Lizenz steht. Der private Eigenbetrieb ist davon nicht betroffen. Eine kommerzielle Weiterverbreitung sollte die Lizenzbedingungen genau prüfen.

Voraussetzungen und Versionen

Bevor Sie starten, sollten diese Komponenten bereitstehen. Die Versionsangaben sind getestete Mindeststände, neuere Versionen funktionieren ebenfalls.

Ein Linux-Server (empfohlen: Debian 12, Ubuntu 24.04 LTS oder vergleichbar) mit Root- oder sudo-Zugriff.
Docker Engine 27 oder neuer und das Plugin Docker Compose v2 (Befehl docker compose, nicht das alte docker-compose).
Eine eigene (Sub-)Domain, etwa vault.example.de, mit einem A- bzw. AAAA-Record, der auf die öffentliche IP des Servers zeigt.
Offene Ports 80 und 443 in der Firewall, da Let’s Encrypt für die Zertifikatsausstellung Port 80 erreichen muss.
Ein Reverse Proxy. Diese Anleitung nutzt Nginx, Caddy oder Traefik funktionieren analog.
Vaultwarden 1.36.0 (Docker-Image vaultwarden/server, veröffentlicht am 3. Mai 2026).
Mindestens 512 MB RAM und 1 GB freier Speicher, für Backups etwas mehr.

Warum eine echte Domain und nicht nur eine IP? Die Bitwarden-Clients setzen auf die WebCrypto-API des Browsers (window.crypto.subtle). Diese ist nur in einem sicheren Kontext (HTTPS) verfügbar. Ohne gültiges TLS-Zertifikat scheitert die Ver- und Entschlüsselung im Browser, und der Tresor lädt nicht. Eine Domain brauchen Sie deshalb zwingend, ein selbstsigniertes Zertifikat führt auf Mobilgeräten regelmäßig zu Problemen.

Prüfen Sie zuerst, ob Docker korrekt installiert ist:

$ docker --version
Docker version 27.5.1, build 9f9e405

$ docker compose version
Docker Compose version v2.32.4

Schritt 1 bis 3: Server vorbereiten und Docker installieren

Schritt 1: System aktualisieren

Bringen Sie das Betriebssystem zuerst auf den aktuellen Stand. Auf Debian oder Ubuntu:

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl ca-certificates sqlite3

Schritt 2: Docker und Compose installieren

Das offizielle Installationsskript von Docker richtet Engine und Compose-Plugin in einem Schritt ein. Eine ausführliche Referenz dazu liefert die offizielle Docker-Compose-Dokumentation:

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER
# danach einmal ab- und wieder anmelden, damit die Gruppe greift

Die Zugehörigkeit zur Gruppe docker erlaubt Docker-Befehle ohne sudo. Beachten Sie, dass diese Gruppe faktisch Root-Rechte gewährt. Nehmen Sie nur vertrauenswürdige Konten auf.

Schritt 3: Projektverzeichnis anlegen

Legen Sie einen festen Ort für Konfiguration und Daten an. Diese Trennung erleichtert spätere Backups:

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

Im Ordner vw-data wird Vaultwarden später die SQLite-Datenbank (db.sqlite3), den RSA-Schlüssel, Anhänge und die Logdatei ablegen. Dieser Ordner ist Ihr wertvollstes Gut. Wer ihn verliert, verliert alle Tresore.

Schritt 4 bis 6: docker-compose.yml und ADMIN_TOKEN

Schritt 4: Admin-Token mit Argon2 erzeugen

Das Admin-Panel von Vaultwarden ist über /admin erreichbar und schützt sich mit dem ADMIN_TOKEN. Speichern Sie diesen Token niemals im Klartext. Vaultwarden bringt einen Befehl mit, der Ihr Passwort als Argon2id-Hash im PHC-Format ausgibt:

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

Sie werden zur Eingabe eines starken Passworts aufgefordert. Die Ausgabe sieht etwa so aus:

Generate an Argon2id PHC string...
Please provide the password:

ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$bXBhc3N3b3Jkc2FsdA$Nq7l...gP4'

Kopieren Sie die gesamte Zeichenkette inklusive $argon2id.... Argon2id ist ein speicherintensives Hash-Verfahren, das Brute-Force auf den Token erheblich verteuert. Mehr zur Funktionsweise solcher Verfahren lesen Sie in unserem Beitrag zur Passwortsicherheit mit Hashing und 2FA.

Schritt 5: docker-compose.yml schreiben

Erstellen Sie die Datei /opt/vaultwarden/docker-compose.yml. Tragen Sie Ihre Domain und den eben erzeugten Token ein. Achtung beim Dollarzeichen: Docker Compose interpretiert $ als Variable. Hinterlegen Sie den Token deshalb in einer separaten .env-Datei oder verdoppeln Sie jedes $ zu $$.

services:
  vaultwarden:
    image: vaultwarden/server:1.36.0
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.de"
      SIGNUPS_ALLOWED: "true"
      ADMIN_TOKEN: ${ADMIN_TOKEN}
      LOG_FILE: "/data/vaultwarden.log"
      LOG_LEVEL: "warn"
      ROCKET_PORT: "80"
    volumes:
      - ./vw-data:/data
    ports:
      - "127.0.0.1:8080:80"

Legen Sie daneben eine Datei .env an, die den Token enthält. So vermeiden Sie das Escaping-Problem und halten das Geheimnis aus der Compose-Datei heraus:

# /opt/vaultwarden/.env
ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$bXBhc3N3b3Jkc2FsdA$Nq7l...gP4'

Zwei Punkte sind hier zentral. Erstens bindet ports: "127.0.0.1:8080:80" den Dienst nur an localhost. Vaultwarden ist damit nicht direkt aus dem Internet erreichbar, sondern ausschließlich über den Reverse Proxy. Zweitens fixiert das Tag :1.36.0 die Version. Verwenden Sie nicht das Tag :latest, denn unkontrollierte Upgrades können Migrationen auslösen, die Sie nicht eingeplant haben.

Schritt 6: Wichtige Umgebungsvariablen verstehen

Vaultwarden steuert nahezu alles über Umgebungsvariablen. Diese Auswahl deckt die wichtigsten Fälle ab:

Variable	Beispielwert	Funktion
`DOMAIN`	https://vault.example.de	Vollständige URL, zwingend für Login und WebCrypto
`ADMIN_TOKEN`	$argon2id$v=19$…	Argon2-Hash für das Admin-Panel
`SIGNUPS_ALLOWED`	false	Selbstregistrierung erlauben oder sperren
`SIGNUPS_DOMAINS_WHITELIST`	example.de	Registrierung nur für bestimmte Mail-Domains
`INVITATIONS_ALLOWED`	true	Einladungen trotz gesperrter Registrierung
`SMTP_HOST`	mail.example.de	Mailserver für Einladungen und 2FA-Mails
`PUSH_ENABLED`	true	Push-Benachrichtigungen an Mobil-Apps
`LOG_FILE`	/data/vaultwarden.log	Logdatei, Voraussetzung für Fail2ban

Die vollständige Referenz pflegt das Projekt im offiziellen Vaultwarden-Wiki. Stellen Sie SIGNUPS_ALLOWED nur für die Ersteinrichtung auf true und sperren Sie es danach sofort wieder.

Schritt 7 bis 9: Reverse Proxy und HTTPS mit Nginx

Schritt 7: Container starten

Starten Sie Vaultwarden im Hintergrund und prüfen Sie den Status:

cd /opt/vaultwarden
docker compose up -d
docker compose logs -f --tail 20

Eine erfolgreiche Ausgabe sieht so aus:

vaultwarden  | [INFO] Rocket has launched from http://0.0.0.0:80
vaultwarden  | [INFO] Starting Vaultwarden 1.36.0
vaultwarden  | [INFO] Web-Vault version: 2026.x.x
vaultwarden  | [INFO] Database: SQLite

Schritt 8: TLS-Zertifikat besorgen

Holen Sie ein kostenloses Let’s-Encrypt-Zertifikat. Der detaillierte Ablauf steht in unserer Anleitung Let’s Encrypt: Zertifikat in 12 Schritten. In Kurzform mit Certbot:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d vault.example.de

Schritt 9: Nginx als Reverse Proxy konfigurieren

Der Proxy nimmt HTTPS auf Port 443 entgegen und leitet intern an den localhost-Port 8080 weiter. Wichtig sind die WebSocket-Header, denn seit Version 1.29 laufen die Echtzeit-Benachrichtigungen über den Hauptport. Ein separater Port 3012 ist nicht mehr nötig.

server {
    listen 443 ssl http2;
    server_name vault.example.de;

    ssl_certificate     /etc/letsencrypt/live/vault.example.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/vault.example.de/privkey.pem;

    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";
    }
}

Prüfen und laden Sie die Konfiguration neu:

sudo nginx -t && sudo systemctl reload nginx

Die Zeile client_max_body_size 525M ist kein Zufallswert. Bitwarden erlaubt Anhänge, und ohne diese Grenze blockt Nginx größere Uploads mit Fehler 413. Wer die WebSocket-Header vergisst, bemerkt es erst später: Tresor-Änderungen synchronisieren sich dann nicht mehr in Echtzeit zwischen Geräten. Die Grundlagen eines Reverse Proxy erklären wir ausführlich in der Anleitung Nginx Reverse Proxy: HTTPS in 12 Schritten.

Schritt 10 bis 12: Anmeldung, Admin-Panel, Registrierung sperren

Schritt 10: Erstes Konto anlegen

Rufen Sie https://vault.example.de im Browser auf. Sie sehen die vertraute Bitwarden-Oberfläche. Legen Sie über “Konto erstellen” Ihr erstes Konto an. Das Master-Passwort verlässt niemals Ihr Gerät: Der Client leitet daraus mit Argon2id einen Schlüssel ab und sendet nur ein abgeleitetes Authentifizierungs-Hash an den Server. Selbst der Serverbetreiber kann die Tresore nicht entschlüsseln.

Schritt 11: Admin-Panel öffnen

Öffnen Sie https://vault.example.de/admin und melden Sie sich mit dem Klartext-Passwort an, aus dem Sie in Schritt 4 den Token erzeugt haben. Im Panel verwalten Sie Nutzer, Organisationen, Diagnose und die globalen Einstellungen. Hier sehen Sie auch, ob ein Update verfügbar ist.

Schritt 12: Registrierung sperren

Sobald alle gewünschten Konten existieren, schließen Sie die Tür. Setzen Sie in der docker-compose.yml den Wert SIGNUPS_ALLOWED: "false" und starten Sie den Container neu:

docker compose up -d --force-recreate

Ab jetzt kann sich niemand mehr ungefragt registrieren. Neue Nutzer fügen Sie über das Admin-Panel per Einladung hinzu, sofern INVITATIONS_ALLOWED aktiv ist und ein SMTP-Server hinterlegt ist. Damit ist die Grundinstallation fertig. Die nächsten Abschnitte machen den Server produktionsreif.

Datenbank-Backends: SQLite, MySQL oder PostgreSQL?

Vaultwarden unterstützt drei Datenbanken. Für die allermeisten Selbsthoster ist SQLite die richtige Wahl, weil es ohne separaten Datenbankserver auskommt und in einer einzigen Datei liegt. MySQL/MariaDB und PostgreSQL lohnen sich erst bei vielen gleichzeitigen Nutzern oder wenn ohnehin ein Datenbankcluster existiert.

Backend	Konfiguration	Empfohlen für	Backup-Methode
SQLite (Standard)	keine, Datei in /data	Privat, Familie, kleines Team	`sqlite3 .backup`
MariaDB / MySQL	`DATABASE_URL=mysql://...`	Mittlere Teams, vorhandener DB-Server	`mysqldump`
PostgreSQL	`DATABASE_URL=postgresql://...`	Große Setups, hohe Parallelität	`pg_dump`

Wer mit SQLite startet und später wechseln will, sollte das früh tun. Eine Migration zwischen den Backends ist nicht im Standard enthalten und erfordert ein separates Werkzeug wie pgloader oder einen Export-Import über das Web-Vault. Für ein klassisches Heim- oder Familiensetup bleibt SQLite die robusteste und einfachste Lösung.

Backups automatisieren

Ein Passwort-Manager ohne Backup ist eine Zeitbombe. Drei Dinge müssen Sie sichern: die Datenbank db.sqlite3, den RSA-Schlüssel (rsa_key.pem bzw. rsa_key.*) und den Ordner attachments. Ohne den RSA-Schlüssel lassen sich bestehende Sitzungen und manche Daten nach einem Restore nicht mehr verwenden.

Wichtig bei SQLite: Kopieren Sie die Datei nicht einfach mit cp, während der Server läuft. Das kann eine inkonsistente Kopie erzeugen. Nutzen Sie den eingebauten Sicherungsbefehl, der eine konsistente Momentaufnahme erstellt:

#!/bin/bash
# /opt/vaultwarden/backup.sh
set -euo pipefail

DATA_DIR="/opt/vaultwarden/vw-data"
BACKUP_DIR="/opt/backups/vaultwarden"
STAMP="$(date +%Y-%m-%d_%H%M)"

mkdir -p "$BACKUP_DIR"

# Konsistente SQLite-Sicherung
sqlite3 "$DATA_DIR/db.sqlite3" ".backup '$BACKUP_DIR/db_$STAMP.sqlite3'"

# Schluessel, Anhaenge und Konfiguration
tar czf "$BACKUP_DIR/files_$STAMP.tar.gz" -C "$DATA_DIR" \
    attachments config.json rsa_key.pem rsa_key.pub.pem 2>/dev/null || true

# Sicherungen aelter als 14 Tage entfernen
find "$BACKUP_DIR" -type f -mtime +14 -delete

echo "Backup abgeschlossen: $STAMP"

Machen Sie das Skript ausführbar und planen Sie es per Cron, hier täglich um 03:30 Uhr:

chmod +x /opt/vaultwarden/backup.sh
( crontab -l 2>/dev/null; echo "30 3 * * * /opt/vaultwarden/backup.sh >> /var/log/vw-backup.log 2>&1" ) | crontab -

Eine Sicherung am selben Server schützt nicht vor Festplattendefekt oder Ransomware. Kopieren Sie die Backups regelmäßig an einen zweiten Ort, etwa per rsync auf ein NAS oder verschlüsselt in einen Cloud-Speicher. Testen Sie mindestens einmal das Zurückspielen. Ein Backup, das Sie nie wiederhergestellt haben, ist nur eine Hoffnung.

Sicherheit härten: Fail2ban, 2FA und Argon2id

Ein öffentlich erreichbarer Login zieht automatisierte Angriffe an. Drei Maßnahmen senken das Risiko deutlich.

Fail2ban gegen Brute-Force

Fail2ban wertet die Logdatei aus und sperrt IP-Adressen nach mehreren Fehlversuchen. Voraussetzung ist, dass Sie LOG_FILE gesetzt haben. Legen Sie einen Filter unter /etc/fail2ban/filter.d/vaultwarden.conf an:

[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Dazu die Jail unter /etc/fail2ban/jail.d/vaultwarden.local:

[vaultwarden]
enabled  = true
port     = 80,443
filter   = vaultwarden
logpath  = /opt/vaultwarden/vw-data/vaultwarden.log
maxretry = 5
bantime  = 14400
findtime = 14400

Nach sudo systemctl restart fail2ban werden Adressen nach fünf Fehlversuchen für vier Stunden gesperrt. Eine ausführliche Einführung samt Prüfbefehlen finden Sie in unserer Anleitung Fail2ban einrichten: SSH-Schutz in 12 Schritten.

Zwei-Faktor-Authentifizierung erzwingen

Jeder Nutzer sollte in den Kontoeinstellungen 2FA aktivieren, am besten per TOTP-App oder Hardware-Schlüssel (FIDO2/WebAuthn). Für E-Mail-basierte 2FA und Einladungen muss ein SMTP-Server in den Variablen SMTP_HOST, SMTP_FROM und SMTP_PORT hinterlegt sein. TOTP funktioniert auch ohne Mailserver.

Argon2id als Schlüsselableitung

Die Bitwarden-Clients leiten den Tresorschlüssel seit 2023 standardmäßig mit Argon2id ab. Die Standardparameter sind 64 MiB Speicher, 3 Iterationen und 4 parallele Threads. Diese Werte machen Offline-Angriffe auf einen gestohlenen Tresor extrem teuer. Prüfen Sie in den Sicherheitseinstellungen Ihres Kontos, ob als KDF “Argon2id” und nicht das ältere “PBKDF2” eingestellt ist. Details erklärt die offizielle Bitwarden-Dokumentation zu KDF-Algorithmen.

Caddy statt Nginx: TLS vollautomatisch

Wer den Reverse Proxy noch einfacher haben will, nutzt Caddy statt Nginx. Caddy holt und erneuert Let’s-Encrypt-Zertifikate vollautomatisch, ohne separaten Certbot-Aufruf. Die gesamte Konfiguration passt in wenige Zeilen. Statt einer langen Nginx-Datei genügt diese Caddyfile:

vault.example.de {
    encode gzip
    reverse_proxy 127.0.0.1:8080 {
        header_up X-Real-IP {remote_host}
    }
    request_body {
        max_size 525MB
    }
}

Caddy verwaltet die WebSocket-Upgrades automatisch, sodass die manuellen Header aus dem Nginx-Beispiel entfallen. Das macht den Einstieg deutlich fehlerärmer. Der Nachteil: Bei sehr komplexen Setups mit mehreren Diensten und feinem Caching ist Nginx flexibler. Für einen einzelnen Vaultwarden-Server ist Caddy aber die schnellste und sauberste Lösung. Starten Sie Caddy einfach als zusätzlichen Container im selben docker-compose.yml oder als Systemdienst.

Egal ob Nginx, Caddy oder Traefik: Der interne Vaultwarden-Port darf nie direkt aus dem Internet erreichbar sein. Die Bindung an 127.0.0.1 in der Compose-Datei stellt das sicher. Nur der Proxy mit gültigem TLS-Zertifikat spricht mit dem Internet.

SMTP für Einladungen und 2FA-Mails einrichten

Sobald Sie die Registrierung sperren, brauchen neue Nutzer eine Einladung per E-Mail. Auch E-Mail-basierte 2FA und Hinweise bei neuen Geräten setzen einen funktionierenden Mailversand voraus. Vaultwarden bringt dafür eigene SMTP-Variablen mit. Ergänzen Sie den environment-Block in der Compose-Datei:

      SMTP_HOST: "mail.example.de"
      SMTP_FROM: "[email protected]"
      SMTP_FROM_NAME: "Vaultwarden"
      SMTP_SECURITY: "starttls"
      SMTP_PORT: "587"
      SMTP_USERNAME: "[email protected]"
      SMTP_PASSWORD: "IHR_SMTP_PASSWORT"

Nach einem Neustart des Containers können Sie im Admin-Panel unter “Diagnostics” eine Test-Mail verschicken. Kommt sie nicht an, prüfen Sie zuerst Port und Sicherheitsmodus. Viele Provider nutzen starttls auf Port 587, manche force_tls auf Port 465. Achten Sie außerdem darauf, dass die Absenderadresse zur Domain passt, sonst landen die Mails im Spam oder werden abgewiesen.

Ein häufiger Stolperstein: Manche Heim-Internetanschlüsse blockieren ausgehenden Verkehr auf Port 25. Das betrifft den direkten Versand, nicht aber den Versand über einen authentifizierten SMTP-Server auf Port 587. Wer keinen eigenen Mailserver betreibt, kann einen beliebigen Postfach-Anbieter als Relay nutzen, solange dieser SMTP-Auth erlaubt.

Vaultwarden auf NAS und Raspberry Pi betreiben

Der geringe Ressourcenbedarf macht Vaultwarden zum Klassiker für Heimserver. Auf einem Synology- oder QNAP-NAS installieren Sie es über die jeweilige Container-Verwaltung (Container Manager bzw. Container Station). Wichtig ist auch hier: Das NAS sollte nicht ungeschützt im Internet hängen. Setzen Sie den im Gerät integrierten Reverse Proxy davor und holen Sie ein gültiges Zertifikat über die Zertifikatsverwaltung des Herstellers.

Auf dem Raspberry Pi 4 oder 5 läuft das identische Docker-Image, da Vaultwarden ARM64 unterstützt. Die Installation folgt exakt dieser Anleitung. Achten Sie nur auf den Speicher: Eine schnelle und zuverlässige SSD per USB ist einer SD-Karte deutlich überlegen, denn SQLite schreibt häufig kleine Datenmengen, und SD-Karten verschleißen darunter schneller. Legen Sie das Verzeichnis vw-data deshalb auf die SSD.

Für die Erreichbarkeit von außen ohne feste IP-Adresse hilft ein DynDNS-Dienst, der Ihre wechselnde Heim-IP einem Hostnamen zuordnet. Alternativ binden Sie den Dienst hinter ein WireGuard-VPN und greifen nur über den Tunnel zu. Diese Variante ist sicherer, weil der Login-Endpunkt dann gar nicht öffentlich erreichbar ist, kostet aber etwas Komfort beim mobilen Zugriff.

Egal auf welcher Hardware: Backups und Updates bleiben Ihre Aufgabe. Gerade auf einem Heimserver, der unbeaufsichtigt läuft, ist ein automatisiertes Backup auf ein zweites Gerät unverzichtbar. Ein Stromausfall oder ein defektes Speichermedium darf nicht das Ende aller Passwörter bedeuten.

Kosten und Wartungsaufwand realistisch einschätzen

Self-Hosting ist nicht kostenlos, auch wenn die Software nichts kostet. Sie tauschen Abogebühren gegen Zeit und Verantwortung. Diese Übersicht hilft bei der ehrlichen Einschätzung, ob sich der Eigenbetrieb für Sie lohnt:

Posten	Vaultwarden (Self-Hosted)	Bitwarden-Cloud (Premium)
Software-Lizenz	0 € (AGPL-3.0)	ca. 10 US-Dollar pro Jahr
Serverkosten	VPS ab ca. 3 bis 5 € im Monat oder eigene Hardware	entfällt
Wartung	Updates, Backups, TLS, Monitoring	vom Anbieter übernommen
Datenstandort	frei wählbar (z. B. EU)	vom Tarif abhängig
Premium-Funktionen	enthalten	im Premium-Tarif enthalten
Ausfallrisiko	liegt bei Ihnen	beim Anbieter

Die Faustregel: Wer ohnehin einen Heimserver oder VPS betreibt und Freude an der Administration hat, fährt mit Vaultwarden hervorragend und gewinnt volle Datenkontrolle. Wer dagegen keine Lust auf Wartung hat und nur einen verlässlichen Passwort-Speicher sucht, ist mit der gehosteten Bitwarden-Variante oder einer anderen fertigen Lösung besser bedient. Rechnen Sie pro Monat realistisch mit 15 bis 30 Minuten Wartungsaufwand für Updates und das Prüfen der Backups.

Häufige Fehler und Stolperfallen

Diese Fehler kosten erfahrungsgemäß die meiste Zeit. Wer sie kennt, spart sich die Fehlersuche.

Falscher DOMAIN-Wert. Stimmt DOMAIN nicht exakt mit der aufgerufenen URL überein (inklusive https:// und ohne abschließenden Schrägstrich), schlägt die Anmeldung fehl und WebCrypto bricht ab.
HTTP statt HTTPS. Ohne gültiges TLS-Zertifikat lädt der Tresor nicht, weil der Browser window.crypto.subtle nur im sicheren Kontext freigibt.
Token nicht gehasht. Wer das Klartext-Passwort als ADMIN_TOKEN einträgt, kommt ab Version 1.30 nicht mehr ins Admin-Panel. Es muss der Argon2-Hash sein.
Dollarzeichen nicht escaped. In der docker-compose.yml muss jedes $ im Token verdoppelt werden, sonst zerlegt Compose den Hash. Besser: in .env auslagern.
Volume vergessen. Ohne Mount von ./vw-data:/data liegen alle Daten nur im Container und sind nach einem docker compose down verloren.
Fehlende WebSocket-Header. Ohne die Upgrade-Header im Proxy synchronisieren sich Geräte nicht in Echtzeit.

Troubleshooting: 8 typische Probleme lösen

Wenn etwas nicht funktioniert, hilft fast immer zuerst ein Blick in die Logs mit docker compose logs --tail 50. Diese acht Fälle treten am häufigsten auf:

“An error has occurred” beim Login. Meist stimmt DOMAIN nicht oder das Zertifikat ist ungültig. Vergleichen Sie den Wert mit der Browser-Adresszeile und prüfen Sie das Zertifikat mit curl -vI https://vault.example.de.
Admin-Panel verweigert das Passwort. Der Token ist vermutlich nicht gehasht oder das $ wurde in Compose falsch interpretiert. Erzeugen Sie den Hash neu und legen Sie ihn in .env ab.
Container startet nicht (Exit 0/1). Prüfen Sie mit docker compose logs auf Syntaxfehler in der YAML-Datei oder fehlende Schreibrechte auf vw-data. Setzen Sie mit sudo chown -R 1000:1000 vw-data die Eigentümerrechte.
Fehler 413 beim Anhang-Upload. Erhöhen Sie client_max_body_size im Nginx-Block und laden Sie die Konfiguration neu.
Keine Echtzeit-Synchronisierung. Es fehlen die WebSocket-Header (Upgrade und Connection) im Proxy. Ergänzen Sie sie und starten Sie Nginx neu.
Push-Benachrichtigungen kommen nicht an. Push erfordert eine Registrierung der Server-Installation bei Bitwarden sowie korrekte PUSH_INSTALLATION_ID und PUSH_INSTALLATION_KEY.
Mobile App verbindet sich nicht. Tragen Sie die Server-URL in der App unter “Selbst gehostet” ein, bevor Sie sich anmelden. Selbstsignierte Zertifikate werden auf Mobilgeräten oft abgelehnt, nutzen Sie Let’s Encrypt.
Fail2ban sperrt nichts. Häufig fehlt LOG_FILE oder der logpath in der Jail zeigt auf den falschen Ort. Testen Sie den Filter mit fail2ban-regex /opt/vaultwarden/vw-data/vaultwarden.log /etc/fail2ban/filter.d/vaultwarden.conf.

Fortgeschrittene Tipps für den Produktivbetrieb

Wer Vaultwarden dauerhaft betreibt, holt mit diesen Maßnahmen mehr Sicherheit und Komfort heraus.

Updates kontrolliert einspielen. Pinnen Sie die Version im Tag und aktualisieren Sie bewusst: docker compose pull nach Anpassung des Tags, dann docker compose up -d. Lesen Sie vorher die Release-Notes auf GitHub. Vor jedem Update: Backup.
Organisationen und Collections nutzen. Für Familien oder Teams legen Sie eine Organisation an und teilen Tresoreinträge über Collections mit feingranularen Rechten. Bei Vaultwarden ist das ohne Abo möglich.
Notfallzugriff einrichten. Über “Emergency Access” gewähren Sie einer Vertrauensperson nach einer Wartezeit Lese- oder Übernahmezugriff. Das löst das klassische Problem, was mit den Passwörtern im Ernstfall geschieht.
Reverse Proxy mit Rate-Limiting. Ergänzen Sie in Nginx eine limit_req_zone speziell für /admin und die Login-Endpunkte, um automatisierte Angriffe zusätzlich zu Fail2ban auszubremsen.
Geoblocking oder VPN-only. Wer das Admin-Panel nicht öffentlich braucht, beschränkt /admin per Nginx auf interne IP-Bereiche oder bindet den ganzen Dienst hinter ein WireGuard-VPN.
Monitoring. Ein einfacher Uptime-Check plus eine Benachrichtigung bei vollem Speicher verhindert böse Überraschungen. Vaultwarden bietet unter /alive einen Health-Endpoint.

DSGVO und Datensouveränität im DACH-Raum

Für Unternehmen, Vereine und Behörden in Deutschland, Österreich und der Schweiz ist der Speicherort der Daten ein zentrales Kriterium. Ein selbst gehosteter Vaultwarden auf einem Server in der EU hält sämtliche Zugangsdaten innerhalb der eigenen Kontrolle. Es gibt keinen US-Cloud-Anbieter, kein Drittland-Transfer-Problem und keine Abhängigkeit von der Verfügbarkeit eines externen Dienstes.

Das Zero-Knowledge-Prinzip von Bitwarden bleibt dabei erhalten: Die Tresore werden auf dem Client mit dem aus dem Master-Passwort abgeleiteten Schlüssel ver- und entschlüsselt. Der Server speichert nur Chiffrate. Selbst bei einem Servereinbruch sind die Inhalte ohne Master-Passwort wertlos, vorausgesetzt, die Nutzer haben starke Passwörter und Argon2id als KDF gewählt.

Trotzdem entbindet Self-Hosting nicht von Pflichten. Wer personenbezogene Daten von Mitarbeitenden in einem Passwort-Manager verwaltet, braucht ein Verarbeitungsverzeichnis, ein Backup-Konzept und technische Maßnahmen wie die hier gezeigte Härtung. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt Passwort-Manager ausdrücklich und gibt praktische Hinweise in seinen Empfehlungen zu sicheren Passwörtern. Eine Marktübersicht über fertige Lösungen bietet unser Passwort-Manager-Vergleich 2026.

Komplettes Beispielprojekt im Überblick

Zum Abschluss die fertige Verzeichnisstruktur eines produktiven Setups, wie es nach dieser Anleitung entsteht:

/opt/vaultwarden/
├── docker-compose.yml      # Dienstdefinition, Version 1.36.0 gepinnt
├── .env                    # ADMIN_TOKEN (Argon2-Hash)
├── backup.sh               # taegliches Backup-Skript
└── vw-data/                # persistente Daten (Backup-Ziel!)
    ├── db.sqlite3          # Tresordatenbank
    ├── rsa_key.pem         # Server-Schluessel
    ├── attachments/        # Datei-Anhaenge
    ├── config.json         # im Admin-Panel gesetzte Optionen
    └── vaultwarden.log     # Log fuer Fail2ban

/etc/nginx/sites-available/vaultwarden   # Reverse-Proxy-Block
/etc/fail2ban/filter.d/vaultwarden.conf  # Brute-Force-Filter
/etc/fail2ban/jail.d/vaultwarden.local   # Sperr-Regeln
/opt/backups/vaultwarden/                # rotierende Backups

Prüfen Sie zum Schluss, ob alles läuft. Ein docker compose ps sollte den Status running zeigen, und der Health-Endpoint antwortet:

$ curl -s https://vault.example.de/alive
2026-06-15T08:42:11.532Z

$ docker compose ps
NAME          IMAGE                       STATUS         PORTS
vaultwarden   vaultwarden/server:1.36.0   Up 3 minutes   127.0.0.1:8080->80/tcp

Damit haben Sie einen vollständigen, gehärteten und gesicherten Bitwarden-kompatiblen Passwort-Server. Er läuft mit minimalen Ressourcen, hält Ihre Daten in der EU und kostet außer dem Server keinen Cent an Lizenzgebühren.

Häufig gestellte Fragen (FAQ)

Ist Vaultwarden sicher genug für sensible Passwörter?

Ja, sofern Sie es korrekt betreiben. Die Verschlüsselung folgt dem Zero-Knowledge-Prinzip von Bitwarden, der Server sieht nur Chiffrate. Entscheidend sind ein starkes Master-Passwort, Argon2id als KDF, HTTPS, aktivierte 2FA und regelmäßige Updates. Die in dieser Anleitung gezeigte Härtung mit Fail2ban und gesperrter Registrierung deckt die wichtigsten Angriffsflächen ab.

Worin unterscheidet sich Vaultwarden von Bitwarden?

Vaultwarden ist eine inoffizielle, ressourcenschonende Neuimplementierung der Bitwarden-Server-API in Rust. Es stammt nicht von Bitwarden Inc., nutzt aber dieselben Client-Apps und schaltet einige sonst kostenpflichtige Funktionen frei. Für große Unternehmen mit Support-Bedarf bleibt die offizielle Variante die richtige Wahl.

Brauche ich zwingend HTTPS und eine Domain?

Ja. Die Bitwarden-Clients nutzen die WebCrypto-API, die nur in einem sicheren Kontext (HTTPS) verfügbar ist. Ohne gültiges TLS-Zertifikat lädt der Tresor im Browser nicht, und Mobil-Apps lehnen selbstsignierte Zertifikate meist ab. Eine eigene Domain mit Let’s-Encrypt-Zertifikat ist daher Pflicht.

Läuft Vaultwarden auf einem Raspberry Pi?

Problemlos. Mit rund 10 bis 15 MB RAM-Bedarf im Leerlauf läuft Vaultwarden auf einem Raspberry Pi 4, einem NAS oder einem 1-GB-VPS. Das Docker-Image unterstützt auch ARM-Architekturen, sodass die Installation identisch zu dieser Anleitung verläuft.

Wie aktualisiere ich Vaultwarden sicher?

Erstellen Sie zuerst ein Backup. Ändern Sie dann das Versions-Tag in der docker-compose.yml, holen Sie das neue Image mit docker compose pull und starten Sie mit docker compose up -d neu. Lesen Sie vorab die Release-Notes auf GitHub, da größere Versionssprünge Datenbankmigrationen auslösen können.

Kann ich von der Bitwarden-Cloud zu Vaultwarden migrieren?

Ja. Exportieren Sie Ihren Tresor in der Bitwarden-App als verschlüsselten oder JSON-Export und importieren Sie ihn nach der Anmeldung am Vaultwarden-Server über die Import-Funktion des Web-Vaults. Achten Sie darauf, dass beide Seiten Argon2id als KDF verwenden, damit die Migration reibungslos läuft.

Welche Datenbank soll ich wählen?

Für die allermeisten privaten und kleinen Setups ist SQLite die beste Wahl: keine Konfiguration, eine einzige Datei, einfaches Backup. MySQL/MariaDB oder PostgreSQL lohnen sich erst bei vielen gleichzeitigen Nutzern oder wenn ohnehin ein Datenbankserver vorhanden ist.

Ist der Eigenbetrieb DSGVO-konform?

Self-Hosting auf einem EU-Server stärkt die Datensouveränität, weil keine Daten in Drittländer fließen. Die DSGVO-Konformität hängt aber von der Gesamtorganisation ab: Verarbeitungsverzeichnis, technische und organisatorische Maßnahmen, Backup-Konzept und Zugriffskontrolle müssen stimmen. Die Technik allein genügt nicht, sie ist aber eine gute Grundlage.

Vaultwarden einrichten: 12 Schritte, 15 MB RAM [2026]