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 dem Ressourcenminimum. Es entscheidet über die engere Auswahl, bevor Funktionen eine Rolle spielen. Die folgenden Zahlen stammen aus den jeweils veröffentlichten Angaben der Projekte, Stand Oktober 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
  }
]

Die Docker-Compose-Installationsseite von authentik fordert „einen Host mit mindestens 2 CPU-Kernen und 2 GB RAM“. Das entspricht 2048 MB. Die veröffentlichte Compose-Datei startet 3 Container: PostgreSQL, den Server und den Worker. Dieser Host-Wert muss alle drei Komponenten einschließlich der Datenbank abdecken.

Keycloak veröffentlicht den genauesten Wert der 3 Lösungen. Der Sizing-Leitfaden gibt an: „Der grundlegende Speicherbedarf eines Pods einschließlich Caches für Realm-Daten und 10.000 gecachter Sessions beträgt 1250 MB RAM.“ Diese 1250 MB gelten für den Keycloak-Server mit diesen Caches. Der Leitfaden dimensioniert die Datenbank separat. PostgreSQL benötigt daher zusätzlich eigenen Speicher. Auf derselben Seite wird erklärt, warum das Containerlimit so wichtig ist: Keycloak verwendet 70 % des Speicherlimits als Heap und benötigt zusätzlich ungefähr 300 MB Non-Heap-Speicher. Im Beispiel wird der Basiswert von 1250 MB in ein Speicherlimit von 1360 MB umgerechnet. Bei 1 GB für den Container berechnet Keycloak einen Heap von etwa 717 MB. Zusammen mit den ungefähr 300 MB Non-Heap-Speicher ergibt das insgesamt etwa 1017 MB. Unter dem Limit bleibt damit fast kein Puffer, während der eigene Basiswert des Leitfadens mit Realm-Caches und 10.000 Sessions 1250 MB beträgt.

Auch die Compose-Seite von Zitadel fordert 2 GB, also dieselben 2048 MB. Dieser Wert wird als Voraussetzung für den gesamten Leitfaden genannt, vom Quickstart bis zur Homelab- oder Semi-Production-Phase. Für eine weitergehende Dimensionierung ist die Production-Seite maßgeblich. Der Zitadel-Prozess selbst benötigt „ungefähr 512 MB RAM und kann mit weniger als einem CPU-Kern betrieben werden“. Der größte Speicherbedarf entfällt auf die Datenbank: „etwa ein CPU-Kern pro 100 Requests pro Sekunde (req/s) und 4 GB RAM pro Kern“. Für das Hashing von Passwörtern werden außerdem „4 CPU-Kerne für diesen Zweck“ benötigt, weil eine Anmeldespitze zu einer hohen CPU-Auslastung führt. Die offizielle v4-Compose-Konfiguration startet 4 Container, bevor weitere Komponenten hinzukommen: Traefik als Proxy, die Zitadel-API, einen separaten Login-UI-Container und PostgreSQL. Redis und ein OpenTelemetry Collector werden über optionale Compose-Profile aktiviert.

Keycloak und authentik passen daher auf einen VPS mit 4 GB RAM, sodass noch Speicher für die geschützten Anwendungen verfügbar bleibt. Zitadel startet zwar mit 2 GB, konkurriert dann aber bei jeder Anmeldung mit dem eigenen PostgreSQL-Prozess um den 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 jede Komponente tatsächlich auf Ihrem Server ausführt

authentik besteht aus PostgreSQL und zwei Instanzen desselben Images: einem Server und einem Worker. Der Server beantwortet HTTP-Anfragen und enthält einen eingebetteten Outpost. Der Worker führt Hintergrundaufgaben wie Verzeichnissynchronisierungen 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. Beim ersten Aufruf von Port 9000 wird der Einrichtungsassistent gestartet. 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.8.1 start-dev

start-dev dient zum Erkunden. 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 Ihre Realm-Konfiguration mit. Für den Produktivbetrieb verwenden Sie stattdessen start mit einem echten PostgreSQL über KC_DB und einem öffentlichen Hostnamen über KC_HOSTNAME. Der Produktionsleitfaden von Keycloak schreibt außerdem vor, dass die gesamte Kommunikation zum und vom Server über einen sicheren Kanal erfolgt. HTTPS ist dort daher nicht optional.

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, bevor Sie den Stack zum ersten Mal starten. Dabei handelt es sich um den 32 Zeichen langen Schlüssel, den Zitadel zum Verschlüsseln von Geheimnissen in der Datenbank verwendet. Wenn Sie ihn verlieren, verlieren Sie den Zugriff auf diese Geheimnisse. Wenn Sie noch wenig Erfahrung mit dem Betrieb solcher Stacks haben, erklärt die Grundlagen von Docker Compose für einen VPS die Volume- und Restart-Policy-Entscheidungen, die bestimmen, ob Ihr Identity Provider einen Reboot übersteht.

Welche Protokolle unterstützt jede Lösung?

Alle drei unterstützen OpenID Connect (OIDC), die Anmeldeschicht über 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 gegensätzliche Aufgaben.

LDAP lesen bedeutet, dass der SSO-Server Passwörter gegen ein bereits vorhandenes Verzeichnis prüft. Keycloak erledigt dies über User Federation. Zitadel unterstützt dies ebenfalls. Die Dokumentation beschreibt, wie sich „ein LDAP-Server als Identity Provider in ZITADEL verbinden“ lässt.

LDAP bereitstellen bedeutet, dass eine Anwendung, die ausschließlich LDAP unterstützt, sich an Ihrem SSO-Server binden kann, als wäre er das Verzeichnis. Nur authentik unterstützt dies. Sein LDAP-Provider macht „alle Benutzer und Gruppen in der authentik-Datenbank über das LDAP-Verzeichnis durchsuchbar“. Dafür wird ein dedizierter LDAP-Outpost verwendet. LDAPS ist auf Port 636 verfügbar. Standardmäßig kann ein gebundener Benutzer nur seine eigenen Details und Gruppen durchsuchen. Das Dienstkonto, mit dem sich eine Anwendung bindet, benötigt daher die Berechtigung „Search full LDAP directory“, um alle Benutzer und Gruppen sehen zu können. Die Dokumentation beschreibt nur Bind- und Suchvorgänge, aber keine Schreibvorgänge. Behandeln Sie das Verzeichnis daher als schreibgeschützt. Ein Einmalcode 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 diesen Lösungen ein zweites Verzeichnis betreiben und zwei Benutzerlisten synchron halten.

Apps ohne Login

Forward Auth ist die Lösung. Das ist ein häufiger Fall beim Betrieb eigener Server. Ihr Reverse Proxy fragt den SSO-Server, ob eine Anfrage zulässig ist, bevor er sie an das Backend 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 authentik Proxy Provider unterstützt dies in drei dokumentierten Modi. Bei „Proxy“ lässt der authentik Outpost den Datenverkehr selbst an die Backend-Anwendung weiterleiten. Bei „Forward auth (single application)“ bleibt der Datenverkehr bei Ihrem vorhandenen Reverse Proxy. authentik wird nur für die Authentifizierungsprüfung verwendet. „Forward auth (domain level)“ schützt alle Anwendungen unter einer gemeinsamen übergeordneten Domain mit einem einzigen Provider. Die Domain-Ebene ist die komfortable 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, im November 2020 eingestellt und im Dezember 2020 auf GitHub archiviert. Um eine Anwendung ohne OIDC-Unterstützung zu schützen, führen Sie davor eine separate Komponente aus, normalerweise oauth2-proxy, die auf einen Keycloak-Client verweist. Auch Zitadel verfügt über keinen eigenen Forward-Auth-Modus. Dort benötigen Sie daher ebenfalls eine zusätzliche Komponente, die installiert, überwacht und aktualisiert werden muss.

An diesem zusätzlichen Hop wird die Konfiguration des Reverse Proxys komplexer. Lesen Sie daher wie Traefik mehrere Docker-Compose-Anwendungen bereitstellt, bevor Sie eine Auth-Middleware einbinden.

Wie problematisch ist der Upgrade-Pfad?

Am 25. Oktober 2026 sind Keycloak 26.8.1, authentik 2026.8.5 und Zitadel v4.20.0 die aktuellen Releases. Alle drei führen Schema-Migrationen gegen PostgreSQL aus. Damit ändert jedes Upgrade die Datenbank. Sichern Sie die Datenbank daher jedes Mal vorher. Diese eine Gewohnheit ist mehr wert 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 nicht direkt von einer älteren Major-Version auf die neueste Version.“ Aktualisieren Sie zunächst innerhalb jeder Version auf den neuesten Patchstand, bevor Sie zur nächsten Version wechseln. Außerdem „unterstützt authentik kein Downgrade“. Wenn Sie bei einem Projekt mit Kalender-Versionen ein Jahr zurückliegen, wird aus einem Upgrade eine Kette mehrerer Upgrades. Jedes davon bringt eine eigene Datenbankmigration mit.

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 Änderungen 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 bei denen ein Übersehen später erhebliche Probleme verursachen kann.

Zitadel trennt die Init- und Setup-Phasen vom laufenden Server. Die Empfehlungen für den Produktivbetrieb sehen vor, diese Phasen getrennt zu halten, damit eine Skalierung die Setup-Arbeiten nicht wiederholt. Auf einem einzelnen VPS bedeutet das meist, dass der Setup-Schritt abgeschlossen sein muss, bevor die API den Status healthy meldet. Deshalb enthält die Compose-Datei Healthchecks, 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-Zuordnungen und einem vorhandenen Unternehmensverzeichnis. Von den drei Projekten bietet er die vollständigste Standardimplementierung. Auf einem VPS mit 2 GB RAM, auf dem vier selbst gehostete Anwendungen laufen und die Hälfte davon keine OIDC-Unterstützung bietet, ist er jedoch ungeeignet. Bevor die Datenbank berücksichtigt wird, benötigt der Keycloak-Server 1250 MB. Sie müssen ein Realm-Modell erlernen, das für ein Unternehmen konzipiert ist, und installieren anschließend trotzdem oauth2-proxy für die Anwendungen, die Sie tatsächlich absichern wollten.

authentik richtet sich an die Self-Hosting-Zielgruppe, wie die Funktionsliste zeigt. Es bietet Forward Auth und einen LDAP-Provider und erstellt Login-Flows in einem visuellen Editor. Seine Grenzen zeigen sich, wenn Sie Hersteller-Support ohne Enterprise-Budget oder einen Release-Zyklus benötigen, der nicht alle paar Wochen neue Versionen hervorbringt. Support ist nur mit einem kostenpflichtigen Abonnement erhältlich: Ticket-Support mit Enterprise-Abonnements über $1k und dedizierter Support mit SLAs bei Enterprise Plus, das bei $20k pro Jahr beginnt. Die Kalender-Versionierung ohne Möglichkeit zum Downgrade oder zum Überspringen von Versionen verursacht echten Betriebsaufwand. Außerdem ist der Flow-Editor ein vollständiges Modell, das Sie erlernen müssen, wenn Ihr eigentliches Problem nur ein einzelner OIDC-Client ist.

Zitadel richtet sich an Entwickler, die Authentifizierung in ein von ihnen veröffentlichtes Produkt integrieren. Eine starke API und Multi-Tenancy gehören dabei zu den grundlegenden Funktionen. Genau in diesem Szenario liegen die Grenzen. Vier Container, kein Forward Auth und eine Datenbankgröße von 4 GB pro Core sind für einen einzelnen VPS mit einem Passwort-Manager und einem Wiki dahinter die falsche Architektur.

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 Sizing-Leitfaden von Keycloak veranschlagt für den Server ohne Datenbank 1250 MB Basisspeicher. Mit den zu schützenden Anwendungen sind beide Lösungen auf 2 GB knapp bemessen. Planen Sie daher 4 GB als komfortable Untergrenze ein. Der Compose-Leitfaden von Zitadel nennt ebenfalls 2 GB und beschreibt damit einen Betrieb im Homelab oder in einer semiproduktiven Umgebung. Für den Produktionseinsatz werden jedoch 4 CPU-Kerne für das Hashing von Passwörtern und 4 GB RAM pro Datenbankkern empfohlen. Sobald echter Anmeldeverkehr auftritt, werden 2 GB daher voraussichtlich knapp.

Können Keycloak oder Zitadel eine Anwendung schützen, die keine eigene Anmeldung hat?

Nicht allein. Beide Lösungen liefern keine Forward-Auth-Komponente mit. Der frühere Begleit-Proxy von Keycloak, Louketo Proxy, erreichte im November 2020 sein End of Life. Sein GitHub-Repository ist seit Dezember 2020 archiviert. Er sollte daher nicht mehr als Grundlage verwendet werden. Platzieren Sie oauth2-proxy oder eine ähnliche Komponente zwischen Ihrem Reverse Proxy und der Anwendung. Verweisen Sie diese Komponente auf einen OIDC-Client auf dem SSO-Server. authentik unterstützt dieses Verfahren 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 dienen, die ausschließlich LDAP unterstützt?

authentik. Sein LDAP Provider läuft auf einem Outpost und stellt Benutzer und Gruppen aus authentik über LDAP zur Suche bereit. LDAPS ist auf Port 636 verfügbar. Die Dokumentation beschreibt nur Bind- und Suchvorgänge. Behandeln Sie den Zugriff daher als schreibgeschützt. Keycloak und Zitadel arbeiten in die entgegengesetzte Richtung: Beide lesen Benutzer aus einem vorhandenen LDAP-Verzeichnis. Keine der beiden Lösungen beantwortet einen LDAP-Bind 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. Installieren Sie zunächst innerhalb jeder Version das aktuellste Patch-Release. Wechseln Sie anschließend jeweils um eine Version weiter. Sichern Sie PostgreSQL vor jedem Schritt. authentik unterstützt kein Downgrade, und die Migrationen laufen nur vorwärts.