Keycloak, authentik of Zitadel op één VPS kiezen
Vergelijk Keycloak, authentik en Zitadel voor hosting op een kleine VPS. Ontdek welk geheugengebruik ze vereisen en welke server legacy applicaties zonder SSO ondersteunt.
Welke SSO-server past op één VPS
Keycloak, authentik en Zitadel zijn de zelfgehoste single sign-on (SSO) servers die steevast worden genoemd wanneer men één login wil voor alle applicaties op een server. Op één kleine VPS zijn ze niet onderling uitwisselbaar. authentik is de veilige standaardkeuze voor een server met drie of vier zelfgehoste applicaties, omdat dit de enige van de drie is die een inlogscherm kan plaatsen voor een applicatie die zelf geen inlogfunctie heeft. Keycloak is de juiste keuze wanneer elke applicatie die u beveiligt al een standaardprotocol ondersteunt en u het geheugen voor een Java virtual machine (JVM) kunt missen. Zitadel is gebouwd voor ontwikkelaars die een product via een API aanbieden, en dit is de optie die ik niet zou proberen met minder dan 4 GB RAM.
Kies eerst, installeer daarna. Zodra u een keuze heeft gemaakt, behandelt de praktische installatie van authentik op een VPS de configuratie stap voor stap.
Hoeveel RAM heeft elk project daadwerkelijk nodig?
Begin bij de minimale systeemeisen, aangezien deze de shortlist bepalen nog voordat er naar functionaliteiten wordt gekeken. De onderstaande cijfers zijn de door de projecten zelf gepubliceerde waarden, geraadpleegd in augustus 2026. Dit zijn richtlijnen van de leverancier, geen resultaten van een belastingtest.
The data behind this chart
[
{
"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
}
]De Docker Compose-installatiepagina van authentik vraagt om "een host met ten minste 2 CPU-cores en 2 GB RAM", wat neerkomt op 2048 MB. Het gepubliceerde compose-bestand draait 3 containers: PostgreSQL, de server en de worker.
Keycloak publiceert het meest specifieke cijfer van de 3. De sizing-handleiding stelt dat "het basisgeheugengebruik voor een Pod, inclusief caches voor Realm-data en 10.000 gecachte sessies, 1250 MB RAM bedraagt". Deze 1250 MB dekken enkel het Java-proces zelf, nog exclusief de database. Dezelfde pagina legt uit waarom de containerlimiet zo belangrijk is: Keycloak reserveert 70% van de geheugenlimiet als heap en gebruikt daarbovenop ongeveer 300 MB aan non-heap geheugen. Als u de container 1 GB toewijst, berekent deze een heap van ongeveer 717 MB, terwijl er nog steeds 300 MB aan non-heap geheugen nodig is; de limiet is dus al verbruikt voordat er enige sessiedata in de cache terechtkomt.
De compose-pagina van Zitadel vraagt eveneens om 2 GB, oftewel 2048 MB, maar dat cijfer geldt voor een eerste opstart. De productiepagina is de relevante bron. Het Zitadel-proces zelf heeft "ongeveer 512 MB RAM nodig en kan functioneren met minder dan één CPU-core". De database is het kostbare onderdeel: "ongeveer één CPU-core per 100 verzoeken per seconde (req/s) en 4 GB RAM per core". Wachtwoord-hashing vereist vervolgens "4 CPU-cores beschikbaar voor dit doel", omdat een piek in het aantal aanmeldingen leidt tot een CPU-belasting. De officiële v4-compose draait 4 containers voordat u iets toevoegt: Traefik als proxy, de Zitadel API, een aparte Login UI-container en PostgreSQL. Redis en een OpenTelemetry-collector bevinden zich achter optionele compose-profielen.
Keycloak en authentik passen dus op een 4 GB VPS, met ruimte over voor de applicaties die u beveiligt. Zitadel start op 2 GB, maar zal bij elke aanmelding strijden met zijn eigen PostgreSQL om het geheugen. Ik zou Zitadel niet draaien met minder dan 4 GB, en op een server die ook andere applicaties host, zou ik de voorkeur geven aan 8 GB.
Wat er daadwerkelijk op uw server draait
authentik bestaat uit PostgreSQL en twee kopieën van één image: een server en een worker. De server beantwoordt HTTP-verzoeken en bevat een ingebouwde outpost. De worker voert achtergrondtaken uit, zoals directory-synchronisaties en e-mailverwerking. De gepubliceerde installatie is beknopt.
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 -dDe server publiceert poort 9000 en 9443. Het eerste bezoek aan poort 9000 start de initiële configuratieprocedure, waarbij u het wachtwoord voor de standaardgebruiker akadmin instelt. Plaats een reverse proxy met een geldig certificaat voor deze poort voordat deze vanaf het internet bereikbaar is.
Keycloak is één proces plus een door u geleverde database. De quickstart bestaat uit één 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-devstart-dev is bedoeld om de software te verkennen. Het draait met een lokale ontwikkeldatabase zonder TLS (transport layer security); een container die op deze manier wordt gestart en later wordt verwijderd, neemt uw realm met zich mee. Voor productie gebruikt u in plaats daarvan start, met een volwaardige PostgreSQL via KC_DB en een publieke hostnaam via KC_HOSTNAME. De productiehandleiding van Keycloak stelt bovendien dat alle communicatie van en naar de server via een beveiligd kanaal moet verlopen, waardoor HTTPS daar niet optioneel is.
Zitadel is de stack van vier containers zoals hierboven beschreven.
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 --waitStel ZITADEL_MASTERKEY in .env in vóór de eerste start. Dit is de 32 tekens lange sleutel die Zitadel gebruikt om geheimen in de database te versleutelen; verlies van deze sleutel betekent dat u de toegang tot die geheimen verliest. Als u nog niet bekend bent met het draaien van dergelijke stacks, behandelt de basisprincipes van Docker Compose voor een VPS de keuzes voor volumes en restart-policies die bepalen of uw identity provider een herstart overleeft.
Welke protocollen ondersteunen ze?
Alle drie ondersteunen OpenID Connect (OIDC), de inloglaag bovenop OAuth 2.0 die moderne applicaties gebruiken, en alle drie ondersteunen SAML 2.0 (security assertion markup language), de oudere standaard die nog steeds door enterprise-software wordt geleverd. Het werkelijke verschil zit in LDAP (lightweight directory access protocol), waarbij één term twee tegenovergestelde functies dekt.
Lezen vanuit LDAP betekent dat de SSO-server wachtwoorden controleert tegen een directory die u al beheert. Keycloak doet dit via user federation. Zitadel doet dit ook: de documentatie beschrijft hoe u "een LDAP-server als identiteitsprovider in ZITADEL verbindt".
LDAP aanbieden betekent dat een applicatie die uitsluitend LDAP spreekt, kan binden aan uw SSO-server alsof het de directory is. Alleen authentik biedt dit. De LDAP-provider maakt "alle gebruikers en groepen in de database van authentik doorzoekbaar via de LDAP-directory" via een speciale LDAP-outpost, waarbij LDAPS beschikbaar is op poort 636. Dit is alleen-lezen, dus bind- en zoekopdrachten werken, maar schrijfacties niet. Een eenmalige code wordt met een puntkomma aan het wachtwoord toegevoegd, zoals in password;123456, en SMS-authenticators worden tijdens het binden niet ondersteund.
Als een applicatie op uw lijst uitsluitend LDAP spreekt, eindigt de vergelijking daar. Keycloak en Zitadel kunnen niet op die bind-aanvraag reageren, waardoor u naast hen een tweede directory zou moeten draaien en twee gebruikerslijsten synchroon zou moeten houden.
Hoe zit het met applicaties zonder inlogfunctie?
Forward auth is de oplossing, en dit is een scenario waar een zelfgehoste server constant mee te maken krijgt. Uw reverse proxy vraagt aan de SSO-server of een verzoek is toegestaan voordat het wordt doorgestuurd naar de upstream-applicatie. De applicatie erachter merkt niets van SSO. Deze ontvangt verzoeken die de proxy al heeft gecontroleerd, meestal met de gebruikersnaam in een header.
De proxy-provider van authentik dekt dit af met drie gedocumenteerde modi. "Proxy" laat de authentik outpost het verkeer zelf naar de upstream-applicatie sturen. "Forward auth (single application)" laat het verkeer bij uw bestaande reverse proxy en gebruikt authentik alleen voor de authenticatiecontrole. "Forward auth (domain level)" beveiligt elke applicatie onder één hoofddomein met één provider. Domain level is de handige optie, maar kent een gedocumenteerde beperking: het "kan geen verschillende autorisatieregels op applicatieniveau afdwingen voor elke beveiligde applicatie", waardoor elke applicatie onder dat domein dezelfde beleidsset deelt.
Keycloak heeft dit niet. De bijbehorende proxy, Keycloak Gatekeeper, werd hernoemd naar Louketo Proxy en vervolgens gearchiveerd op GitHub, met de laatste commit in augustus 2023. Om een applicatie zonder OIDC-ondersteuning te beveiligen, draait u een afzonderlijke component ervoor, meestal oauth2-proxy, gekoppeld aan een Keycloak-client. Zitadel heeft zelf ook geen forward auth-modus, dus het antwoord is daar dezelfde extra component die u moet installeren, monitoren en upgraden.
Die extra stap is waar de configuratie van een reverse proxy niet langer eenvoudig is, dus lees hoe Traefik meerdere Docker Compose-applicaties aanstuurt voordat u er een auth-middleware in integreert.
Hoe problematisch is het upgradepad?
Sinds augustus 2026 zijn de huidige releases Keycloak 26.7.1, authentik 2026.5.6 en Zitadel v4.16.3. Alle drie voeren schema-migraties uit op PostgreSQL, wat betekent dat elke upgrade een wijziging in de database inhoudt. Maak elke keer eerst een back-up van de database. Die ene gewoonte is meer waard dan welke functie in deze vergelijking dan ook.
authentik hanteert de strengste regel en stelt deze duidelijk: "Upgrades moeten de volgorde van de grote releases volgen; sla niet direct een oudere hoofdversie over naar de meest recente versie." U stapt naar de laatste patch binnen elke versie voordat u naar de volgende versie gaat, en "authentik ondersteunt geen downgrades". Als u een jaar achterloopt op een project met kalenderversiebeheer, verandert één upgrade in een hele reeks, elk met zijn eigen database-migratie.
De upgradehandleiding van Keycloak geeft een te volgen volgorde aan: bekijk de migratiewijzigingen van de vorige versie, upgrade de server en upgrade vervolgens de adapters. De database-migratie wordt automatisch uitgevoerd, of u kunt deze exporteren en handmatig toepassen, wat nuttig is wanneer u de wijziging wilt lezen voordat deze wordt doorgevoerd. De kosten bij Keycloak zitten in dat leeswerk. De release notes bevatten afschrijvingen en gedragswijzigingen die gemakkelijk over het hoofd worden gezien en duur zijn om te missen.
Zitadel scheidt de init- en setup-fasen van de draaiende server, en de richtlijnen voor productie raden aan om deze gescheiden te houden zodat schalen het setup-werk niet herhaalt. Op een enkele VPS betekent dit meestal dat de setup-stap voltooid moet zijn voordat de API als gezond wordt gerapporteerd, en daarom bevat het compose-bestand health checks en gebruikt het startcommando --wait.
Voor wie elk project is gebouwd en waar de beperkingen liggen
Keycloak is de identiteitsserver van Red Hat, gebouwd voor organisaties die werken met realms, groepen, roltoewijzingen en een bestaande bedrijfsdirectory. Het is de meest complete implementatie van de drie wat betreft standaarden. Het schiet tekort op een 2 GB VPS die vier zelfgehoste applicaties draait, waarvan de helft geen OIDC-ondersteuning heeft. U verbruikt 1250 MB aan RAM voor de JVM, u moet een realm-model leren dat is ontworpen voor een bedrijf, en u installeert alsnog oauth2-proxy voor de applicaties waar het u daadwerkelijk om te doen was.
authentik is gebouwd voor de self-hosting-doelgroep en de lijst met functies weerspiegelt dat. Het bevat forward auth en een LDAP-provider, en het bouwt inlogflows via een visuele editor. Het schiet tekort wanneer u een supportcontract van een leverancier nodig heeft of een release-cyclus die niet elke paar weken verandert. Kalenderversiebeheer zonder downgradepad en zonder mogelijkheid om versies over te slaan, zorgt voor aanzienlijke operationele last, en de flow-editor is een volledig nieuw model om te leren terwijl uw eigenlijke probleem slechts één OIDC-client betreft.
Zitadel is gebouwd voor ontwikkelaars die authenticatie integreren in een product dat zij uitbrengen, met een sterke API en multi-tenancy als kernfuncties. Het schiet tekort in precies deze situatie. Vier containers, geen forward auth en een database die 4 GB per core vereist, is de verkeerde schaal voor één VPS met enkel een wachtwoordmanager en een wiki erachter.
Wat ik op één VPS zou draaien, en hoe
Draai voor één VPS met drie of vier zelfgehoste applicaties authentik. Alle drie bieden ze een inlogscherm. De doorslaggevende factor is dat sommige van uw applicaties nooit OIDC zullen ondersteunen; authentik lost dit op met ingebouwde forward auth, in plaats van met een extra component ernaast.
Wijs 4 GB toe als dat mogelijk is, en gebruik alleen 2 GB als de applicaties ernaast klein zijn. Houd poort 9000 afgeschermd van het openbare internet en beëindig TLS bij een reverse proxy aan de voorzijde. Maak dagelijks PostgreSQL-dumps en sla deze extern op, aangezien een identity provider zonder back-up een single point of failure vormt voor elke applicatie die erachter draait. Draai de stack onder een toegewezen account zonder privileges in plaats van als root: het instellen van gebruikers met minimale rechten op een VPS behandelt het account- en bestandsbeheer dat hiervoor nodig is.
Kies voor Keycloak wanneer elke applicatie die u beveiligt al OIDC of SAML ondersteunt, of wanneer u het fijnmazige rollenmodel nodig heeft dat Keycloak-realms bieden. Kies voor Zitadel wanneer u een applicatie bouwt waarvoor anderen zich kunnen aanmelden en u de API en het tenant-model daarvan wilt gebruiken. Geen van beide is geschikt voor het scenario met drie applicaties op één server waar dit artikel over gaat.
De storingsmodi die u als eerste zult tegenkomen
Keycloak bevat geen gegevens na een herstart. U heeft het gestart met start-dev, wat een lokale ontwikkeldatabase gebruikt. In een container zonder volume zorgt het verwijderen van de container ervoor dat de realm wordt verwijderd. Stap over op start met KC_DB=postgres gericht op een echte database.
De authentik worker-container verdwijnt op een kleine server. De worker en de server draaien hetzelfde image en bevatten beide Python-processen, terwijl PostgreSQL zijn deel van een 2 GB host opeist. Voer docker compose ps uit om te bevestigen welke service is afgesloten, en controleer vervolgens dmesg op een out-of-memory kill voordat u op zoek gaat naar een bug in de applicatie.
De Console van Zitadel werkt niet achter uw proxy. De Zitadel API gebruikt gRPC, waarvoor HTTP/2 tot aan de upstream vereist is. De vereistenpagina vraagt om een reverse proxy die HTTP/2 upstream-verbindingen ondersteunt en noemt geteste versies van Traefik v3.x, NGINX v1.x, Caddy v2.x en Apache httpd 2.4.x. Een proxy die de upstream-verbinding downgradet naar HTTP/1.1 resulteert in een inlogpagina die wel laadt, maar een Console die faalt.
Elke applicatie stuurt u terug naar het inlogscherm. De publieke URL van de SSO-server en de URL die in de applicatie is geconfigureerd, moeten exact overeenkomen, inclusief het schema en de poort. Keycloak noemt dit de hostname-instelling, Zitadel noemt dit het externe domein. Wanneer deze niet overeenkomen, leidt de applicatie door naar een inlogpagina die de server niet als de zijne herkent, waardoor de browser blijft wisselen tussen beide.
FAQ
Welke van de drie is geschikt voor een 2 GB VPS?
authentik en Keycloak. De opgegeven vereiste voor authentik is een host met minimaal 2 CPU-cores en 2 GB RAM. De sizing-gids van Keycloak stelt het basisgeheugen op 1250 MB voor de server, nog voor de database. Beide zitten krap op 2 GB zodra u de applicaties toevoegt die u wilt beveiligen; beschouw 4 GB daarom als de comfortabele ondergrens. Zitadel noemt 2 GB voor een eerste run, maar de richtlijnen voor productieomgevingen vragen om 4 CPU-cores voor wachtwoord-hashing en 4 GB RAM per database-core. 2 GB is dus geen realistische configuratie voor een productieomgeving.
Kunnen Keycloak of Zitadel een applicatie beveiligen die zelf geen inlogfunctie heeft?
Niet op zichzelf. Geen van beide bevat een forward auth-component. De oude begeleidende proxy van Keycloak, Louketo Proxy, is gearchiveerd op GitHub met de laatste commit in augustus 2023; dit is dus geen basis om op voort te bouwen. U plaatst oauth2-proxy of een vergelijkbare component tussen uw reverse proxy en de applicatie, en verwijst deze naar een OIDC-client op de SSO-server. authentik doet dit standaard met zijn proxy-provider in de modus "Forward auth (single application)" of "Forward auth (domain level)".
Welke kan fungeren als LDAP-server voor een applicatie die alleen LDAP ondersteunt?
authentik. De LDAP-provider draait op een outpost en maakt gebruikers en groepen in authentik doorzoekbaar via LDAP, waarbij LDAPS beschikbaar is op poort 636. Dit is alleen-lezen; bind- en zoekopdrachten werken, maar schrijfopdrachten niet. Keycloak en Zitadel werken in de andere richting: beide lezen vanuit een bestaande LDAP-directory als gebruikersbron, en geen van beide beantwoordt een LDAP-bind van een applicatie.
Kan ik versies overslaan bij het upgraden van authentik?
Nee. De documentatie stelt dat upgrades de volgorde van major releases moeten volgen en dat u niet direct van een oudere major-versie naar de meest recente versie mag springen. Stap eerst over naar de laatste patch-release binnen elke versie en ga daarna stapsgewijs één versie omhoog. Maak voor elke stap een back-up van PostgreSQL, omdat authentik geen downgrades ondersteunt en de migraties alleen voorwaarts kunnen worden uitgevoerd.