Vaultwarden auf VPS selbst hosten Anleitung

Was Sie aufbauen

Ein Passwortmanager in Ihrem vollständigen Besitz: Vaultwarden läuft in einem kleinen Container hinter einem Reverse Proxy, der HTTPS terminiert. Die offiziellen Bitwarden-Apps auf Ihrem Smartphone, Laptop und Browser sind darauf konfiguriert. Vaultwarden implementiert die Bitwarden-Server-API in Rust neu und nutzt dasselbe Protokoll wie bitwarden.com. Daher funktionieren alle offiziellen Clients unverändert mit dieser Instanz – allerdings benötigt sie nur etwa 100 MB RAM, anstatt des offiziellen Multi-Container-Stacks zu nutzen.

Die Installation besteht lediglich aus einem Dutzend Zeilen Compose. Die drei entscheidenden Faktoren – und die häufigsten Fehlerquellen – sind: TLS muss konfiguriert sein, bevor Sie den Web-Vault laden, öffentliche Registrierungen müssen deaktiviert werden, sobald Ihr eigenes Konto existiert, und das Datenvolumen muss gesichert und durch eine Test-Wiederherstellung validiert werden, da dieses eine Verzeichnis alle Ihre Passwörter enthält.

Voraussetzungen und bekannte Fallstricke

• Ein VPS mit Docker Engine und dem Compose-Plugin auf einem frischen Ubuntu 24.04 KVM-System mit root- oder sudo-Rechten. 512 MB RAM sind ausreichend; 1 GB sind komfortabel. Dies ist eine der ressourcensparendsten Anwendungen — sie steht weit oben auf der Liste der Dienste, die sich zum Self-Hosting eignen.
• Eine Domain mit einem A-Record (und AAAA bei IPv6), der auf vault.example.com zeigt. Das TLS-Zertifikat wird genau für diesen Namen ausgestellt; die DNS-Auflösung muss vor dem Start funktionieren.
• Die Ports 80 und 443 müssen für das Internet offen sein und werden durch Ihren Reverse Proxy terminiert — niemals direkt durch Vaultwarden. Port 80 wird nur für die ACME-Zertifikatsprüfung und die HTTP-zu-HTTPS-Weiterleitung verwendet.
• Der wichtigste Fallstrick zu Beginn: Bitwarden-Clients kommunizieren nicht mit einem Server, der kein HTTPS verwendet. Ein Test über HTTP ist nicht möglich — dieser Weg funktioniert aus einem konkreten Grund nicht, der im nächsten Abschnitt behandelt wird.

Warum Vaultwarden statt des offiziellen Bitwarden-Stacks

Gleiche Clients bei deutlich geringerem Ressourcenverbrauch. Der offizielle selbst gehostete Bitwarden-Stack wird als Container-Bundle ausgeliefert (MSSQL, Nginx, Identity, Api, Admin und weitere) und benötigt etwa 2 GB RAM. Vaultwarden ist eine einzelne Binary, die standardmäßig alles in einer SQLite-Datenbank speichert und im Leerlauf nur wenige zehn Megabyte verbraucht. Für Einzelpersonen, Familien oder kleine Teams ist dies die offensichtliche Wahl. Da die Bitwarden API originalgetreu implementiert wurde, bleiben Ihre Daten zwischen Vaultwarden und bitwarden.com portabel.

Sie verzichten auf den Großteil der Enterprise-Funktionen: es gibt kein SCIM-Provisioning (obwohl experimentelles OpenID Connect SSO in Version 1.35.0 eingeführt wurde). Zudem sind Sie der Administrator, daher liegen Patching, HTTPS und Backups in Ihrer Verantwortung. Diese Anleitung deckt diese drei Aufgaben ab.

Warum HTTPS nicht optional ist

Der Bitwarden Web Vault und die Browser-Extensions generieren Ihre Verschlüsselungsschlüssel im Browser mithilfe der Web Crypto API (window.crypto.subtle). Browser stellen crypto.subtle nur in einem sicheren Kontext bereit – also über HTTPS oder den Sonderfall http://localhost. Über unverschlüsseltes http://vault.example.com ist dies undefined. Sobald die App versucht, einen Schlüssel zu generieren, tritt ein Fehler auf. Die Konsole zeigt:

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'importKey')

Die Seite friert ein oder zeigt einen allgemeinen Krypto-Fehler an. Eine Anmeldung ist nicht möglich. Die Desktop-, Mobile- und Browser-Clients führen eine eigene Prüfung gegen die selbst gehostete URL durch. Gegen einen HTTP-Endpunkt (oder einen nicht erreichbaren Endpunkt) verweigern sie den Dienst mit:

This is not a recognized Bitwarden server. You may need to check with your provider or update your server.

Beide Fälle haben dieselbe Ursache: kein gültiges HTTPS. Konfigurieren Sie daher zuerst TLS. Öffnen Sie den Vault niemals über HTTP, auch nicht für eine kurze Einsicht.

Schritt 1 — DNS und der Reverse Proxy (zuerst TLS)

Zeigen Sie den Record auf Ihren VPS und bestätigen Sie, dass er die korrekte Adresse auflöst:

dig +short vault.example.com

Die ausgegebene Zeile muss die IP Ihres VPS sein. Wenn die Ausgabe leer ist oder die falsche IP anzeigt, korrigieren Sie die DNS-Einstellungen und warten Sie die TTL ab. Die Zertifikatserstellung schlägt fehl, wenn der Name nicht auflöst.

Für das HTTPS-Frontend verwendet diese Anleitung Traefik. Traefik stellt Let's Encrypt-Zertifikate automatisch aus, erneuert diese und lässt sich direkt in Compose integrieren. Falls Sie Traefik noch nicht nutzen, folgen Sie zuerst dem Traefik Reverse Proxy und dem automatischen TLS-Setup. Dieser erstellt ein externes Docker-Netzwerk (proxy unten) und einen ACME-Resolver (letsencrypt), an den sich der Vaultwarden-Dienst bindet. Ein Standard-nginx mit einem manuell ausgestellten Zertifikat funktioniert von der Vaultwarden-Seite aus identisch.

Bevorzugen Sie nginx und Certbot anstelle von Traefik? Setzen Sie Vaultwarden auf 127.0.0.1:8080 (fügen Sie ports: ["127.0.0.1:8080:80"] zum Service hinzu und entfernen Sie die Traefik-Labels), stellen Sie dann ein Zertifikat aus und nutzen Sie einen Proxy darauf. Das Thema Zertifikate wird in der Ausstellung von Let's Encrypt Zertifikaten mit Certbot und nginx behandelt. Die entscheidende zusätzliche Anforderung ist das WebSocket-Upgrade auf dem Benachrichtigungspfad:

server {
    listen 443 ssl;
    server_name vault.example.com;

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

Beachten Sie die X-Real-IP Zeile — diese sorgt dafür, dass Fail2ban später den echten Angreifer erkennt anstatt 127.0.0.1. Alles andere in dieser Anleitung bleibt gleich, unabhängig davon, ob Traefik oder nginx als Frontend genutzt wird.

Schritt 2 — die Compose-Datei

Erstellen Sie zuerst das Projektverzeichnis. Dieses Tutorial verwendet /opt/vaultwarden. Dadurch ist der Compose-Projektname – und somit das Datenvolume vaultwarden_vw-data – vorhersagbar. Die nachfolgenden Schritte für Fail2ban und das Backup hängen von diesem exakten Namen ab.

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

Erstellen Sie ein .env für das Admin-Secret und die Compose-Datei in diesem Verzeichnis.

# .env
ADMIN_TOKEN=paste-a-strong-token-here

Generieren Sie den Token mit openssl rand -base64 48 und fügen Sie ihn ein. (Eine sicherere Hash-Form wird im nächsten Schritt behandelt; ein langer Zufallsstring ist für den Anfang ausreichend.)

# docker-compose.yml
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"          # closed in Step 4, keep true just to register
      ADMIN_TOKEN: "${ADMIN_TOKEN}"
      IP_HEADER: "X-Forwarded-For"     # X-Real-IP if your proxy sends that instead
      LOG_FILE: "/data/vaultwarden.log"
      LOG_LEVEL: "warn"
    volumes:
      - vw-data:/data
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.vw.rule=Host(`vault.example.com`)"
      - "traefik.http.routers.vw.entrypoints=websecure"
      - "traefik.http.routers.vw.tls.certresolver=letsencrypt"
      - "traefik.http.services.vw.loadbalancer.server.port=80"

volumes:
  vw-data:

networks:
  proxy:
    external: true

Zwei Details in dieser Datei sind entscheidend für das Design. Es gibt kein ports:-Mapping. Vaultwarden ist daher nur über Traefik und dessen TLS erreichbar. Das Veröffentlichen des Ports auf dem Host führt dazu, dass der Vault versehentlich über HTTP bereitgestellt wird. Zudem muss DOMAIN die vollständige öffentliche HTTPS-URL sein. Diese URL ist in den Anhänge-Links, WebAuthn 2FA und dem Notifications-Endpoint fest hinterlegt. Ein falscher Wert oder ein HTTP-Wert führt dazu, dass diese Funktionen trotz korrekt geladener Website nicht funktionieren. Das latest-Tag ist eine bewusste Ausnahme von der üblichen Never-latest-Regel. Vaultwarden liefert stabile Releases als einzelnes Rolling-Image aus, wobei :testing der separate Pre-Release-Kanal ist. Aktualisieren Sie daher gezielt und lesen Sie die Release Notes vor dem Pull.

Starten Sie den Container und beobachten Sie das Log:

docker compose up -d
docker compose logs -f vaultwarden

Ein korrekter Start endet mit einer Zeile wie Rocket has launched from http://0.0.0.0:80. Geben Sie Traefik einige Sekunden Zeit, um das Zertifikat abzurufen, und laden Sie dann https://vault.example.com. Sie sollten den Bitwarden Web-Vault mit einem gültigen Schloss-Symbol und ohne Zertifikatswarnung aufrufen können.

Step 3 — a strong ADMIN_TOKEN, and the $$ trap

ADMIN_TOKEN guards /admin, the panel that can read every user and setting on your instance, so treat it like a root password. Two forms work.

The simple form is the random string you already generated with openssl rand -base64 48. Because base64 never contains a $, it drops straight into .env with no escaping.

The hardened form is an Argon2 PHC hash, so the plaintext token is never stored on disk. Generate one against the same image:

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

It prompts twice and prints a string starting $argon2id$v=19$.... Here is the trap that costs people an hour: Docker Compose treats $ as variable interpolation, so you must double every $ to $$ when you paste the hash into the Compose file. Put it directly under environment:, not through .env, and do not wrap it in quotes:

    environment:
      ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$c29tZXNhbHQ$$RdescudvJCsgt3ub+b+dWRWJTmaaJObG

If you leave the single $ signs, Compose warns The "argon2id" variable is not set and blanks the token, and /admin then rejects your correct password. Run docker compose up -d, and keep the plaintext you typed at the prompt in your own password store.

Schritt 4 — Konto registrieren und Zugriff einschränken

Öffnen Sie mit SIGNUPS_ALLOWED: "true" die https://vault.example.com, klicken Sie auf Create account und registrieren Sie sich mit Ihrer E-Mail-Adresse und einem starken Master-Passwort. Dieses Master-Passwort kann niemals wiederhergestellt werden — es gibt keine Reset-Funktion — speichern Sie es daher zuerst an einem sicheren Ort.

Deaktivieren Sie nun die Registrierung. Bearbeiten Sie die Compose-Datei, um die Registrierung zu unterbinden:

      SIGNUPS_ALLOWED: "false"

Wenden Sie die Änderungen mit docker compose up -d erneut an. Dies ist keine kritische Sicherheitsmaßnahme, die aufgeschoben werden kann. Wenn die Registrierung aktiviert bleibt, kann jeder, der die URL findet — und Crawler finden sie —, ein Konto auf Ihrem Server erstellen. Die Benutzer können Ihren Vault nicht lesen, aber sie verbrauchen Ressourcen und machen Ihre private Instanz zu einem öffentlichen Dienst. Ein Anzeichen für eine offene Registrierung ist: /admin listet Konten auf, die Sie nie erstellt haben.

Um später Familienmitglieder oder Teammitglieder hinzuzufügen, ohne die öffentliche Registrierung wieder zu öffnen, nutzen Sie die Schaltfläche Invite User in /admin; dieser Pfad erfordert eine konfigurierte SMTP-Verbindung, damit der Empfänger den Link erhält.

Schritt 5 — Aufruf von /admin

Rufen Sie https://vault.example.com/admin auf und geben Sie das Admin-Token im Klartext ein (die zufällige Zeichenfolge oder das Passwort, das Sie gehasht haben – nicht den Hash selbst). Dort können Sie Benutzer auflisten, Einstellungen anpassen, eine Test-E-Mail senden und einen Datenbank-Snapshot erstellen.

Wenn die Seite 404 Not Found zurückgibt, ist ADMIN_TOKEN leer oder nicht gesetzt. Dies deaktiviert das Panel vollständig – dies ist eine sinnvolle Option, falls Sie das Panel nie benötigen. Wenn die Seite lädt, aber das Token ablehnt, beachten Sie die Falle durch das Escaping von $$ in der untenstehenden Fehlerliste. Token vergessen? Es gibt keine Wiederherstellungsaufforderung; bearbeiten Sie .env oder die Compose-Datei, setzen Sie ein neues Token und docker compose up -d.

Schritt 6 — Verbindung der Bitwarden-Clients herstellen

Jeder offizielle Client kann auf einen selbst gehosteten Server verweisen. Installieren Sie den Bitwarden Desktop-, Mobile- oder Browser-Client aus den regulären Stores — Sie benötigen keinen speziellen Vaultwarden-Build.

Öffnen Sie vor der Anmeldung das Einstellungs-Symbol auf dem Login-Bildschirm (beschriftet mit Self-hosted oder Region → Self-hosted), setzen Sie die Server URL auf https://vault.example.com und speichern Sie die Einstellung. Melden Sie sich anschließend mit der registrierten E-Mail-Adresse und dem Master-Passwort an; der Client sollte die Verbindung sofort herstellen und das Ausfüllen sowie Speichern von Anmeldedaten anbieten.

Falls ein Client This is not a recognized Bitwarden server. You may need to check with your provider or update your server. anzeigt, ist die URL fehlerhaft, verwendet http oder das Zertifikat ist nicht vertrauenswürdig — prüfen Sie zuerst, ob https://vault.example.com korrekt in einem Browser geladen werden kann. Verzögerte Updates auf anderen Geräten liegen an WebSocket-Push-Benachrichtigungen, die weiter unten behandelt werden.

Schritt 7 — ein Fail2ban Jail für den Login-Endpunkt

Vaultwarden protokolliert jeden fehlgeschlagenen Login in der Datei, die durch LOG_FILE festgelegt wurde. Dies ist die Voraussetzung für einen Schutz gegen Brute-Force-Angriffe. Falls Sie Fail2ban noch nicht installiert haben, finden Sie die Installation und Grundlagen im Fail2ban SSH Hardening Guide; hier fügen wir ein Jail für den Vault hinzu.

Finden Sie zuerst den Pfad des Named Volume auf dem Host, damit Fail2ban das Log lesen kann:

docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}'

Dies gibt etwas wie /var/lib/docker/volumes/vaultwarden_vw-data/_data aus; das Log befindet sich unter vaultwarden.log darin. Erstellen Sie den Filter:

# /etc/fail2ban/filter.d/vaultwarden.conf
[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Und das Jail:

# /etc/fail2ban/jail.d/vaultwarden.local
[vaultwarden]
enabled   = true
filter    = vaultwarden
logpath   = /var/lib/docker/volumes/vaultwarden_vw-data/_data/vaultwarden.log
banaction = iptables-allports
chain     = DOCKER-USER
maxretry  = 5
findtime  = 600
bantime   = 3600

Laden Sie die Konfiguration mit sudo systemctl restart fail2ban neu und bestätigen Sie dies mit sudo fail2ban-client status vaultwarden.

Drei Docker-Details entscheiden über den Erfolg des Schutzes. Erstens: Wenn das Log bei jedem fehlgeschlagenen Versuch IP: 127.0.0.1 oder die IP-Adresse Ihres Proxys anzeigt, wird Vaultwarden den Proxy sperren. Setzen Sie IP_HEADER auf den Header, den Ihr Proxy tatsächlich sendet (X-Forwarded-For für Traefik, X-Real-IP für den obigen nginx-Block, CF-Connecting-IP bei Cloudflare). Zweitens: Die korrekte iptables-Chain hängt von Ihrem Proxy ab. Wenn Traefik als Container mit veröffentlichten Ports läuft, durchläuft der Traffic den Docker FORWARD Pfad. Die Sperre muss daher in DOCKER-USER erfolgen, wie oben beschrieben. Wenn Sie jedoch die Host-nginx-Option aus Schritt 1 gewählt haben, enden die Verbindungen in der INPUT Chain des Hosts auf dem Host. Eine DOCKER-USER Sperre erkennt diese Verbindungen nicht. Löschen Sie in diesem Fall die Zeile chain = DOCKER-USER, damit Fail2ban die Standard-INPUT Chain verwendet. Drittens: Verwenden Sie banaction = iptables-allports anstelle des portbasierten Standards. Dieses Jail definiert keinen Port. Eine Sperre aller Ports in DOCKER-USER blockiert den Verursacher zuverlässig für alle veröffentlichten Dienste auf dem System.

Schritt 8 — Sichern Sie den Vault, dann führen Sie die Wiederherstellung durch

Das vw-data-Volume ist Ihr Passwortmanager. Es enthält db.sqlite3 (jeden Eintrag), die Verzeichnisse attachments/ und sends/, die rsa_key.*-Dateien zur Signierung von Login-Sitzungen sowie config.json aus dem Admin-Panel. Ein Backup, das einen dieser Teile auslässt, schlägt im Ernstfall fehl.

Das Kopieren von db.sqlite3 während Schreibvorgängen durch Vaultwarden kann zu korrupten Dateien führen. Erstellen Sie daher einen Cold Snapshot — die Ausfallzeit beträgt nur wenige Sekunden:

#!/usr/bin/env bash
set -euo pipefail
STAMP=$(date +%F)
DEST=/root/vw-backups
VOL=$(docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}')
mkdir -p "$DEST"
docker compose -f /opt/vaultwarden/docker-compose.yml stop vaultwarden
tar czf "$DEST/vw-$STAMP.tgz" -C "$VOL" .
docker compose -f /opt/vaultwarden/docker-compose.yml start vaultwarden

Richten Sie einen täglichen Cronjob ein, um die .tgz zu sichern, und übertragen Sie diese vom Server weg — ein Backup, das nur auf dem zu schützenden Server existiert, ist kein Backup. Die sauberste Methode ist ein nächtliches restic-Backup auf einen anderen Server oder Object Storage, da dies das Archiv verschlüsselt und redundante Snapshots dedupliziert. Die Schaltfläche Backup Database im Admin-Panel erstellt einen schnellen Snapshot der SQLite-Datei, lässt jedoch Anhänge und Keys aus.

Nun folgt der entscheidende Schritt, um ein echtes Backup von einem bloßen Versuch zu unterscheiden — führen Sie die Wiederherstellung einmalig durch, um die Funktion zu beweisen:

mkdir -p /tmp/vw-restore
tar xzf /root/vw-backups/vw-2026-07-15.tgz -C /tmp/vw-restore
docker run --rm -p 127.0.0.1:8888:80 -v /tmp/vw-restore:/data vaultwarden/server

Verbinden Sie sich von Ihrem Laptop via ssh -L 8888:127.0.0.1:8888 you@your-vps mit dem Server und öffnen Sie http://localhost:8888. Da localhost eine sichere Umgebung ist, ist crypto.subtle verfügbar und der Vault wird über Plain HTTP entschlüsselt — dies ist die einzige erlaubte Ausnahme. Melden Sie sich mit Ihrem Master-Passwort an und prüfen Sie, ob alle Einträge vorhanden sind. Wenn ja, wurden die Datenbank, die RSA-Keys und das Master-Passwort korrekt übertragen. Sie können nun einen neuen VPS in wenigen Minuten neu aufsetzen. Stoppen Sie den Container mit Ctrl-C und löschen Sie /tmp/vw-restore.

Fehlerursachen und die entsprechenden Meldungen

Cannot read properties of undefined (reading 'importKey') in der Browser-Konsole. Der Vault wurde über http geladen, daher ist crypto.subtle undefiniert; der Zugriff ist nur über https:// möglich. Konfigurieren Sie eine HTTP-zu-HTTPS-Weiterleitung am Proxy.

This is not a recognized Bitwarden server... in einem Client. Die Server-URL ist http, falsch geschrieben oder das Zertifikat ist nicht vertrauenswürdig; prüfen Sie, ob https://vault.example.com ein gültiges Schloss anzeigt, und geben Sie die URL anschließend in den Self-Hosted-Einstellungen des Clients erneut ein.

/admin lehnt das korrekte Passwort ab. Der Argon2-Hash hat seine Escaping-Formatierung verloren — jeder $ muss in Compose $$ sein — oder Sie haben den Hash anstatt des Klartextes eingegeben.

Langsame geräteübergreifende Synchronisation; die Konsole zeigt WebSocket connection to 'wss://vault.example.com/notifications/hub' failed. Der Proxy leitet die Upgrade/Connection-Header nicht weiter; Traefik erledigt dies automatisch, nginx benötigt die zwei Upgrade-Zeilen aus Schritt 1. Der Vault funktioniert weiterhin, die Synchronisation erfolgt jedoch erst beim Öffnen. Der alte dedizierte Port 3012 existiert seit v1.31.0 nicht mehr, daher ist keine separate WebSocket-Route erforderlich.

Fail2ban meldet eine Sperre, aber der Angreifer stellt weiterhin Verbindungen her. Es wird 127.0.0.1 gesperrt, weil IP_HEADER falsch konfiguriert ist, oder die Sperre befindet sich in der falschen iptables-Chain — setzen Sie chain = DOCKER-USER und banaction = iptables-allports.

Upgrades

Laden Sie das neue Image herunter und erstellen Sie den Container neu; das benannte Volume und alle Daten bleiben erhalten:

docker compose pull
docker compose up -d

Vaultwarden veröffentlicht häufig neue Versionen. Verfolgen Sie die Release Notes des Projekts, anstatt eine Patch-Version festzulegen, da einige Versionen Hinweise zu Datenbank-Migrationen enthalten. Erstellen Sie vor jedem größeren Update ein neues Backup; Sie können eine Wiederherstellung durch das Entpacken des tarball in ein neues Volume durchführen.

FAQ

Ist Vaultwarden dasselbe wie Bitwarden?

Es handelt sich um einen kompatiblen, unabhängigen Server, nicht um den offiziellen. Vaultwarden implementiert die Bitwarden Server-API in Rust neu. Daher funktionieren alle offiziellen Desktop-, Mobile-, Browser- und CLI-Clients damit bei deutlich geringerem Ressourcenverbrauch. Das Vault-Format ist identisch, sodass eine Migration durch Export und Import in beide Richtungen möglich ist.

Benötige ich zwingend HTTPS oder kann ich es über http in meinem LAN betreiben?

Außer für einen localhost Test ist HTTPS erforderlich. Der Bitwarden Web-Vault und die Extensions nutzen die Web Crypto API des Browsers. Diese ist nur in einem sicheren Kontext verfügbar. Über unverschlüsseltes http gibt der Client Cannot read properties of undefined aus und verhindert den Login. Die einzige funktionierende http-Adresse ist http://localhost. Aus diesem Grund nutzt der Restore-Test in Schritt 8 einen SSH-Tunnel.

Wie verhindere ich, dass sich Fremde auf meinem Server registrieren?

Setzen Sie SIGNUPS_ALLOWED: "false" in der Compose-Datei und führen Sie docker compose up -d direkt nach der Erstellung Ihres eigenen Kontos aus. Laden Sie ab diesem Zeitpunkt neue Personen über die Schaltfläche Invite User in /admin ein. Hierfür muss SMTP konfiguriert sein, damit die Einladungslinks versendet werden können. Überprüfen Sie regelmäßig die Liste der Admin-Benutzer, um sicherzustellen, dass keine unerwarteten Konten erstellt wurden.

Wie erstelle ich ein Backup meines Vaultwarden-Vaults?

Stoppen Sie kurzzeitig den Container und archivieren Sie das gesamte vw-data Volume — db.sqlite3, attachments/, sends/, config.json und die rsa_key.* Dateien. Kopieren Sie das Archiv anschließend vom Server weg, idealerweise über einen nächtlichen cron. Das Kopieren der aktiven SQLite-Datei während des Serverbetriebs kann zu einem korrupten Snapshot führen; führen Sie den Backup-Vorgang daher im Offline-Modus durch. Wichtig ist, das Backup einmal in einem Test-Container wiederherzustellen und den Login zu prüfen. Nur so stellen Sie sicher, dass das Backup funktioniert, bevor Sie sich darauf verlassen.

Ist das Self-Hosting meiner Passwörter tatsächlich sicher?

Ja, wenn Sie die drei in diesem Guide behandelten Punkte umsetzen: echtes HTTPS, deaktivierte Registrierung mit einem starken Admin-Token und getestete Backups. Ihr Vault wird clientseitig mit Ihrem Master-Passwort verschlüsselt. Der Server sieht Ihre Passwörter daher niemals im Klartext — ein gestohlener db.sqlite3 ist ohne das Passwort wertlos. Der Nachteil ist, dass das Patchen und die Backups nun in Ihrer Verantwortung liegen. Deshalb sind Fail2ban und das Wiederherstellungstraining hier keine Option, sondern Pflicht.