Vaultwarden: der Rust-Server für die Bitwarden-Client-API im Selbstbetrieb
Inoffizieller Bitwarden-kompatibler Server, geschrieben in Rust, früher bekannt als bitwarden_rs.
Auf einen Blick
- Was ist das?
- Analyse des Projekts dani-garcia/vaultwarden: Funktionsumfang, containerbasierte Einrichtung, HTTPS-Pflicht für den Web-Tresor und die Supportregeln, die Nutzer kennen sollten.
- Für wen ist es gedacht?
- Vaultwarden eignet sich für alle, die einen Bitwarden-kompatiblen Tresor auf eigener Hardware betreiben wollen, ohne die offizielle Serverinstallation zu fahren, und die Funktionen wie Organizations, Send, FIDO2 oder YubiKey nutzen. Entscheidend ist die Disziplin bei der Einrichtung: HTTPS über Reverse Proxy ist Pflicht für den Web-Tresor, und Fehlermeldungen gehören in die Projekt-Kanäle, nie an den offiziellen Bitwarden-Support.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Rust, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Alternative Serverimplementierung der Bitwarden-Client-API in Rust
Vaultwarden ist eine in Rust geschriebene, alternative Serverimplementierung der Bitwarden-Client-API und arbeitet mit den offiziellen Bitwarden-Clients zusammen, vom Browser bis zum mobilen Gerät. Das README positioniert es für den Selbstbetrieb dort, wo der offizielle Dienst mit seinem Ressourcenhunger ungeeignet erscheint; einen direkten Verbrauchsvergleich beider Server liefert der Text allerdings nicht.
Die Verbreitung ist enorm: Das Repository zählt über 66.000 Sterne und mehr als 3.100 Forks, bei 89 offenen Issues. Lizenz ist AGPL-3.0, Haupt-Branch main, und die Entwicklung lebt: Die Releases 1.37.0 und 1.37.1 erschienen im Juli 2026, 1.37.2 am 22. August 2026. Ein Blick auf diese Taktung zeigt ein Projekt im laufenden Betrieb, keine ausgehungerte Gemeinschaftslösung.
Funktionsumfang: Organizations, Send, FIDO2, YubiKey und Duo
Das README nennt die Implementierung nahezu vollständig und listet die abgedeckten Bereiche einzeln: der persönliche Tresor, Send, Anhänge, Website-Icons und ein persönlicher API-Schlüssel. Organizations bringen Sammlungen, Passwortfreigabe, Mitgliederrollen, Gruppen, Ereignisprotokolle, Admin-Passwort-Reset, Directory Connector und Richtlinien mit.
Bei der Mehrfaktor-Authentifizierung deckt der Server Authenticator-Apps, E-Mail, FIDO2 WebAuthn, YubiKey und Duo ab. Dazu kommen Notfallzugriff, ein eigenes Admin-Backend und ein modifizierter Web-Vault-Client aus dem Repository dani-garcia/bw_web_builds, der in den Container-Images gebündelt mitgeliefert wird. Jeder Funktionsbereich verlinkt auf die offiziellen Bitwarden-Hilfeseiten, was praktisch ist, aber auch zeigt: Wie vollständig jede Einzelfunktion umgesetzt ist, beziffert das README nicht und nennt keine eigenen Testergebnisse.
HTTPS-Pflicht wegen der Web Crypto API und Empfehlung zum Reverse Proxy
Eine harte Voraussetzung steht markant im README: Der Web-Tresor braucht HTTPS und einen sicheren Kontext, weil die Web Crypto API das verlangt. Ohne aktiviertes HTTPS arbeitet die Weboberfläche schlicht nicht. Das Projekt verlinkt ein Wiki-Kapitel zur HTTPS-Aktivierung und empfiehlt zusätzlich den Betrieb hinter einem Reverse Proxy, mit Beispielkonfigurationen im Wiki.
Interessant ist der Hinweis zur Basis: Vaultwarden setzt auf das Rocket-Webframework, das TLS eingebaut unterstützt. Trotzdem lautet die Empfehlung auf Reverse Proxy, also auf eine Konfiguration, bei der ein vorgelagerter Webserver die Verschlüsselung übernimmt. Wer Vaultwarden ins Internet stellt, sollte diese Anordnung als Standard behandeln und nicht die eingebaute TLS-Variante als Ersatz dafür betrachten.
Container-Images auf ghcr.io, docker.io und quay.io
Der empfohlene Installationsweg sind Container-Images, die auf drei Registries gleichzeitig erscheinen: ghcr.io, docker.io und quay.io. Welche Ausgabe für welchen Zweck gedacht ist, erklärt ein Wiki-Artikel zu den Tags. Daneben gibt es gemeinschaftlich gepflegte Pakete, für die das README ausdrücklich warnt, sie könnten hinter der aktuellen Version zurückliegen oder eine abweichende Konfiguration mitbringen. Wer vollständige Kontrolle will, kann den Server laut Wiki auch selbst bauen.
Das CLI-Beispiel zieht vaultwarden/server:latest und startet mit docker run --detach --name vaultwarden, setzt die Umgebungsvariable DOMAIN auf die spätere Serveradresse wie https://vw.domain.tld, bindet /vw-data/ als Datenvolumen ein und veröffentlicht den Port nur lokal über 127.0.0.1:8000:80. Dieselbe Konfiguration geht als compose.yaml mit den Feldern image, environment, volumes und ports; die Datendateien bleiben in beiden Fällen unter /data/ im Container.
Supportregeln: Bugs an das Projekt, nicht an Bitwarden
Eine der wichtigsten Regeln steht als Warnhinweis gleich am Anfang: Bugs und Vorschläge gehören immer zum Vaultwarden-Projekt, egal welcher Client verwendet wird, also egal ob Mobil, Desktop oder Browser. Der offizielle Bitwarden-Support ist für diesen Server ausdrücklich nicht zuständig, weil es sich um eine inoffizielle Implementierung handelt.
Die Kontaktkanäle des Projekts: Matrix-Raum #vaultwarden:matrix.org, GitHub Discussions und die Discourse-Foren unter vaultwarden.discourse.group. Vor einer Fehlermeldung verlangt das README eine Suche im Issue-Tracker und in den Discussions, ob der Fall schon bekannt ist, und die Bestätigung, die neueste Version zu verwenden. Erst dann folgen neue Diskussion oder neues Issue. Diese Trennung schützt beide Seiten: Bitwarden-Inc.-Support wird nicht mit Fremdserver-Problemen belastet, und das Projekt sammelt seine Meldungen an einer Stelle.
Admin-Backend und Web-Vault aus bw_web_builds
Zwei Komponenten unterscheiden den Server von einer nackten API-Implementierung. Das Vaultwarden-Admin-Backend ist eine eigene Verwaltungsoberfläche, deren Aktivierung im Wiki beschrieben ist; sie gehört zu den Funktionen, die der offizielle Server in dieser Form nicht in gleicher Weise anbietet. Der Web-Vault wiederum ist eine modifizierte Fassung des offiziellen Clients und kommt aus dem separaten Repository bw_web_builds.
Der praktische Unterschied liegt in der Lieferung: Die Container-Images bringen diesen angepassten Web-Vault bereits mit, ein separater Download entfällt. Für Betreiber bedeutet das, dass Client- und Serverstand über die Image-Version gekoppelt sind; wer selbst baut, muss den Web-Vault dagegen selbst beschaffen und auf Kompatibilität achten, das README beschreibt diesen Weg nur über die Wiki-Verweise.
Fazit: Reifer Selbstbetrieb-Tresor mit klarer Pflichtenliste
Vaultwarden ist der Standardeinstieg für einen selbst betriebenen Bitwarden-kompatiblen Tresor geworden, und das aus guten Gründen: nahezu vollständige API-Abdeckung inklusive Organizations, Send und fünf Zwei-Faktor-Verfahren, lebhafte Entwicklung mit Releases im Monatsrhythmus, Bündelung des Web-Vaults in den Images und drei offizielle Registry-Quellen. Die AGPL-3.0-Lizenz verlangt, dass Änderungen am Servercode bei netzwerknutzung offengelegt werden, was für private Betriebe meist folgenlos bleibt.
Die Arbeitsliste vor dem Start ist kurz, aber verbindlich: Image aus ghcr.io oder docker.io ziehen, DOMAIN auf die echte HTTPS-Adresse setzen, Datenvolumen für /data/ anlegen, Portbindung auf 127.0.0.1 beschränken und einen Reverse Proxy mit HTTPS davor schalten, wie es die Web-Crypto-Anforderung erzwingt. Wer diese Punkte abarbeitet, hat einen Tresor, der sich wie der offizielle Dienst bedient; wer Support vom Bitwarden-Hersteller erwartet, ist hier falsch, denn genau das schließt das README aus.
Redaktionelles Fazit
Vaultwarden eignet sich für alle, die einen Bitwarden-kompatiblen Tresor auf eigener Hardware betreiben wollen, ohne die offizielle Serverinstallation zu fahren, und die Funktionen wie Organizations, Send, FIDO2 oder YubiKey nutzen. Entscheidend ist die Disziplin bei der Einrichtung: HTTPS über Reverse Proxy ist Pflicht für den Web-Tresor, und Fehlermeldungen gehören in die Projekt-Kanäle, nie an den offiziellen Bitwarden-Support.
Community-Notizen