Passwortmanager selbst hosten: Vaultwarden, KeePass und Bitwarden Cloud im Vergleich

Das Problem: Passwörter als Sammelrisiko

In kleinen Firmen, Vereinen und anderen Organisationen mit fünf bis 50 Mitarbeitern sammeln sich Passwörter auf unübersichtliche Weise. Ein gemeinsamer Mailkonto-Zugang schwebt in einer Exceldatei auf einem geteilten Laufwerk. Der Admin hat den Router-PIN auf einem Post-it. Beim Ausscheiden eines Mitarbeiters werden nicht alle Zugänge zurückgezogen, weil niemand weiß, welche Konten welche Person genutzt hat. Die Situation löst sich nicht von selbst – je größer die Organisation, desto unübersichtlicher wird es.

Dabei gibt es eine einfache Wahrheit: Ein strukturierter Passwortmanager ist keine Komforteinrichtung, sondern die günstigste Gegenmaßnahme gegen den häufigsten Angriffsvektor – gestohlene oder geratenen Zugangsdaten. Die Entscheidung ist nicht, ob man einen benötigt, sondern welchen Ansatz passt: eine Cloud-Lösung von außen, eine selbst gehostete Instanz oder ein lokal arbeitendes Programm.

Dieser Artikel vergleicht die drei gängigen Wege – Bitwarden Cloud, selbst gehosteten Vaultwarden und KeePass – und grenzt sie von rein clientseitigen Lösungen ab, die nach einer Lizenz dann ohne Server laufen. Am Ende steht keine Marketingentscheidung, sondern eine handlungsfähige Einrichtung für Vaultwarden sowie ein kurer Überblick über KeePass-Sync-Varianten und ihre Risiken.

Vergleich: Welche Lösung passt?

Die folgende Tabelle fasst die wesentlichen Unterschiede zusammen. Keine Spalte ist per se besser – jede hat ihr Werkstück.

|---|---|---|---|---|

Die zentrale Unterscheidung: Bei Bitwarden Cloud und Vaultwarden liegt eine zentrale Passwortdatenbank vor, auf die Nutzer zugreifen – mit der Folge, dass ein Administrator Zugänge verwalten, Mitarbeiter hinzufügen und austragen kann. KeePass ist primär eine lokale Datei; Sync ergibt sich aus der Infrastruktur, nicht aus dem Programm selbst. Das macht KeePass für verteilte Teams unhandlich, für einzelne Administratoren mit sichtbaren Sync-Pfaden aber pragmatisch.

Eine wichtige Abgrenzung: Vaultwarden ist eine eigenständige, selbst gehostete Server-Implementierung des Bitwarden-Protokolls. Es ist kein Plugin, kein Skript und kein Kundenportal – es ist der Server, vor dem die Clients authschon. Der Artikel behandelt keinen bestehenden Kundenbereich oder Tooling-Skripte, die Passwörter bei einem Hersteller verwalten; die Entscheidung liegt bei der Organisation.

Vaultwarden selbst stehen: Eine praxisnahe Einrichtung

Vaultwarden läuft in der Regel in Docker. Das folgende docker-compose-Grundgerüst zeigt den Einstieg mit SQLite (einfach, für kleine Umgebungen) und einem Hinweis, wie Postgres dazu kommt.

docker-compose.yml – Grundgerüst (SQLite)


version: "3.8"

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      - DOMAIN=https://vaultwarden.brillianze.de
      - WEBSOCKET_ENABLED=true
      - SIGNUPS_ALLOWED=false
      - ADMIN_TOKEN=ändern!
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:8000:80"

Der Docker-Container speichert seine Daten unter /data. Bei SQLite liegt die Datenbank dort als db.sqlite3. Für den produktiven Einsatz sollte der ADMIN_TOKEN ein zufälliger, langer Wert sein und nicht im Code liegen – im echten Setup besser über eine Umgebungsdatei oder Docker-Secret.

Option mit Postgres statt SQLite

Wenn mehrere Nutzer, höhere Verfügbarkeit oder klarere Backup-Grenzen gewünscht sind, bietet sich Postgres an. Dann fügt man einen zweiten Service hinzu und verweist Vaultwarden auf die Datenbank:


services:
  vaultwarden:
    image: vaultwarden/server:latest
    environment:
      - DOMAIN=https://vaultwarden.brillianze.de
      - DATABASE_URL=postgres://vwuser:passwort@db:5432/vaultwarden
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    environment:
      - POSTGRES_USER=vwuser
      - POSTGRES_PASSWORD=passwort
      - POSTGRES_DB=vaultwarden
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

Frühzeitig Entscheidung treffen: SQLite reicht für viele kleine Firmen; Postgres lohnt sich, wenn man bereits PostgreSQL pflegt, längere Backups oder Wiederherstellungstests plant. Der Wechsel nachträglich ist möglich, erfordert aber ein Datenbank-Migration-Skript – im Zweifel von Anfang an right decision fällen.

Caddy als Reverse Proxy für HTTPS

Ein eigenständiger Vaultwarden ohne TLS ist keine Option, wenn Zugänge über das Internet genutzt werden. Caddy erzeugt automatisch Let's-Encrypt-Zertifikate und leitet die Verbindungen weiter. Eine einfache Caddyfile-Konfiguration:


vaultwarden.brillianze.de {
    reverse_proxy localhost:8000
}

Caddy muss dafür sichtbar nach außen sein (Port 80/443) und die Domain auf den Server zeigen. In einer rein internen Umgebung ohne offizielle Domain lohnt sich ein eigenes Zertifikat oder Caddy mit http-Modus – aber dann kein automatischer TLS.

Erstes Admin-Konto registrieren

Nach dem Start kann sich zunächst jeder registrieren, wenn SIGNUPS_ALLOWED=true ist. In der Praxis setzt man das auf false und erstellt den ersten Administrator über das Admin-Interface: Aufruf von https://vaultwarden.brillianze.de/admin mit dem ADMIN_TOKEN im Header oder als Query-Parameter (je nach Vaultwarden-Version; in neueren Versionen über den Admin-Token als Authorization-Header). Dort erstellt man den ersten Admin-Benutzer. Danach werden weitere Nutzer über die Administrationsoberfläche oder bei aktiviertem Invite-Modus per Einladung eingestellt.

Punkt: Der erste Admin ist die Person, die im Fehlerfall Zugriff auf die Datenbank und die Konfiguration hat. Diese Rolle sollte einer zuverlässigen Person mit Backup-Zugriff zugeordnet sein.

Backup der Datenbank

Beim SQLite-Setup reicht ein kopiertes db.sqlite3 nicht immer, weil die Datei während des Kopierens beschrieben werden kann. Sicherer: Vaultwarden bietet ein Backup-Kommando über die CLI des Containers oder man nutzt ein Skript, das den Container kurz anhält oder ein transaction-angelehntes Dump erstellt. Konkret:


docker exec vaultwarden backup-db

Diese Funktion erstellt ein Backup der SQLite-Datenbank im /data-Verzeichnis (abhängig von der Version). Bei Postgres setzt man auf pg_dump wie in früheren Artikeln beschrieben (z.B. datenbank-backups.md im selben Ordner). Ein Backup-Skript legt Backups an, rotates sie nach sieben Tagen täglich, vier Wochen wöchentlich und zwölf Monate monatlich – sinnvolle Hausregeln für kleine Umgebungen.

Wichtig: Ein Backup ohne getestete Wiederherstellung ist kein Backup. Lies die Checkliste im Artikel datenbank-backups.md für PostgreSQL/MySQL – das Prinzip gilt hier gleich.

KeePass als Alternative: Lokal, flexibel, aber anderweitig Sync-abhängig

KeePass verwaltet Passwörter in einer verschlüsselten .kdbx-Datei. Das Programm selbst hat keine Server-Komponente. Sync bedeutet, dass diese Datei auf mehrere Geräte kommt – mit den üblichen Sync-Methoden.

Drei Sync-Varianten und ihre Risiken

1. Nextcloud (oder ein anderer WebDAV/Cloud-Sync Dienst)

Die .kdbx-Datei liegt in einem Nextcloud-Ordner, der auf allen Geräten synchronisiert wird. Vorteil: Kein eigener Server für den Sync nötig, wenn Nextcloud ohnehin läuft. Risiko: Konflikt, wenn zwei Geräte gleichzeitig schreiben – KeePass versucht, Konflikte aufzulösen, aber keine Garantie auf konsistente Historie. Ein versehentliches Entsperren der Datei ohne Masterpasswort kann den Zugang blockieren.

2. USB-Stick

Die Datei liegt auf einem USB-Stick, der manuell zwischen Geräten getragen wird. Vorteil: Kein Netzwerk-Angriffsfläche für den Sync, volle Kontrolle. Risiko: Verlust des Sticks, falsche Geräte, veraltete Kopien. Kein automatischer Sync – bei fünfzehn Mitarbeitern unmöglich.

3. Git

Die .kdbx-Datei wird in ein Git-Repository committed. Vorteil: Versionshistorie, theoretisch Rückverfolgung. Risiko: Passwortdatei in Git ist eine schlechte Idee, wenn das Repository öffentlich oder unsicher zugänglich ist – auch private Repos haben Zugriffsrisiken. Konflikte beim Merge, große Dateien im History. Für sehr kleine Teams mit sichtbarer Kontrolle theoretisch denkbar, aber nicht die erste Wahl.

Die gemeinsame Lehre: KeePass ist für einzelne Administratoren oder sehr kleine Teams gut, die eine klare Sync-Regel akzeptieren. Für verteilte Teams mit Rollenrechten ist ein zentraler Server (Vaultwarden) meist die bessere Wahl.

Sicherheit: Was kann schiefgehen und was hilft

Konkrete Risiken

1. Server kompromittiert. Wenn der Vaultwarden-Server angegriffen wird, kann ein Angreifer unter Umständen Zugriff auf verschlüsselte Datenbankdumps oder Konfiguration erhalten. Auch wenn die Passwörter verschlüsselt gespeichert sind, kann die Kryptografie bei schwachen Masterpasswörtern ins Wanken geraten.

2. Datenbank-Dump ohne Kontrolle. Ein Backup, das nicht verschlüsselt wird und an einen unsicheren Ort wandert (externe Festplatte, Cloud ohne Verschlüsselung), ist ein Risiko bei Verlust oder Raiden.

3. Fehlendes 2FA für administrative Zugänge. Der Admin-Account ohne Zwei-Faktor-Authentifizierung ist ein Einzelpunkt des Versagens. Auch wenn Clients 2FA nutzen, gehört der Admin-Zugang selbst ins 2FA.

4. Fehlender Master-Passwort-Weg. Wenn der Admin das Masterpasswort verliert oder keinRecovery-Option existiert, sind die Daten ohne Brute-Force nicht mehr zugänglich. Ein dokumentierter, sicherer Wiederherstellungsweg gehört zur Einrichtung.

Gegenmaßnahmen

HTTPS zwingend (Caddy oder anderer Reverse Proxy mit Let's Encrypt).
2FA für alle administrativen Accounts aktivieren, idealerweise mit App oder Hardware-Key.
Backups verschlüsselt ablegen, z.B. mit GPG oder age, und separat vom Server aufbewahren.
Masterpasswort-Richtlinien: starke, einzigartige Passwörter für den Admin-Account; Recovery-Option dokumentiert, aber nicht unsicher abgelegt.
Regelmäßige Wiederherstellungstests – kein Backup ohne Test.
Updates von Vaultwarden und Docker-Basis regelmäßig – Sicherheitslücken in Container Images sind real.

DSGVO und Verantwortung in kleinen Organisationen

Passwortmanager sind keine reine Technik-Entscheidung, sondern berühren personenbezogene Daten (Zugangsdaten zu Diensten, teilweise mit Namen, E-Mails, Metadaten). Für kleine Firmen und Vereine bedeutet das: Klarheit über Rollen, Löschpflichten und Aufbewahrung.

Rollen und Rechte

Vaultwarden erlaubt die Unterscheidung von Administratoren und normalen Nutzern. Administratoren können Organisationen verwalten, Nutzer einladen und entfernen, einen Teil der Konfiguration sehen. Normale Nutzer haben Zugriff auf ihre eigenen Vault-Einträge. In der Praxis sollte der Admin-Zugang auf ein oder zwei Personen beschränkt sein, nicht auf alle IT-Berechtigten ohne Unterscheidung.

Löschpflichten und Aufbewahrung

Wenn ein Mitarbeiter ausscheidet, sollten seine Zugänge entfernt oder übertragen werden, soweit keine gesetzlichen Aufbewahrungspflichten entgegenstehen. Das bedeutet: Admin entfernt den Nutzer aus Vaultwarden, überprüft, ob gemeinsame Organisationszugänge übernommen sind, und löscht die persönliche Datenbank des Ausgeschiedenen, wenn dies vereinbart ist. Eine Regel im Unternehmen hilft: "Wer geht, dessen Zugänge werden innerhalb von zwei Werktagen überprüft und bereinigt."

Bei KeePass liegt die Verantwortung bei der Person oder dem Sync-Ziel, das die Datei hält – eine explizite Übergaberegel ist hier wichtiger als bei einem zentralen Server.

Dokumentation

Der Einsatz eines Passwortmanagers sollte dokumentiert sein: Welche Lösung, wer hat Admin-Zugang, wo sind die Backups, wie erfolgt die Wiederherstellung, welche Rollen gibt es. Diese Dokumentation gehört in eine interne Sicherheitsdokumentation, nicht notwendigerweise öffentlich.

Häufige Fehler – drei realistische Beispiele

1. "Wir sichern die SQLite-Datei mit rsync." Die SQLite-Datei wird waehrend des Kopiervorgangs beschrieben; das Backup ist inkonsistent. Bei Wiederherstellung meldet Vaultwarden dann Fehler oder verliert Daten. Lösung: Vaultwarden-eigenes Backup oder ein Dump-Verfahren, nicht simples Dateikopieren unter Last.

2. "Der Admin-Token steht in der compose-Datei im Git-Repo." Der Admin-Token ist der Schlüssel zum Administrationsinterface. Wenn er in einem öffentlichen oder leicht zugänglichen Repository liegt, ist der Schutz wertlos. Lösung: Token in eine Umgebungsdatei, Docker-Secret oder ein Vault, und das Repository sauber halten.

3. "Wir nutzen KeePass und syncen über Nextcloud – funktioniert schon." Bis zwei Personen gleichzeitig die Datei bearbeiten und ein Konflikt entsteht, mit dem eine Eintrage verlorengehen. Ohne klare Nutzungsregel ("nur eine Person gleichzeitig aktiv") entstehen Datenverluste, die in einem zentralen Server durch Serialisierung vermieden würden.

FAQ

Kann ich Vaultwarden ohne Domain und ohne öffentliches Internet nutzen?

Ja, für rein lokale Umgebungen. Dann muss aber HTTPS anders gelöst werden (selbstsignierte Zertifikate oder lokales PKI wie im BsN-Homelab üblich). Die Clients müssen das Zertifikat vertrauen. Ohne TLS ist die Verbindung unverschlüsselt – für Passwortdaten nicht acceptable.

Ist Vaultwarden dasselbe wie Bitwarden?

Vaultwarden ist eine eigenständige Implementierung des Bitwarden-Protokolls, die sich kompatibel zu den offiziellen Clients verhält. Die Bitwarden-Cloud ist der kommerzielle Dienst von Bitwarden. Beide können die gleichen Clients nutzen; die Daten liegen aber unterschiedlich.

Muss ich Postgres nutzen?

Nein. SQLite reicht für viele kleine Umgebungen. Postgres lohnt sich bei größeren Teams, wenn man bereits PostgreSQL pflegt oder spezielle Backup-/Wiederherstellungsanforderungen hat. Die Entscheidung ist keine Frage der Sicherheit allein, sondern der Wartbarkeit.

Wie speichere ich die 2FA-Codes für den Admin-Zugang?

Am besten mit einer App, die der Administrator ohne den Passwortmanager ausführen kann – oder einem Hardware-Key. Wenn der 2FA-Schlüssel nur im Passwortmanager liegt, ist der Zufall ein Zufall.

Was passiert, wenn ich den Admin-Token verliere?

Ohne den Admin-Token ist der Administrationszugang nicht mehr verfügbar. Ein Wiederherstellungsweg ist über die Datenbank möglich (je nach Version und Konfiguration), aber nicht bequem. Daher: Token sicher ablegen, z.B. im eigenen Passwortmanager für Admin-Tools oder einem separaten, sicheren Vault.

Schluss: Die Entscheidung ist eine Infrastruktur-Entscheidung

Die Wahl eines Passwortmanagers ist weniger eine Entscheidung über ein einzelnes Tool als eine Entscheidung über Datenhoheit, Sync und Verantwortung. Vaultwarden gibt kleine Firmen die volle Kontrolle über die Daten und die Struktur, behält aber die Bekanntheit der Bitwarden-Clients und UI. KeePass ist eine valide Alternative für kleine Teams, die eine lokale Datei und klare Sync-Regeln akzeptieren. Bitwarden Cloud ist der schnellste Einstieg, wenn man keine eigenen Server betreuen will.

Passt man die Einrichtung an die eigene Infrastruktur an – HTTPS, Backup, 2FA, Rollen –, ist ein selbst gehosteter Vaultwarden für viele kleine Unternehmen die vernünftigste Mischung aus Kontrolle und Komfort.

Interne Links zu weiteren Artikeln

[Sicherer Fernzugriff auf den Heimserver] – wie man den Own Server und die Zugänge schützt, bevor Passwörter über das Internet wandern: sicherer-fernzugriff-heimserver.md
[SSO und Benutzerverwaltung selbst gehostet] – wie man zentrale Zugänge für mehrere Dienste einrichtet, damit ein Passwortmanager nicht die einzige Struktur bleibt: sso-und-benutzerverwaltung-selbst-gehostet.md
[Datenbank-Backups richtig planen: PostgreSQL, MySQL und die Container-Falle] – wie man das Backup von Vaultwarden-Datenbanken (besonders Postgres) korrekt und testbar aufsetzt: datenbank-backups.md

Bildvorschlag

Dateiname: images/vaultwarden-admin-dashboard-2026.png
Alt-Text: Screenshot der Vaultwarden-Administrationsoberfläche mit Organisationsübersicht, Nutzerliste und Backup-Status
Zielformat: PNG, max. 1600 px breit, auf 2x für Retina-Schärfe gerendert; Vorschaugröße im Artikel auf 800 px, Klick auf Vollgröße

Hinweis zum Status

Dieser Artikel liegt als Draft vor. Die Veröffentlichung erfolgt erst nach inhaltlicher Prüfung durch Benjamin. Insbesondere die konkreten Befehle (docker-compose, Caddy, Backup-Skripte) sind für eine veröffentlichte Version ggf. an die tatsächliche BsN- oder Kunden-Infrastruktur anzupassen und gegen aktuelle Vaultwarden- und Docker-Versionen zu verifizieren.

Hinweis: Dieser Artikel ist redaktioneller Inhalt und enthält keine Affiliate- oder Partner-Links. Alle Angaben entsprechen dem Stand 2026 und können sich ändern.