Keycloak, authentik oder Zitadel auf einem VPS

Welcher SSO-Server passt zu einem VPS

Keycloak, authentik und Zitadel sind selbst gehostete Single-Sign-on-Server (SSO), die häufig genannt werden, wenn ein einziger Login für alle Anwendungen auf dem Server benötigt wird. Auf einem kleinen VPS sind sie nicht austauschbar. authentik ist die sichere Standardwahl für einen Server mit drei oder vier selbst gehosteten Anwendungen, weil nur dieses Produkt von den drei genannten einen Login-Bildschirm vor eine Anwendung schalten kann, die keine eigene Anmeldung unterstützt. Keycloak ist die richtige Wahl, wenn jede zu schützende Anwendung bereits ein Standardprotokoll unterstützt und ausreichend Arbeitsspeicher für eine Java Virtual Machine (JVM) verfügbar ist. Zitadel ist für Entwickler ausgelegt, die ein Produkt über eine API ausliefern. Unter 4 GB würde ich es nicht einsetzen.

Treffen Sie zuerst eine Auswahl und installieren Sie anschließend. Nach der Auswahl beschreibt die praxisnahe authentik-Installation auf einem VPS die Einrichtung Schritt für Schritt.

Wie viel RAM benötigt jede Lösung tatsächlich?

Beginnen Sie mit der Ressourcenuntergrenze. Sie legt die engere Auswahl fest, bevor einzelne Funktionen eine Rolle spielen. Die folgenden Zahlen stammen aus den jeweils veröffentlichten Angaben der Projekte, abgerufen im August 2026. Sie sind Herstellerangaben und keine Ergebnisse eines Lasttests.

[
  {
    "label": "authentik",
    "vendor_min_ram_mb": 2048,
    "base_containers": 3
  },
  {
    "label": "Keycloak",
    "vendor_min_ram_mb": 1250,
    "base_containers": 2
  },
  {
    "label": "Zitadel",
    "vendor_min_ram_mb": 2048,
    "base_containers": 4
  }
]

Auf der Installationsseite von authentik für Docker Compose wird ein „Host mit mindestens 2 CPU-Kernen und 2 GB RAM“ verlangt. Das entspricht 2048 MB. Die veröffentlichte Compose-Datei startet 3 Container: PostgreSQL, den Server und den Worker.

Keycloak veröffentlicht die genaueste Angabe der 3 Lösungen. Im Sizing-Leitfaden steht: „Der grundlegende Speicherbedarf für einen Pod einschließlich Caches für Realm-Daten und 10.000 gecachte Sitzungen beträgt 1250 MB RAM.“ Diese 1250 MB gelten nur für den Java-Prozess, noch ohne die Datenbank. Auf derselben Seite wird erklärt, warum das Containerlimit so wichtig ist: Keycloak verwendet 70 % des Speicherlimits als Heap und benötigt zusätzlich etwa 300 MB Non-Heap-Speicher. Geben Sie dem Container 1 GB, berechnet er einen Heap von etwa 717 MB und benötigt weiterhin diese 300 MB Non-Heap-Speicher. Damit ist das Limit bereits ausgeschöpft, bevor Sitzungsdaten im Cache abgelegt werden.

Auf der Compose-Seite von Zitadel werden ebenfalls 2 GB verlangt, also dieselben 2048 MB. Diese Angabe gilt jedoch für den ersten Start. Maßgeblich ist die Produktionsdokumentation. Der Zitadel-Prozess selbst benötigt „etwa 512 MB RAM und kann mit weniger als einem CPU-Kern betrieben werden“. Die Datenbank ist der aufwendige Teil: „etwa ein CPU-Kern pro 100 Anfragen pro Sekunde (req/s) und 4 GB RAM pro Kern“. Das Hashing von Passwörtern benötigt außerdem „4 verfügbare CPU-Kerne für diesen Zweck“, weil eine Anmeldespitze zu einer hohen CPU-Auslastung führt. Die offizielle v4-Compose-Konfiguration startet 4 Container, bevor Sie weitere hinzufügen: Traefik als Proxy, die Zitadel-API, einen separaten Login-UI-Container und PostgreSQL. Redis und ein OpenTelemetry Collector sind über optionale Compose-Profile verfügbar.

Damit passen Keycloak und authentik auf einen VPS mit 4 GB RAM, und es bleibt noch Speicher für die geschützten Anwendungen. Zitadel startet mit 2 GB, konkurriert danach aber bei jeder Anmeldung mit dem eigenen PostgreSQL um Speicher. Ich würde Zitadel nicht mit weniger als 4 GB betreiben. Auf einem Server, der zusätzlich Anwendungen hostet, würde ich 8 GB einplanen.

Was tatsächlich auf Ihrem Server läuft

authentik besteht aus PostgreSQL und zwei Instanzen desselben Images: einem Server und einem Worker. Der Server beantwortet HTTP-Anfragen und enthält einen integrierten Outpost. Der Worker führt Hintergrundaufgaben wie Verzeichnissynchronisationen und den E-Mail-Versand aus. Die veröffentlichte Installationskonfiguration ist kurz.

wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

Der Server veröffentlicht die Ports 9000 und 9443. Der erste Aufruf von Port 9000 startet den Einrichtungsassistenten. Dort legen Sie das Passwort für den standardmäßigen akadmin-Benutzer fest. Schalten Sie einen Reverse Proxy mit einem gültigen Zertifikat davor, bevor dieser Port aus dem Internet erreichbar ist.

Keycloak besteht aus einem Prozess und einer von Ihnen bereitgestellten Datenbank. Der Schnellstart verwendet einen einzelnen Container.

docker run -p 127.0.0.1:8080:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak:26.7.1 start-dev

start-dev dient zum Ausprobieren. Es läuft mit einer lokalen Entwicklungsdatenbank und ohne TLS (Transport Layer Security). Ein auf diese Weise gestarteter und später entfernter Container nimmt daher auch Ihre Realm-Konfiguration mit. Für den Produktivbetrieb verwenden Sie stattdessen start, eine echte PostgreSQL-Datenbank über KC_DB und einen öffentlichen Hostnamen über KC_HOSTNAME. Der Produktionsleitfaden von Keycloak legt außerdem fest, dass die gesamte Kommunikation zum und vom Server über einen sicheren Kanal erfolgen muss. HTTPS ist dort daher verpflichtend.

Zitadel ist der oben beschriebene Stack aus vier Containern.

mkdir zitadel-compose && cd zitadel-compose
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/docker-compose.yml
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/.env.example
cp .env.example .env
docker compose up -d --wait

Setzen Sie ZITADEL_MASTERKEY in .env vor dem ersten Start. Dabei handelt es sich um den 32 Zeichen langen Schlüssel, den Zitadel zur Verschlüsselung von Geheimnissen in der Datenbank verwendet. Wenn Sie ihn verlieren, verlieren Sie den Zugriff auf diese Geheimnisse. Wenn Sie noch keine Erfahrung mit dem Betrieb solcher Stacks haben, erläutert die Docker-Compose-Grundlagen für einen VPS die Volume- und Restart-Policy-Auswahl, die bestimmt, ob Ihr Identity Provider einen Reboot übersteht.

Welche Protokolle unterstützt jedes der Systeme?

Alle drei unterstützen OpenID Connect (OIDC), die Anmeldeschicht auf Basis von OAuth 2.0, die moderne Anwendungen verwenden. Außerdem unterstützen alle drei SAML 2.0 (Security Assertion Markup Language), den älteren Standard, den Unternehmenssoftware weiterhin ausliefert. Der entscheidende Unterschied betrifft LDAP (Lightweight Directory Access Protocol). Dabei bezeichnet ein Begriff zwei entgegengesetzte Aufgaben.

Aus LDAP lesen bedeutet, dass der SSO-Server Passwörter gegen ein bereits betriebenes Verzeichnis prüft. Keycloak erledigt dies über User Federation. Auch Zitadel unterstützt dies. Die Dokumentation beschreibt, wie Sie „einen LDAP-Server als Identity Provider in ZITADEL verbinden“.

LDAP bereitstellen bedeutet, dass eine Anwendung, die ausschließlich LDAP unterstützt, sich an Ihrem SSO-Server binden kann, als wäre dieser das Verzeichnis. Nur authentik unterstützt dies. Sein LDAP-Provider macht „alle Benutzer und Gruppen in der authentik-Datenbank über das LDAP-Verzeichnis suchbar“. Dafür wird ein dedizierter LDAP-Outpost verwendet. LDAPS ist auf Port 636 verfügbar. Der Zugriff ist schreibgeschützt. Bind- und Suchvorgänge funktionieren, Schreibvorgänge jedoch nicht. Ein einmaliger Code wird mit einem Semikolon an das Passwort angehängt, wie in password;123456. SMS-Authentifikatoren werden während des Bind-Vorgangs nicht unterstützt.

Wenn eine Anwendung in Ihrer Liste ausschließlich LDAP unterstützt, endet der Vergleich an dieser Stelle. Keycloak und Zitadel können diese Bind-Anfrage nicht beantworten. Sie müssten daher neben ihnen ein zweites Verzeichnis betreiben und zwei Benutzerlisten synchron halten.

Was ist mit Anwendungen, die überhaupt keine Anmeldung haben?

Forward Auth ist die Lösung. Das ist ein Fall, mit dem ein Self-Hosting-Server ständig konfrontiert ist. Ihr Reverse Proxy fragt den SSO-Server, ob eine Anfrage zulässig ist, bevor er sie an das Upstream-System weiterleitet. Die dahinterliegende Anwendung erfährt nichts über SSO. Sie erhält Anfragen, die der Proxy bereits geprüft hat, normalerweise mit dem Benutzernamen in einem Header.

Der Proxy Provider von authentik unterstützt dies in drei dokumentierten Modi. Bei „Proxy“ leitet der authentik Outpost den Datenverkehr selbst an die Upstream-Anwendung weiter. Bei „Forward auth (single application)“ bleibt der Datenverkehr bei Ihrem bestehenden Reverse Proxy, während authentik nur die Authentifizierungsprüfung übernimmt. „Forward auth (domain level)“ schützt alle Anwendungen unter einer gemeinsamen übergeordneten Domain mit einem einzigen Provider. Die Einstellung auf Domain-Ebene ist die praktische Variante. Sie hat jedoch eine dokumentierte Einschränkung: Sie „kann keine unterschiedlichen Autorisierungsregeln auf Anwendungsebene für jede geschützte Anwendung erzwingen“. Daher verwenden alle Anwendungen unter dieser Domain denselben Regelsatz.

Keycloak bietet dafür keine eigene Funktion. Der zugehörige Proxy Keycloak Gatekeeper wurde in Louketo Proxy umbenannt und anschließend auf GitHub archiviert. Der letzte Commit stammt aus August 2023. Um eine Anwendung ohne OIDC-Unterstützung zu schützen, führen Sie eine separate Komponente davor aus, normalerweise oauth2-proxy, das auf einen Keycloak-Client verweist. Auch Zitadel bietet keinen eigenen Forward-Auth-Modus. Dort müssen Sie daher ebenfalls eine zusätzliche Komponente installieren, überwachen und aktualisieren.

An diesem zusätzlichen Hop endet die einfache Konfiguration des Reverse Proxys. Lesen Sie daher wie Traefik mehrere Docker-Compose-Anwendungen vorlagert, bevor Sie eine Auth-Middleware darin konfigurieren.

Wie schwierig ist der Upgrade-Pfad?

Im August 2026 lauten die aktuellen Releases Keycloak 26.7.1, authentik 2026.5.6 und Zitadel v4.16.3. Alle drei führen Schema-Migrationen gegen PostgreSQL aus. Damit ändert jedes Upgrade die Datenbank. Sichern Sie die Datenbank jedes Mal vorher. Diese eine Gewohnheit ist wertvoller als jedes Feature in diesem Vergleich.

authentik hat die strengste Regel und formuliert sie eindeutig: „Upgrades müssen der Reihenfolge der Major-Releases folgen. Überspringen Sie keine älteren Major-Versionen direkt zur neuesten Version.“ Wechseln Sie innerhalb jeder Version zunächst auf den neuesten Patchstand, bevor Sie zur nächsten Version wechseln. Außerdem „unterstützt authentik kein Downgrade“. Wenn Sie bei einem Projekt mit kalenderbasierten Versionen ein Jahr zurückliegen, wird aus einem Upgrade eine Kette von Upgrades. Jedes davon umfasst eine eigene Datenbankmigration.

Der Upgrade-Leitfaden von Keycloak gibt eine Reihenfolge vor: Prüfen Sie die Migrationsänderungen seit der vorherigen Version, aktualisieren Sie den Server und aktualisieren Sie anschließend die Adapter. Die Datenbankmigration läuft automatisch. Alternativ können Sie sie exportieren und manuell anwenden. Das ist hilfreich, wenn Sie die Änderung vor ihrer Anwendung prüfen möchten. Der Aufwand bei Keycloak besteht in dieser Prüfung. Die Release Notes enthalten veraltete Funktionen und Verhaltensänderungen, die leicht übersehen werden und deren Fehlen kostspielig sein kann.

Zitadel trennt die Init- und Setup-Phasen vom laufenden Server. Die Dokumentation für den Produktivbetrieb empfiehlt, diese Phasen getrennt zu halten, damit die Skalierung die Einrichtung nicht wiederholt. Auf einem einzelnen VPS bedeutet das meist, dass der Setup-Schritt abgeschlossen sein muss, bevor die API einen fehlerfreien Zustand meldet. Deshalb enthält die Compose-Datei Health Checks, und der Startbefehl verwendet --wait.

Für wen die einzelnen Projekte entwickelt wurden und wo ihre Grenzen liegen

Keycloak ist der Identity-Server von Red Hat. Er richtet sich an Organisationen mit Realms, Gruppen, Rollen-Mappings und einem vorhandenen Unternehmensverzeichnis. Von den drei Projekten setzt er die Standards am vollständigsten um. Auf einem 2-GB-VPS mit vier selbst gehosteten Anwendungen ist er jedoch ungeeignet, wenn die Hälfte davon OIDC nicht unterstützt. Die JVM benötigt 1250 MB. Sie müssen ein für Unternehmen entwickeltes Realm-Modell erlernen. Für die Anwendungen, die Sie tatsächlich absichern wollten, müssen Sie trotzdem noch oauth2-proxy installieren.

authentik richtet sich an Self-Hosting-Nutzer. Das zeigt bereits die Funktionsliste. Es unterstützt Forward Auth und stellt einen LDAP-Provider bereit. Außerdem erstellen Sie Login-Flows in einem visuellen Editor. Grenzen zeigen sich, wenn Sie einen Supportvertrag des Herstellers oder einen Release-Zyklus benötigen, der nicht alle paar Wochen weiterläuft. Kalenderbasierte Versionierung ohne Downgrade-Pfad und ohne das Überspringen von Versionen verursacht im Betrieb echten Aufwand. Der Flow-Editor führt ein vollständiges eigenes Modell ein, obwohl Ihr tatsächliches Problem möglicherweise nur aus einem OIDC-Client besteht.

Zitadel richtet sich an Entwickler, die Authentifizierung in ein von ihnen veröffentlichtes Produkt integrieren. Eine leistungsfähige API und Multi-Tenancy gehören zu den zentralen Funktionen. Genau für diesen Anwendungsfall ist es jedoch ungeeignet. Vier Container, keine Forward Auth und eine Datenbank, die mit 4 GB pro Kern dimensioniert wird, passen nicht zu einem einzelnen VPS, hinter dem ein Passwort-Manager und ein Wiki betrieben werden.

Was ich auf einem VPS einsetzen würde und wie

Auf einem VPS mit drei oder vier selbst gehosteten Anwendungen würde ich authentik einsetzen. Alle drei bieten eine Anmeldeseite. Entscheidend ist, dass einige Ihrer Anwendungen niemals OIDC unterstützen werden. authentik löst dieses Problem mit integrierter Forward-Auth, statt dafür eine weitere Komponente daneben zu betreiben.

Wenn möglich, weisen Sie authentik 4 GB Arbeitsspeicher zu. 2 GB reichen nur aus, wenn die daneben laufenden Anwendungen klein sind. Halten Sie Port 9000 vom öffentlichen Internet fern und terminieren Sie TLS an einem vorgeschalteten Reverse Proxy. Erstellen Sie jeden Abend PostgreSQL-Dumps und speichern Sie sie außerhalb des Servers. Ein Identity Provider ohne Backup ist für jede dahinterliegende Anwendung ein Single Point of Failure. Betreiben Sie den Stack unter einem eigenen, nicht privilegierten Account und nicht als root: Einrichten von Benutzern mit geringsten Rechten auf einem VPS beschreibt die dafür erforderlichen Account- und Dateibesitzkonfigurationen.

Verwenden Sie stattdessen Keycloak, wenn jede zu schützende Anwendung bereits OIDC oder SAML unterstützt oder wenn Sie das fein abgestufte Rollenmodell von Keycloak-Realm benötigen. Verwenden Sie Zitadel, wenn Sie eine Anwendung entwickeln, bei der sich andere Personen registrieren sollen, und Sie dessen API und Mandantenmodell benötigen. Keine dieser beiden Lösungen ist für den Fall mit drei Anwendungen auf einem Server gedacht, um den es in diesem Beitrag geht.

Die Fehlerursachen, auf die Sie zuerst stoßen werden

Keycloak hat nach einem Neustart keine Daten. Sie haben es mit start-dev gestartet. Dabei wird eine lokale Entwicklungsdatenbank verwendet. In einem Container ohne Volume werden beim Entfernen des Containers auch die Realm-Daten gelöscht. Wechseln Sie mit KC_DB=postgres zu start und konfigurieren Sie eine echte Datenbank.

Der authentik-Worker-Container verschwindet auf einem kleinen System. Worker und Server verwenden dasselbe Image und führen beide Python-Prozesse aus. Zusätzlich benötigt PostgreSQL einen Teil des Arbeitsspeichers eines 2-GB-Hosts. Führen Sie docker compose ps aus, um zu prüfen, welcher Dienst beendet wurde. Prüfen Sie anschließend dmesg auf eine Beendigung wegen Speichermangels, bevor Sie nach einem Fehler in der Anwendung suchen.

Die Console von Zitadel funktioniert hinter Ihrem Proxy nicht. Die Zitadel-API verwendet gRPC. Dafür muss HTTP/2 bis zum Upstream durchgängig verwendet werden. Auf der Anforderungsseite wird ein Reverse Proxy mit Unterstützung für HTTP/2-Upstream-Verbindungen vorausgesetzt. Dort werden getestete Versionen von Traefik v3.x, NGINX v1.x, Caddy v2.x und Apache httpd 2.4.x genannt. Ein Proxy, der die Upstream-Verbindung auf HTTP/1.1 herabstuft, zeigt zwar eine funktionierende Anmeldeseite. Die Console schlägt jedoch fehl.

Jede Anwendung leitet Sie zurück zur Anmeldeseite. Die öffentliche URL des SSO-Servers und die in der Anwendung konfigurierte URL müssen exakt übereinstimmen. Das gilt auch für Schema und Port. Keycloak bezeichnet diese Einstellung als Hostname. Bei Zitadel heißt sie externe Domain. Stimmen die Werte nicht überein, leitet die Anwendung zu einer Anmeldung weiter, die der Server nicht als eigene erkennt. Der Browser wechselt dadurch fortlaufend zwischen beiden URLs.

FAQ

Welche der drei Lösungen eignet sich für einen 2-GB-VPS?

authentik und Keycloak. authentik nennt als Voraussetzung einen Host mit mindestens 2 CPU-Kernen und 2 GB RAM. Der Dimensionierungsleitfaden von Keycloak setzt den Basisspeicher für den Server ohne Datenbank mit 1250 MB an. Beide Lösungen haben auf 2 GB wenig Reserven, sobald die zu schützenden Anwendungen hinzukommen. 4 GB sind daher die praktikable Untergrenze. Zitadel nennt für den ersten Start 2 GB. Die Produktionsanforderungen sehen jedoch 4 CPU-Kerne für das Hashing von Passwörtern und 4 GB RAM pro Datenbankkern vor. 2 GB reichen daher nicht für einen realen Produktiveinsatz.

Kann Keycloak oder Zitadel eine Anwendung schützen, die keine eigene Anmeldung hat?

Nicht allein. Keine der beiden Lösungen enthält eine Forward-Auth-Komponente. Der alte Begleit-Proxy von Keycloak, Louketo Proxy, ist auf GitHub archiviert. Sein letzter Commit stammt aus August 2023. Er eignet sich daher nicht als Grundlage. Setzen Sie oauth2-proxy oder eine ähnliche Komponente zwischen Ihren Reverse Proxy und die Anwendung. Verweisen Sie diese Komponente auf einen OIDC-Client auf dem SSO-Server. authentik unterstützt dies nativ mit seinem Proxy Provider im Modus „Forward auth (single application)“ oder „Forward auth (domain level)“.

Welche Lösung kann als LDAP-Server für eine Anwendung fungieren, die ausschließlich LDAP unterstützt?

authentik. Sein LDAP Provider läuft auf einem Outpost und macht Benutzer und Gruppen aus authentik über LDAP durchsuchbar. LDAPS ist auf Port 636 verfügbar. Der Zugriff ist schreibgeschützt. Bind- und Suchvorgänge funktionieren, Schreibvorgänge jedoch nicht. Keycloak und Zitadel arbeiten in die andere Richtung: Beide lesen ein vorhandenes LDAP-Verzeichnis als Benutzerquelle ein. Keine der beiden Lösungen beantwortet eine LDAP-Bind-Anfrage einer Anwendung.

Kann ich beim Upgrade von authentik Versionen überspringen?

Nein. Laut Dokumentation müssen Upgrades in der Reihenfolge der Major-Releases erfolgen. Sie sollten nicht direkt von einer älteren Major-Version auf die aktuellste Version wechseln. Aktualisieren Sie zunächst innerhalb jeder Version auf das neueste Patch-Release. Wechseln Sie danach jeweils um eine Version weiter. Sichern Sie PostgreSQL vor jedem Schritt. authentik unterstützt kein Downgrade, und die Migrationen werden nur vorwärts ausgeführt.