Keycloak vs Authentik vs Zitadel: Ipi bora kwa VPS moja?

Ni seva ipi ya SSO inayofaa kwa VPS moja

Keycloak, authentik na Zitadel ni seva za single sign-on (SSO) unazoweza kujiendeshea mwenyewe ambazo hujitokeza kila wakati mtu anapotaka kuingia kwenye programu zote kwenye seva yake kwa akaunti moja. Kwenye VPS moja ndogo, hizi hazibadilishani kiholela. authentik ndiyo chaguo salama la msingi kwa seva inayoendesha programu tatu au nne, kwa sababu ndiyo pekee kati ya hizo tatu inayoweza kuweka ukurasa wa kuingia mbele ya programu ambayo haina mfumo wake wa kuingia. Keycloak ndiyo jibu sahihi wakati kila programu unayolinda tayari inatumia itifaki ya kawaida na unaweza kutenga kumbukumbu (RAM) kwa ajili ya Java virtual machine (JVM). Zitadel imejengwa kwa ajili ya watengenezaji programu wanaotoa bidhaa kupitia API, na hii ndiyo ambayo nisingejaribu kuiendesha kwenye chini ya 4 GB ya RAM.

Chagua kwanza, kisha usakinishe. Mara tu unapochagua, usakinishaji wa authentik kwenye VPS kwa vitendo unaelezea usanidi huo hatua kwa hatua.

Kila moja inahitaji RAM kiasi gani kwa hakika?

Anza na kiwango cha chini cha rasilimali, kwa sababu ndicho huamua orodha fupi kabla ya kipengele chochote. Nambari zilizo hapa chini ni takwimu zilizochapishwa na kila mradi, zilizosomwa mnamo Agosti 2026. Hizi ni mwongozo kutoka kwa watoa huduma, si matokeo ya jaribio la mzigo (load test).

[
  {
    "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
  }
]

Ukurasa wa usakinishaji wa Docker Compose wa authentik unaomba "seva yenye angalau CPU cores 2 na 2 GB ya RAM", ambayo ni 2048 MB, na faili yake ya compose iliyochapishwa huendesha 3 containers: PostgreSQL, seva, na worker.

Keycloak huchapisha takwimu mahususi zaidi ya 3. Mwongozo wake wa ukubwa unasema kuwa "matumizi ya msingi ya kumbukumbu kwa Pod ikijumuisha akiba (caches) ya data ya Realm na sessions 10,000 zilizohifadhiwa ni 1250 MB ya RAM". Hizo 1250 MB hufunika mchakato wa Java pekee, kabla ya database. Ukurasa huohuo unaeleza kwa nini kikomo cha container ni muhimu sana: Keycloak huchukua 70% ya kikomo cha kumbukumbu kama heap na hutumia takriban 300 MB ya kumbukumbu isiyo ya heap juu yake. Ipe container 1 GB na itahesabu heap ya takriban 717 MB huku bado ikihitaji hizo 300 MB za kumbukumbu isiyo ya heap, kwa hivyo kikomo hicho kinakuwa kimetumika kabla ya data yoyote ya session kuingia kwenye cache.

Ukurasa wa compose wa Zitadel pia unaomba 2 GB, sawa na 2048 MB, lakini takwimu hiyo ni kwa ajili ya uendeshaji wa kwanza. Ukurasa wake wa uzalishaji (production) ndio wa kusomwa. Mchakato wa Zitadel wenyewe unahitaji "takriban 512MB ya RAM na unaweza kufanya kazi na chini ya CPU core moja". Database ndiyo sehemu ya gharama: "takriban CPU core moja kwa kila maombi 100 kwa sekunde (req/s) na 4GB ya RAM kwa kila core". Hashing ya nenosiri kisha inahitaji "CPU cores 4 zinazopatikana kwa kusudi hili", kwa sababu ongezeko la ghafla la logins hugeuka kuwa kilele cha matumizi ya CPU. Compose rasmi ya v4 huendesha 4 containers kabla hujaongeza chochote: Traefik kama proxy, Zitadel API, container tofauti ya Login UI, na PostgreSQL. Redis na OpenTelemetry collector hukaa nyuma ya profaili za hiari za compose.

Kwa hivyo Keycloak na authentik vinafaa kwenye VPS ya 4 GB huku kukiwa na nafasi iliyobaki kwa programu unazozilinda. Zitadel itaanza kwenye 2 GB, kisha itashindana na PostgreSQL yake yenyewe kwa kumbukumbu katika kila login. Nisingeendesha Zitadel chini ya 4 GB, na kwenye seva inayohifadhi programu nyingine ningehitaji 8.

Kile ambacho kila moja huendesha kwenye seva yako

authentik ni PostgreSQL pamoja na nakala mbili za image moja, server na worker. Server hujibu maombi ya HTTP na ina outpost iliyopachikwa. Worker huendesha kazi za nyuma kama vile usawazishaji wa directory na barua pepe. Usakinishaji uliotolewa ni mfupi.

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

Server huchapisha port 9000 na 9443. Ziara ya kwanza kwenye port 9000 huendesha mchakato wa awali wa usanidi, ambapo unaweka nenosiri kwa mtumiaji chaguo-msingi wa akadmin. Weka reverse proxy yenye cheti halali mbele yake kabla ya port hiyo kufikiwa kutoka kwenye Internet.

Keycloak ni mchakato mmoja pamoja na database unayotoa. Usakinishaji wa haraka ni container moja.

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 ni kwa ajili ya kuchunguza. Huendesha na database ya ndani ya maendeleo na bila TLS (transport layer security), kwa hivyo container iliyoanzishwa kwa njia hii na baadaye kuondolewa huchukua realm yako pamoja nayo. Uzalishaji (production) unamaanisha start badala yake, ukiwa na PostgreSQL halisi kupitia KC_DB na hostname ya umma kupitia KC_HOSTNAME. Mwongozo wa uzalishaji wa Keycloak pia unasema kuwa mawasiliano yote kwenda na kutoka kwa server yanahitaji njia salama, kwa hivyo HTTPS si ya hiari hapo.

Zitadel ni stack ya container nne iliyoelezwa hapo juu.

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

Weka ZITADEL_MASTERKEY katika .env kabla ya kuanza kwa mara ya kwanza. Ni ufunguo wa herufi 32 ambao Zitadel hutumia kusimba siri katika database, kwa hivyo kuupoteza kunamaanisha kupoteza ufikiaji wa siri hizo. Ikiwa wewe ni mgeni katika kuendesha stack kama hizi, misingi ya Docker Compose kwa VPS inashughulikia chaguzi za volume na restart-policy zinazoamua ikiwa mtoa huduma wako wa utambulisho (identity provider) atadumu baada ya reboot.

Ni itifaki zipi ambazo kila moja inatumia?

Zote tatu hutumia OpenID Connect (OIDC), safu ya kuingia iliyo juu ya OAuth 2.0 ambayo programu za kisasa hutumia, na zote tatu hutumia SAML 2.0 (security assertion markup language), kiwango cha zamani ambacho programu za kibiashara bado hutoa. Mgawanyiko wa kweli ni LDAP (lightweight directory access protocol), ambapo neno moja hufunika kazi mbili tofauti.

Kusoma kutoka LDAP inamaanisha seva ya SSO hukagua nywila dhidi ya saraka unayoiendesha tayari. Keycloak hufanya hivi kupitia user federation. Zitadel pia hufanya hivyo: nyaraka zake zinaelezea jinsi ya "kuunganisha seva ya LDAP kama identity provider ndani ya ZITADEL".

Kutoa huduma ya LDAP inamaanisha programu inayotumia LDAP pekee inaweza kuunganishwa (bind) na seva yako ya SSO kana kwamba ni saraka. Ni authentik pekee inayofanya hivi. LDAP provider wake hufanya "watumiaji na vikundi vyote vilivyomo kwenye hifadhidata ya authentik viweze kutafutwa kupitia saraka ya LDAP" kupitia LDAP outpost maalum, huku LDAPS ikiwa inapatikana kwenye port 636. Ni ya kusoma pekee (read-only), kwa hivyo bind na search hufanya kazi wakati uandishi (writes) haufanyi kazi. Nambari ya matumizi ya mara moja huongezwa kwenye nywila kwa kutumia semicolon, kama ilivyo katika password;123456, na SMS authenticators haziungwi mkono wakati wa bind.

Ikiwa programu moja kwenye orodha yako inatumia LDAP pekee, ulinganisho huishia hapo. Keycloak na Zitadel haziwezi kujibu bind hiyo, kwa hivyo utahitaji kuendesha saraka ya pili kando yao na kuweka orodha mbili za watumiaji zikiwa zimesawazishwa (sync).

Vipi kuhusu programu zisizo na mfumo wa kuingia (login)?

Forward auth ndiyo jibu, na hili ni jambo ambalo seva ya self-hosted hukutana nalo mara kwa mara. Reverse proxy yako huuliza seva ya SSO kama ombi linaruhusiwa kabla ya kulipeleka kwenye huduma ya ndani (upstream). Programu iliyo nyuma ya proxy haijui chochote kuhusu SSO. Inapokea maombi ambayo proxy imeshayathibitisha, kwa kawaida ikiwa na jina la mtumiaji kwenye header.

Proxy provider ya authentik inashughulikia hili kwa njia tatu zilizoorodheshwa kwenye nyaraka zake. "Proxy" inaruhusu authentik outpost kupitisha trafiki moja kwa moja kwenye programu ya ndani. "Forward auth (single application)" inaiacha trafiki kwenye reverse proxy yako ya sasa na kutumia authentik kwa ajili ya uthibitishaji pekee. "Forward auth (domain level)" inalinda kila programu iliyo chini ya domain moja kuu kwa kutumia provider mmoja. Njia ya domain level ndiyo rahisi zaidi, lakini ina kikomo kilichotajwa: "haiwezi kutekeleza sheria tofauti za idhini (authorization) kwa kila programu inayolindwa," kwa hivyo kila programu chini ya domain hiyo inashiriki sera moja.

Keycloak haina uwezo huu. Proxy yake ya zamani, Keycloak Gatekeeper, ilibadilishwa jina na kuitwa Louketo Proxy kisha ikafungwa kwenye GitHub, ikiwa na commit ya mwisho mnamo Agosti 2023. Ili kulinda programu isiyo na msaada wa OIDC, unaendesha sehemu (component) tofauti mbele yake, kwa kawaida oauth2-proxy, iliyoelekezwa kwenye Keycloak client. Zitadel pia haina mode ya forward auth, kwa hivyo jibu hapo ni kutumia sehemu hiyo ya ziada unayopaswa kuiweka, kuifuatilia, na kuiboresha.

Hatua hiyo ya ziada ndipo usanidi wa reverse proxy unapoacha kuwa rahisi, kwa hivyo soma jinsi Traefik inavyohudumia programu kadhaa za Docker Compose kabla ya kuunganisha auth middleware ndani yake.

Je, njia ya kufanya upgrade ni ngumu kiasi gani?

Kufikia Agosti 2026, matoleo ya sasa ni Keycloak 26.7.1, authentik 2026.5.6, na Zitadel v4.16.3. Zote tatu huendesha schema migrations dhidi ya PostgreSQL, jambo linalomaanisha kila upgrade ni mabadiliko ya database. Hifadhi nakala ya database kwanza, kila wakati. Tabia hiyo moja ina thamani zaidi kuliko kipengele chochote katika ulinganisho huu.

authentik ina sheria kali zaidi na inaisema wazi: "Upgrades lazima zifuate mtiririko wa matoleo makuu (major releases); usiruke moja kwa moja kutoka toleo kuu la zamani kwenda toleo la hivi karibuni." Unahamia kwenye patch ya hivi karibuni ndani ya kila toleo kabla ya kupiga hatua kwenda linalofuata, na "authentik haiauni kushusha toleo (downgrading)". Kuachwa nyuma kwa mwaka mmoja kwenye mradi unaotumia mfumo wa kalenda (calendar-versioned) kunageuza upgrade moja kuwa msururu wa upgrades, kila moja ikiwa na migration yake ya database.

Mwongozo wa upgrade wa Keycloak unatoa utaratibu wa kufuata: kagua mabadiliko ya migration kutoka toleo lililopita, fanya upgrade ya seva, kisha fanya upgrade ya adapters. Migration ya database huendeshwa kiotomatiki, au unaweza kui-export na kuitekeleza kwa mkono, jambo ambalo ni muhimu unapopenda kusoma mabadiliko kabla hayajafanyika. Gharama ya Keycloak ni usomaji huo. Maelezo yake ya toleo (release notes) hubeba mambo yaliyopitwa na wakati (deprecations) na mabadiliko ya tabia ambayo ni rahisi kuyaruka na ni ghali kuyakosa.

Zitadel hutenganisha hatua zake za init na setup kutoka kwa seva inayofanya kazi, na mwongozo wake wa production unapendekeza kuziweka zikiwa zimetenganishwa ili scaling isirudie kazi ya setup. Kwenye VPS moja, hii inamaanisha hatua ya setup lazima ikamilike kabla ya API kuripoti kuwa iko sawa (healthy), ndiyo maana faili la compose linakuja na health checks na amri ya kuanza inatumia --wait.

Nani anayelengwa na kila mradi, na wapi kila mmoja anaposhindwa

Keycloak ni seva ya utambulisho ya Red Hat, iliyoundwa kwa ajili ya mashirika yenye realms, vikundi, ramani za majukumu (role mappings) na saraka ya shirika iliyopo. Hii ndiyo utekelezaji kamili zaidi wa viwango kati ya hizo tatu. Inashindwa kwenye VPS ya 2 GB inayoendesha programu nne za self-hosted ambapo nusu yake haina msaada wa OIDC. Unatumia 1250 MB kwa ajili ya JVM, unajifunza mfano wa realm ulioundwa kwa ajili ya kampuni, na bado unaishia kusakinisha oauth2-proxy kwa ajili ya programu ulizozihitaji kweli.

authentik imeundwa kwa ajili ya hadhira ya self-hosting, na orodha ya vipengele inaonyesha hilo. Inakuja na forward auth na LDAP provider, na inajenga mtiririko wa kuingia (login flows) katika kihariri cha picha. Inashindwa pale unapohitaji mkataba wa msaada wa muuzaji (vendor support) au mzunguko wa matoleo (release train) ambao haubadiliki kila baada ya wiki chache. Utoaji wa matoleo kwa kutumia kalenda bila njia ya kurudi kwenye toleo la awali (downgrade) na bila kuruka matoleo ni kazi halisi ya kiutendaji, na kihariri cha mtiririko ni mfano mzima wa kujifunza wakati tatizo lako halisi ni OIDC client mmoja tu.

Zitadel imeundwa kwa ajili ya watengenezaji wanaoweka uthibitishaji ndani ya bidhaa wanayotoa, ikiwa na API imara na multi-tenancy kama vipengele vya msingi. Inashindwa katika hali hii hasa. Kontena nne, hakuna forward auth, na database yenye ukubwa wa 4 GB kwa kila core ni umbo lisilofaa kwa VPS moja yenye password manager na wiki nyuma yake.

Nini nitakachokiendesha kwenye VPS moja, na jinsi ya kukifanya

Kwa VPS moja yenye programu tatu au nne unazojiendeshea mwenyewe, tumia authentik. Zote tatu zinakupa skrini ya kuingia (login screen). Sababu ya msingi ni kwamba baadhi ya programu zako hazitawahi kutumia OIDC, na authentik inatatua hilo kwa kutumia forward auth iliyojengwa ndani badala ya kuongeza sehemu nyingine kando yake.

Ipe 4 GB ya RAM ikiwezekana, na 2 GB tu ikiwa programu nyingine zilizo kando yake ni ndogo. Usiweke port 9000 kwenye Internet ya umma na fanya TLS termination kwenye reverse proxy iliyo mbele yake. Hifadhi nakala za PostgreSQL kila usiku na uzihifadhi nje ya seva hiyo, kwa sababu mtoa huduma wa utambulisho (identity provider) asiye na backup ni hatari ya kufeli kwa kila programu iliyo nyuma yake. Endesha stack hii kama akaunti maalum isiyo na upendeleo (unprivileged account) badala ya kutumia root: kuweka watumiaji wenye upendeleo mdogo kwenye VPS inaelezea akaunti na umiliki wa faili unaohitajika kwa hili.

Chagua Keycloak badala yake wakati kila programu unayolinda tayari inatumia OIDC au SAML, au unapohitaji mfumo wa majukumu (role model) wa kina unaotolewa na realms za Keycloak. Chagua Zitadel unapojenga programu kwa ajili ya watu wengine kujiunga na unapotaka API yake na mfumo wake wa wapangaji (tenant model). Hakuna kati ya hizo inayofaa kwa hali ya programu tatu kwenye seva moja ambayo makala hii inahusu.

Aina za hitilafu utakazokutana nazo kwanza

Keycloak haina data baada ya kuanzishwa upya. Uliianzisha kwa kutumia start-dev, ambayo hutumia database ya ndani ya maendeleo. Katika container isiyo na volume, kuondoa container hiyo hufuta realm yote. Hamia kwenye start ukiwa na KC_DB=postgres iliyoelekezwa kwenye database halisi.

Container ya mfanyakazi wa authentik hupotea kwenye seva ndogo. Mfanyakazi na seva huendesha image moja na zote mbili huendesha michakato ya Python, na PostgreSQL inahitaji sehemu yake ya rasilimali kutoka kwa seva yenye 2 GB. Tekeleza docker compose ps ili kuthibitisha ni huduma ipi iliyositishwa, kisha kagua dmesg kwa ajili ya tukio la out-of-memory kill kabla ya kuanza kutafuta hitilafu kwenye programu yenyewe.

Console ya Zitadel haifanyi kazi nyuma ya proxy yako. API ya Zitadel hutumia gRPC, ambayo inahitaji HTTP/2 hadi kwenye upstream. Ukurasa wa mahitaji unaelekeza kutumia reverse proxy inayounga mkono miunganisho ya HTTP/2 ya upstream na kutaja matoleo yaliyojaribiwa ya Traefik v3.x, NGINX v1.x, Caddy v2.x na Apache httpd 2.4.x. Proxy inayoshusha muunganisho wa upstream hadi HTTP/1.1 itakupa ukurasa wa kuingia unaopakia lakini Console itashindwa kufanya kazi.

Kila programu inakurudisha kwenye ukurasa wa kuingia. URL ya umma ya seva ya SSO na URL iliyosanidiwa kwenye programu lazima zilingane kikamilifu, ikijumuisha scheme na port. Keycloak inaita hii hostname setting, Zitadel inaita external domain. Pale zinapokosa kulingana, programu huelekeza kwenye ukurasa wa kuingia ambao seva hauitambui kama wake, na kivinjari huanza kuruka kati ya kurasa hizo mbili.

FAQ

Ni ipi kati ya hizo tatu inafaa kwa VPS ya 2 GB?

authentik na Keycloak. Mahitaji yaliyotajwa ya authentik ni seva yenye angalau CPU cores 2 na 2 GB ya RAM, na mwongozo wa ukubwa wa Keycloak unaweka kumbukumbu ya msingi kuwa 1250 MB kwa seva kabla ya database yake. Zote mbili zinabana kwenye 2 GB pindi unapoongeza programu unazozilinda, kwa hivyo chukulia 4 GB kama kiwango cha chini cha starehe. Zitadel inataja 2 GB kwa jaribio la kwanza, lakini mwongozo wake wa uzalishaji (production) unahitaji CPU cores 4 kwa ajili ya hashing ya nenosiri na 4 GB ya RAM kwa kila core ya database, kwa hivyo 2 GB si usanidi halisi wa uzalishaji.

Je, Keycloak au Zitadel inaweza kulinda programu isiyo na mfumo wake wa kuingia (login)?

Haziwezi zenyewe. Hakuna kati yao inayokuja na sehemu ya forward auth. Proxy ya zamani ya Keycloak, Louketo Proxy, imehifadhiwa kwenye GitHub na commit yake ya mwisho ilikuwa Agosti 2023, kwa hivyo si kitu cha kutegemea. Unaweka oauth2-proxy au sehemu inayofanana na hiyo kati ya reverse proxy yako na programu, kisha unaielekeza kwenye OIDC client iliyo kwenye SSO server. authentik hufanya hivi kiasili kupitia proxy provider yake katika hali ya "Forward auth (single application)" au "Forward auth (domain level)".

Ni ipi inaweza kufanya kazi kama LDAP server kwa programu inayozungumza LDAP pekee?

authentik. LDAP provider yake huendeshwa kwenye outpost na kufanya watumiaji na vikundi vilivyomo kwenye authentik viweze kutafutika kupitia LDAP, huku LDAPS ikipatikana kwenye port 636. Hii ni ya kusoma pekee (read-only), kwa hivyo bind na search hufanya kazi wakati uandishi (writes) haufanyi kazi. Keycloak na Zitadel huenda upande mwingine: zote mbili husoma kutoka kwenye LDAP directory iliyopo kama chanzo cha watumiaji, na hakuna inayojibu LDAP bind kutoka kwa programu.

Je, ninaweza kuruka matoleo (versions) wakati wa kuboresha (upgrade) authentik?

Hapana. Nyaraka zinaeleza kuwa uboreshaji lazima ufuate mfululizo wa matoleo makuu (major releases), na kwamba hupaswi kuruka kutoka toleo kuu la zamani moja kwa moja hadi la hivi karibuni. Hamia kwenye toleo la hivi karibuni la patch ndani ya kila toleo kwanza, kisha panda toleo moja baada ya lingine. Hifadhi nakala (backup) ya PostgreSQL kabla ya kila hatua, kwa sababu authentik haiauni kurejea toleo la nyuma (downgrading) na migrations huenda mbele pekee.