Keycloak vs authentik vs Zitadel sa isang VPS

Aling SSO server ang angkop sa isang VPS

Ang Keycloak, authentik, at Zitadel ay mga self-hosted single sign-on (SSO) server na karaniwang pinipili kapag kailangan ng iisang login para sa lahat ng app sa server. Sa isang maliit na VPS, hindi sila magkakapareho ng gamit. Ang authentik ang ligtas na default para sa server na nagpapatakbo ng tatlo o apat na self-hosted app, dahil ito lamang sa tatlo ang maaaring maglagay ng login screen sa harap ng app na walang sariling login. Ang Keycloak ang tamang piliin kapag gumagamit na ng standard protocol ang lahat ng app na poprotektahan mo at may sapat na memory para sa Java virtual machine (JVM). Ang Zitadel ay ginawa para sa mga developer na naglalabas ng produkto sa pamamagitan ng API, at hindi ko ito irerekomenda sa server na wala pang 4 GB.

Pumili muna bago mag-install. Kapag nakapili ka na, saklaw ng step-by-step na authentik install sa isang VPS ang buong setup.

Gaano karaming RAM ang talagang kailangan ng bawat isa?

Magsimula sa resource floor, dahil ito ang nagtatakda ng shortlist bago pa isaalang-alang ang anumang feature. Ang mga numero sa ibaba ay sariling inilathalang figures ng bawat project, na binasa noong August 2026. Vendor guidance ang mga ito, hindi resulta ng 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
  }
]

Sa Docker Compose install page ng authentik, hinihingi ang “isang host na may hindi bababa sa 2 CPU cores at 2 GB ng RAM,” o 2048 MB, at ang inilathalang compose file nito ay nagpapatakbo ng 3 containers: PostgreSQL, ang server, at ang worker.

Ang Keycloak ang naglalathala ng pinakatukoy na figure sa 3. Nakasaad sa sizing guide nito na “ang base memory usage para sa isang Pod, kasama ang caches ng Realm data at 10,000 naka-cache na session, ay 1250 MB ng RAM.” Sinasaklaw ng 1250 MB na ito ang Java process lamang, bago isama ang database. Ipinaliliwanag din ng parehong page kung bakit mahalaga ang container limit: ginagamit ng Keycloak ang 70% ng memory limit bilang heap at nangangailangan ng humigit-kumulang 300 MB na non-heap memory bukod dito. Kung bibigyan ang container ng 1 GB, kino-compute nito ang heap na humigit-kumulang 717 MB habang kailangan pa rin ang 300 MB na non-heap memory. Dahil dito, ubos na agad ang limit bago pa mapunta ang anumang session data sa cache.

Humihingi rin ang compose page ng Zitadel ng 2 GB, o kaparehong 2048 MB, pero para ito sa first run. Ang production page nito ang dapat basahin. Ang Zitadel process mismo ay nangangailangan ng “humigit-kumulang 512MB ng RAM at maaaring gumana gamit ang mas mababa sa isang CPU core.” Ang database ang mas mabigat sa resources: “humigit-kumulang isang CPU core sa bawat 100 requests per second (req/s) at 4GB ng RAM sa bawat core.” Kailangan din ng password hashing ng “4 CPU cores na available para sa layuning ito,” dahil nagiging CPU spike ang biglaang dagsa ng mga login. Ang official v4 compose ay nagpapatakbo ng 4 containers bago ka magdagdag ng anuman: Traefik bilang proxy, ang Zitadel API, isang hiwalay na Login UI container, at PostgreSQL. Nasa likod ng optional compose profiles ang Redis at isang OpenTelemetry collector.

Kaya kasya ang Keycloak at authentik sa isang 4 GB VPS, at may natitirang resources para sa mga app na pinoprotektahan mo. Magsisimula ang Zitadel sa 2 GB, pero makikipag-agawan ito ng memory sa sarili nitong PostgreSQL sa bawat login. Hindi ko patatakbuhin ang Zitadel nang mas mababa sa 4 GB. Kung nagho-host din ang machine ng ibang app, 8 GB ang gusto kong allocation.

Ano talaga ang tumatakbo sa bawat isa sa iyong server

Ang authentik ay PostgreSQL at dalawang kopya ng iisang image: isang server at isang worker. Sumasagot ang server sa HTTP at may embedded outpost. Pinapatakbo ng worker ang mga background task gaya ng directory sync at email. Maikli ang published install.

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

Nagpa-publish ang server ng ports 9000 at 9443. Sa unang pagbisita sa port 9000, tatakbo ang initial setup flow kung saan itatakda mo ang password para sa default na akadmin user. Maglagay ng reverse proxy na may totoong certificate sa harap nito bago maging reachable sa internet ang port na iyon.

Ang Keycloak ay isang process at isang database na ikaw ang magpo-provide. Single container ang quickstart.

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

Ang start-dev ay para sa pagtingin at pagsusuri. Gumagana ito gamit ang local development database at walang TLS (transport layer security), kaya kapag ang container na sinimulan sa ganitong paraan ay inalis kalaunan, kasama nitong mawawala ang iyong realm. Sa production, start ang gamitin sa halip, na may totoong PostgreSQL sa pamamagitan ng KC_DB at public hostname sa pamamagitan ng KC_HOSTNAME. Nakasaad din sa production guide ng Keycloak na lahat ng communication papunta at mula sa server ay nangangailangan ng secure channel, kaya hindi optional ang HTTPS doon.

Ang Zitadel ay ang four-container stack na inilarawan sa itaas.

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

Itakda ang ZITADEL_MASTERKEY sa .env bago ang unang start. Ito ang 32 character key na ginagamit ng Zitadel para i-encrypt ang mga secret sa database, kaya kapag nawala ito, mawawala rin ang access sa mga secret na iyon. Kung bago ka sa pagpapatakbo ng ganitong mga stack, ipinapaliwanag ng mga basic ng Docker Compose para sa isang VPS ang mga pagpili sa volume at restart policy na tumutukoy kung makakaligtas ang iyong identity provider sa reboot.

Anong mga protocol ang sinusuportahan ng bawat isa?

Sinusuportahan ng tatlo ang OpenID Connect (OIDC), ang login layer sa ibabaw ng OAuth 2.0 na ginagamit ng mga modern app. Sinusuportahan din ng tatlo ang SAML 2.0 (security assertion markup language), ang mas lumang standard na ginagamit pa rin sa mga enterprise software release. Ang tunay na pagkakaiba ay LDAP (lightweight directory access protocol), kung saan iisang termino ang tumutukoy sa dalawang magkasalungat na gawain.

Ang pagbabasa mula sa LDAP ay nangangahulugang sinusuri ng SSO server ang mga password laban sa directory na pinapatakbo mo na. Ginagawa ito ng Keycloak sa pamamagitan ng user federation. Ginagawa rin ito ng Zitadel: inilalarawan sa documentation nito kung paano "ikonekta ang isang LDAP server bilang identity provider sa ZITADEL".

Ang pag-serve ng LDAP ay nangangahulugang maaaring mag-bind ang isang app na LDAP lang ang sinusuportahan sa iyong SSO server na para bang ito ang directory. Ang authentik lang ang may ganitong kakayahan. Ginagawang searchable ng LDAP provider nito ang "lahat ng user at group sa database ng authentik sa pamamagitan ng LDAP directory" gamit ang isang dedicated LDAP outpost, at available ang LDAPS sa port 636. Read-only ito, kaya gumagana ang bind at search ngunit hindi ang mga write operation. Idinadagdag ang one-time code sa password gamit ang semicolon, gaya ng password;123456, at hindi sinusuportahan ang SMS authenticator habang nagbi-bind.

Kung may isang app sa listahan mo na LDAP lang ang sinusuportahan, dito nagtatapos ang paghahambing. Hindi masasagot ng Keycloak at Zitadel ang bind na iyon, kaya kailangan mong magpatakbo ng hiwalay na directory at panatilihing naka-sync ang dalawang listahan ng user.

Paano ang mga app na walang login?

Forward auth ang sagot. Ito ang sitwasyong madalas maranasan sa isang self-hosted server. Tinutukoy muna ng reverse proxy sa SSO server kung pinapahintulutan ang request bago ito ipasa upstream. Walang nalalaman ang app tungkol sa SSO. Tumatanggap ito ng mga request na nasuri na ng proxy, karaniwan ay may username sa isang header.

Sinasaklaw ito ng proxy provider ng authentik sa tatlong documented na mode. Sa "Proxy", ang authentik outpost mismo ang nagpapasa ng traffic sa upstream app. Sa "Forward auth (single application)", nananatili ang traffic sa dati mong reverse proxy, at authentik ang ginagamit lamang para sa authentication check. Sa "Forward auth (domain level)", pinoprotektahan ang bawat app sa ilalim ng iisang parent domain gamit ang isang provider. Mas convenient ang domain level, ngunit may documented itong limitasyon: "cannot enforce different application-level authorization rules for each protected application", kaya iisang set ng policy ang ginagamit ng lahat ng app sa domain na iyon.

Wala ng ganitong feature ang Keycloak. Ang companion proxy nito na Keycloak Gatekeeper ay pinalitan ng pangalan bilang Louketo Proxy at pagkatapos ay in-archive sa GitHub; ang huling commit nito ay noong August 2023. Para protektahan ang app na walang OIDC support, magpatakbo ng hiwalay na component sa harap nito, karaniwan ay oauth2-proxy, na naka-point sa isang Keycloak client. Wala ring sariling forward auth mode ang Zitadel, kaya pareho ang solusyon: mag-install, mag-monitor, at mag-upgrade ng karagdagang component.

Sa karagdagang hop na ito nagiging mas komplikado ang reverse proxy config. Basahin muna ang kung paano ginagamit ng Traefik ang ilang Docker Compose app bago mag-wire ng auth middleware dito.

Gaano kahirap ang upgrade path?

Noong August 2026, ang kasalukuyang release ay Keycloak 26.7.1, authentik 2026.5.6, at Zitadel v4.16.3. Lahat ng tatlo ay nagpapatakbo ng schema migration laban sa PostgreSQL, kaya bawat upgrade ay may pagbabago sa database. Mag-back up muna ng database sa bawat pagkakataon. Mas mahalaga ang isang gawi na ito kaysa sa alinmang feature sa paghahambing na ito.

Pinakamahigpit ang panuntunan ng authentik at malinaw nitong sinasabi: "Upgrades must follow the sequence of major releases; do not skip directly from an older major version to the most recent version." Mag-upgrade muna sa pinakabagong patch sa loob ng bawat version bago lumipat sa susunod, at "authentik does not support downgrading". Kapag isang taon kang nahuli sa isang calendar-versioned project, magiging magkakasunod na upgrade ang isang pag-upgrade, at bawat isa ay may sariling database migration.

May order na dapat sundin sa upgrade guide ng Keycloak: suriin ang mga migration change mula sa nakaraang version, i-upgrade ang server, at pagkatapos ay i-upgrade ang adapters. Awtomatikong tumatakbo ang database migration. Maaari mo rin itong i-export at ilapat nang manual, na kapaki-pakinabang kung gusto mong basahin muna ang pagbabago bago ito mailapat. Ang kapalit sa Keycloak ay ang oras para sa pagsusuri. May mga deprecation at pagbabago sa behavior ang release notes nito na madaling malaktawan at magastos kapag hindi napansin.

Inihihiwalay ng Zitadel ang init at setup phase nito mula sa tumatakbong server. Inirerekomenda ng production guidance nito na panatilihing magkahiwalay ang mga ito upang hindi maulit ang setup work kapag nag-scale. Sa isang single VPS, nangangahulugan ito na dapat matapos muna ang setup step bago mag-report ng healthy ang API. Ito ang dahilan kung bakit may health check ang compose file at ginagamit ng start command ang --wait.

Para kanino binuo ang bawat project, at kung saan sila nagkukulang

Ang Keycloak ay identity server ng Red Hat, na idinisenyo para sa mga organisasyong may realms, groups, role mappings, at dati nang corporate directory. Ito ang may pinakakumpletong standards implementation sa tatlo. Nagiging hindi ito angkop sa isang 2 GB VPS na nagpapatakbo ng apat na self-hosted app, kung saan kalahati ay walang OIDC support. Magagamit mo ang 1250 MB para sa JVM, kailangan mong aralin ang realm model na idinisenyo para sa isang kumpanya, at kailangan mo pa ring mag-install ng oauth2-proxy para sa mga app na talagang kailangan mong protektahan.

Ang authentik ay binuo para sa self-hosting audience, at makikita ito sa feature list nito. May kasama itong forward auth at LDAP provider, at binubuo nito ang login flows sa isang visual editor. Nagiging hindi ito angkop kapag kailangan mo ng vendor support contract o release train na hindi nagbabago kada ilang linggo. Totoong operational work ang calendar versioning na walang downgrade path at walang version skipping. Kailangan ding aralin ang buong model ng flow editor kahit isang OIDC client lang ang aktuwal mong problema.

Ang Zitadel ay binuo para sa mga developer na naglalagay ng authentication sa product na kanilang nire-release, na may malakas na API at multi-tenancy bilang first-class features. Hindi ito angkop sa eksaktong sitwasyong ito. Apat na container, walang forward auth, at database na may sizing na 4 GB bawat core ang maling setup para sa isang VPS na may password manager at wiki sa likod nito.

Ano ang patatakbuhin ko sa isang VPS, at paano

Para sa isang VPS na may tatlo o apat na self-hosted app, gamitin ang authentik. Lahat ng tatlong ito ay nagbibigay ng login screen. Ang batayan sa pagpili ay may ilang app na hindi kailanman gagamit ng OIDC, at natutugunan ito ng authentik gamit ang built-in na forward auth sa halip na mangailangan ng isa pang component.

Maglaan ng 4 GB kung kaya, at 2 GB lamang kung maliliit ang mga app na kasabay nito. Huwag ilantad sa public internet ang port 9000, at i-terminate ang TLS sa reverse proxy na nasa harap nito. Gumawa gabi-gabi ng PostgreSQL dumps at i-store ang mga ito sa labas ng server, dahil ang identity provider na walang backup ay nagiging single point of failure para sa bawat app na nasa likod nito. Patakbuhin ang stack gamit ang dedicated unprivileged account sa halip na root: saklaw ng pag-set up ng mga user na may least privilege sa isang VPS ang account at file ownership na kailangan dito.

Piliin ang Keycloak kapag ang bawat app na poprotektahan mo ay gumagamit na ng OIDC o SAML, o kapag kailangan mo ng fine-grained role model na ibinibigay ng Keycloak realms. Piliin ang Zitadel kapag gumagawa ka ng application na maaaring pag-sign-up-an ng ibang tao at kailangan mo ang API at tenant model nito. Hindi angkop ang alinman sa dalawang iyon sa setup na tatlong app sa isang server na tinatalakay ng post na ito.

Mga failure mode na una mong mararanasan

Walang data ang Keycloak pagkatapos ng restart. Sinimulan mo ito gamit ang start-dev, na gumagamit ng local development database. Sa container na walang volume, kapag inalis ang container, mawawala ang realm. Lumipat sa start gamit ang KC_DB=postgres na naka-configure para tumuro sa isang totoong database.

Nawawala ang authentik worker container sa maliit na server. Parehong image ang ginagamit ng worker at server, at parehong may Python process. Kailangan din ng PostgreSQL ng bahagi ng 2 GB na memory ng host. Patakbuhin ang docker compose ps upang makumpirma kung aling service ang nag-exit. Pagkatapos, tingnan ang dmesg para sa out-of-memory kill bago maghanap ng bug sa app.

Hindi gumagana ang Console ng Zitadel sa likod ng proxy. Gumagamit ng gRPC ang Zitadel API, kaya kailangan ng HTTP/2 hanggang sa upstream. Hinihingi sa requirements page ang reverse proxy na sumusuporta sa HTTP/2 upstream connections. Binabanggit din dito ang mga nasubok na bersyon ng Traefik v3.x, NGINX v1.x, Caddy v2.x, at Apache httpd 2.4.x. Kung ibinababa ng proxy ang upstream connection sa HTTP/1.1, maglo-load ang login page ngunit mabibigo ang Console.

Bawat app ay ibinabalik ka sa login screen. Kailangang eksaktong magtugma ang public URL ng SSO server at ang URL na naka-configure sa app, pati ang scheme at port. Tinatawag ito ng Keycloak na hostname setting, samantalang external domain ang tawag dito ng Zitadel. Kapag hindi nagtugma ang mga ito, nagre-redirect ang app sa login na hindi kinikilalang sariling login ng server. Paulit-ulit na nagpapalipat-lipat ang browser sa dalawang URL.

FAQ

Alin sa tatlo ang angkop para sa 2 GB VPS?

authentik at Keycloak. Ang nakasaad na requirement ng authentik ay host na may hindi bababa sa 2 CPU cores at 2 GB ng RAM, at itinatakda ng sizing guide ng Keycloak ang base memory sa 1250 MB para sa server bago isama ang database nito. Kapos ang parehong option sa 2 GB kapag idinagdag ang mga app na poprotektahan mo, kaya ituring ang 4 GB bilang komportableng minimum. Naglalathala ang Zitadel ng 2 GB para sa unang run, ngunit nangangailangan ang production guidance nito ng 4 CPU cores para sa password hashing at 4 GB ng RAM bawat database core, kaya hindi sapat ang 2 GB para sa aktuwal na deployment.

Maaari bang protektahan ng Keycloak o Zitadel ang app na walang sariling login?

Hindi nang mag-isa. Walang forward auth component na kasama sa alinman sa mga ito. Ang dating companion proxy ng Keycloak na Louketo Proxy ay naka-archive sa GitHub, at ang huli nitong commit ay noong August 2023, kaya hindi ito dapat gawing batayan ng bagong deployment. Maglagay ng oauth2-proxy o katulad na component sa pagitan ng reverse proxy at app, at ituro ito sa isang OIDC client sa SSO server. Katutubong ginagawa ito ng authentik gamit ang proxy provider nito sa mode na "Forward auth (single application)" o "Forward auth (domain level)."

Alin sa mga ito ang maaaring maging LDAP server para sa app na LDAP lamang ang sinusuportahan?

authentik. Tumatakbo ang LDAP provider nito sa isang outpost at ginagawang searchable sa LDAP ang mga user at group sa authentik, na may LDAPS sa port 636. Read-only ito, kaya gumagana ang bind at search ngunit hindi ang mga write operation. Kabaligtaran ang direksiyon ng Keycloak at Zitadel: parehong bumabasa mula sa isang umiiral na LDAP directory bilang user source, at wala sa alinman ang tumatanggap ng LDAP bind mula sa isang application.

Maaari ko bang laktawan ang mga version kapag nag-upgrade ng authentik?

Hindi. Ayon sa documentation, dapat sundin ng mga upgrade ang pagkakasunod-sunod ng major release, at hindi dapat direktang lumipat mula sa mas lumang major version papunta sa pinakabagong version. Mag-update muna sa pinakabagong patch release sa loob ng bawat version, pagkatapos ay umakyat nang tig-iisang version. Mag-back up ng PostgreSQL bago ang bawat hakbang, dahil hindi sinusuportahan ng authentik ang pag-downgrade at pasulong lamang tumatakbo ang mga migration.