ఒక VPSలో Keycloak vs authentik vs Zitadel: ఏది?

ఒక VPS కు సరిపోయే SSO server ఏది

Keycloak, authentik మరియు Zitadel అనేవి self-hosted single sign-on (SSO) servers. Server‌లోని ప్రతి అప్లికేషన్‌కు ఒకే login కావాలనుకున్నప్పుడు సాధారణంగా వీటిని పరిశీలిస్తారు. ఒక చిన్న VPS‌లో ఇవి పరస్పరం సమానమైనవి కావు. మూడు లేదా నాలుగు self-hosted అప్లికేషన్లు నడుస్తున్న server‌కు authentik సాధారణంగా సురక్షితమైన default ఎంపిక. స్వంతంగా login వ్యవస్థ లేని అప్లికేషన్ ముందు login screen ఉంచగలిగేది ఈ మూడింటిలో authentik మాత్రమే. మీరు రక్షించాల్సిన ప్రతి అప్లికేషన్ ఇప్పటికే standard protocol‌కు మద్దతు ఇస్తే, Java virtual machine (JVM) కోసం అవసరమైన memory అందుబాటులో ఉంటే Keycloak సరైన ఎంపిక. API ద్వారా product‌ను విడుదల చేసే developers కోసం Zitadel రూపొందించబడింది. 4 GB కంటే తక్కువ memory ఉన్న వ్యవస్థలో దీన్ని ఉపయోగించడానికి నేను ప్రయత్నించను.

ముందుగా ఎంపిక చేసుకోండి, తరువాత install చేయండి. ఎంపిక చేసిన తర్వాత, VPS పై authentik ను స్వయంగా install చేసే విధానం setup‌ను దశలవారీగా వివరిస్తుంది.

ప్రతి దానికి వాస్తవంగా ఎంత RAM అవసరం?

ముందుగా resource floor ను నిర్ణయించండి. ఏ feature ను పరిగణలోకి తీసుకునే ముందే ఇది shortlist ను నిర్ణయిస్తుంది. క్రింది సంఖ్యలు ప్రతి project ఆగస్టు 2026లో ప్రచురించిన గణాంకాల ఆధారంగా ఉన్నాయి. ఇవి vendor guidance మాత్రమే; 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
  }
]

authentik యొక్క Docker Compose install page కనీసం 2 CPU cores మరియు 2 GB RAM ఉన్న host కావాలని చెబుతుంది. ఇది 2048 MB. ప్రచురించిన compose file 3 containers ను నడుపుతుంది: PostgreSQL, server మరియు worker.

Keycloak 3 లో అత్యంత నిర్దిష్టమైన గణాంకాన్ని అందిస్తుంది. దాని sizing guide ప్రకారం, Realm data caches మరియు 10,000 cached sessions తో ఒక Pod కు అవసరమైన base memory usage 1250 MB RAM. ఆ 1250 MB Java process కు మాత్రమే సరిపోతాయి; database ఇందులో లేదు. Container memory limit ఎందుకు ముఖ్యమో అదే page వివరిస్తుంది: Keycloak memory limit లో 70% ను heap గా తీసుకుంటుంది. అదనంగా సుమారు 300 MB non-heap memory అవసరం. Container కు 1 GB ఇస్తే heap సుమారు 717 MB గా లెక్కించబడుతుంది. ఇంకా 300 MB non-heap memory అవసరమవుతుంది. అందువల్ల session data cache లోకి చేరకముందే limit పూర్తిగా వినియోగమవుతుంది.

Zitadel యొక్క compose page కూడా 2 GB, అంటే అదే 2048 MB కోరుతుంది. అయితే అది మొదటి run కు సంబంధించిన గణాంకం. Production page ను పరిశీలించాలి. Zitadel process కు స్వయంగా సుమారు 512MB RAM అవసరం. ఇది ఒక CPU core కంటే తక్కువతో కూడా పనిచేయగలదు. ఖరీదైన భాగం database: ప్రతి 100 requests per second (req/s) కు సుమారు ఒక CPU core మరియు ప్రతి core కు 4GB RAM అవసరం. Password hashing కోసం 4 CPU cores అందుబాటులో ఉండాలి. ఎందుకంటే logins లో ఒక్కసారిగా పెరుగుదల వచ్చినప్పుడు CPU వినియోగం తీవ్రంగా పెరుగుతుంది. Official v4 compose లో మీరు మరేమీ జోడించకముందే 4 containers నడుస్తాయి: proxy గా Traefik, Zitadel API, ప్రత్యేక Login UI container మరియు PostgreSQL. Redis మరియు OpenTelemetry collector optional compose profiles వెనుక ఉంటాయి.

అందువల్ల Keycloak మరియు authentik ను 4 GB VPS పై, మీరు రక్షిస్తున్న apps కోసం కొంత memory మిగిలేలా నడపవచ్చు. Zitadel 2 GB పై ప్రారంభమవుతుంది. అయితే ప్రతి login సమయంలో అది తన PostgreSQL తో memory కోసం పోటీ పడుతుంది. Zitadel ను 4 GB కంటే తక్కువ memory పై నేను నడపను. అదే server పై apps కూడా ఉంటే 8 GB కావాలని నేను భావిస్తాను.

మీ సర్వర్‌లో ప్రతి సేవ వాస్తవంగా ఏమి నడుపుతుంది

authentik అనేది PostgreSQL మరియు ఒకే image యొక్క రెండు copies కలిగిన stack. వాటిలో ఒకటి server, మరొకటి worker. server HTTP అభ్యర్థనలకు సమాధానం ఇస్తుంది మరియు embedded outpost ను కలిగి ఉంటుంది. worker directory syncs, email వంటి background tasks ను నడుపుతుంది. ప్రచురిత 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

server 9000 మరియు 9443 ports ను publish చేస్తుంది. 9000 port కు మొదటిసారి వెళ్లినప్పుడు initial setup flow ప్రారంభమవుతుంది. ఇందులో default akadmin user కోసం password ను సెట్ చేస్తారు. ఆ port internet నుంచి చేరుకోగలిగే ముందు, దాని ముందు నిజమైన certificate తో reverse proxy ను ఉంచండి.

Keycloak అనేది మీరు అందించే database తో కూడిన ఒక process. quickstart ఒకే 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 పరిశీలన కోసం మాత్రమే. ఇది local development database తో, TLS (transport layer security) లేకుండా నడుస్తుంది. అందువల్ల ఈ విధంగా ప్రారంభించిన container ను తరువాత తొలగిస్తే, దానితో పాటు మీ realm కూడా తొలగిపోతుంది. Production కోసం బదులుగా start ఉపయోగించాలి. ఇందులో KC_DB ద్వారా నిజమైన PostgreSQL ను, KC_HOSTNAME ద్వారా public hostname ను అందించాలి. Keycloak production guide ప్రకారం server కు వచ్చే మరియు server నుంచి వెళ్లే మొత్తం communication కు secure channel అవసరం. కాబట్టి అక్కడ HTTPS ఐచ్ఛికం కాదు.

Zitadel అనేది పైన వివరించిన four-container stack.

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

మొదటి start కు ముందు .env లో ZITADEL_MASTERKEY ను సెట్ చేయండి. Database లో secrets ను encrypt చేయడానికి Zitadel ఉపయోగించే 32 character key ఇదే. ఈ key పోతే, ఆ secrets కు ప్రాప్యత కూడా కోల్పోతారు. ఇలాంటి stacks ను అమలు చేయడం మీకు కొత్తైతే, VPS కోసం Docker Compose ప్రాథమికాలు volume మరియు restart-policy ఎంపికలను వివరిస్తుంది. Reboot తర్వాత మీ identity provider కొనసాగుతుందా లేదా అనేది ఈ ఎంపికలపై ఆధారపడి ఉంటుంది.

ప్రతి వ్యవస్థ ఏ ప్రోటోకాల్‌లను ఉపయోగిస్తుంది?

మూడు వ్యవస్థలూ OpenID Connect (OIDC) ను ఉపయోగిస్తాయి. ఇది ఆధునిక అప్లికేషన్లు ఉపయోగించే OAuth 2.0 పై పనిచేసే login layer. అలాగే మూడు వ్యవస్థలూ SAML 2.0 (security assertion markup language) ను కూడా ఉపయోగిస్తాయి. ఇది enterprise software ఇప్పటికీ విడుదల చేసే పాత standard. అసలు తేడా LDAP (lightweight directory access protocol) విషయంలో కనిపిస్తుంది. ఒకే పదం అయిన LDAP రెండు విరుద్ధమైన పనులను సూచిస్తుంది.

LDAP నుంచి చదవడం అంటే మీరు ఇప్పటికే నిర్వహిస్తున్న directory తో SSO server passwords ను తనిఖీ చేయడం. Keycloak దీన్ని user federation ద్వారా చేస్తుంది. Zitadel కూడా ఇదే విధంగా పనిచేస్తుంది. దాని documentation లో "connect an LDAP server as an identity provider in ZITADEL" అని వివరించారు.

LDAP అందించడం అంటే LDAP మాత్రమే మాట్లాడే అప్లికేషన్ మీ SSO server కు directory తో bind అయినట్లుగా bind కావడం. ఇది authentik మాత్రమే చేస్తుంది. దాని LDAP provider ప్రత్యేకమైన LDAP outpost ద్వారా "all users and groups in authentik's database searchable via the LDAP directory" చేస్తుంది. LDAPS port 636 పై అందుబాటులో ఉంటుంది. ఇది read-only. అందువల్ల bind మరియు search పనిచేస్తాయి, కానీ writes పనిచేయవు. Password కు semicolon తో one-time code జతచేయాలి. ఉదాహరణకు password;123456. Bind సమయంలో SMS authenticators కు మద్దతు లేదు.

మీ జాబితాలో ఒక అప్లికేషన్ LDAP మాత్రమే మాట్లాడితే, పోలిక అక్కడితో ముగుస్తుంది. Keycloak మరియు Zitadel ఆ bind కు సమాధానం ఇవ్వలేవు. కాబట్టి వాటి పక్కన రెండవ directory నడిపి, రెండు user lists ను సమకాలీకరించాలి.

లాగిన్ అసలు లేని అప్లికేషన్ల సంగతేంటి?

దీనికి forward auth సమాధానం. self-hosted సర్వర్‌లో ఇది తరచుగా ఎదురయ్యే అవసరం. అభ్యర్థనను upstream కు పంపే ముందు reverse proxy, ఆ అభ్యర్థనకు అనుమతి ఉందా అని SSO server ను అడుగుతుంది. దాని వెనుక ఉన్న అప్లికేషన్‌కు SSO గురించి ఏమీ తెలియదు. Proxy ఇప్పటికే తనిఖీ చేసిన అభ్యర్థనలను అది స్వీకరిస్తుంది. సాధారణంగా username ఒక header లో ఉంటుంది.

authentik యొక్క proxy provider దీనికి documentation లో పేర్కొన్న మూడు modes ను అందిస్తుంది. "Proxy" mode లో authentik outpost traffic ను upstream అప్లికేషన్‌కు స్వయంగా పంపుతుంది. "Forward auth (single application)" mode లో traffic మీ ప్రస్తుత reverse proxy వద్దనే ఉంటుంది. authentik authentication check కోసం మాత్రమే ఉపయోగించబడుతుంది. "Forward auth (domain level)" mode ఒకే parent domain కింద ఉన్న ప్రతి అప్లికేషన్‌ను ఒకే provider తో రక్షిస్తుంది. Domain level సౌకర్యవంతమైనది. అయితే దీనికి documentation లో పేర్కొన్న పరిమితి ఉంది: ఇది "రక్షించబడిన ప్రతి అప్లికేషన్‌కు వేర్వేరు application-level authorization rules ను అమలు చేయలదు". అందువల్ల ఆ domain కింద ఉన్న అన్ని అప్లికేషన్లు ఒకే policy set ను పంచుకుంటాయి.

Keycloak లో ఈ సౌకర్యం ఏదీ లేదు. దానికి అనుబంధంగా ఉన్న proxy, Keycloak Gatekeeper, తరువాత Louketo Proxy గా పేరు మార్చబడింది. ఆ తరువాత GitHub లో archive చేయబడింది. దాని చివరి commit August 2023లో జరిగింది. OIDC support లేని అప్లికేషన్‌ను రక్షించడానికి దాని ముందు ఒక ప్రత్యేక component ను నడపాలి. సాధారణంగా Keycloak client కు pointed గా ఉన్న oauth2-proxy ను ఉపయోగిస్తారు. Zitadel లో కూడా స్వంత forward auth mode లేదు. కాబట్టి అక్కడ కూడా install, monitor, upgrade చేయాల్సిన అదనపు component అవసరం.

ఆ అదనపు hop వచ్చినప్పుడు reverse proxy configuration సరళంగా ఉండదు. అందువల్ల auth middleware ను అందులో అమర్చే ముందు అనేక Docker Compose అప్లికేషన్ల ముందు Traefik ను ఎలా ఉంచాలో చదవండి.

అప్‌గ్రేడ్ మార్గం ఎంత క్లిష్టంగా ఉంటుంది?

2026 August నాటికి ప్రస్తుత releases Keycloak 26.7.1, authentik 2026.5.6, మరియు Zitadel v4.16.3. ఈ మూడూ PostgreSQL పై schema migrations నడుపుతాయి. అంటే ప్రతి upgrade లో database మార్పు ఉంటుంది. ప్రతి సారి ముందుగా database ను backup చేయండి. ఈ ఒక్క అలవాటు ఈ పోలికలోని ఏ feature కంటే ఎక్కువ విలువైనది.

authentik కు అత్యంత కఠినమైన నియమం ఉంది. దానిని స్పష్టంగా ఇలా పేర్కొంటుంది: "Upgrades must follow the sequence of major releases; do not skip directly from an older major version to the most recent version." ప్రతి version లోని తాజా patch కు ముందుగా upgrade చేసి, ఆ తరువాతి major version కు వెళ్లాలి. అలాగే "authentik does not support downgrading". Calendar-versioned project లో ఒక సంవత్సరం వెనుకబడితే, ఒక upgrade అనేక వరుస upgrades గా మారుతుంది. ప్రతి upgrade కు ప్రత్యేక database migration ఉంటుంది.

Keycloak upgrade guide అనుసరించాల్సిన క్రమాన్ని వివరిస్తుంది: మునుపటి version నుంచి వచ్చిన migration మార్పులను పరిశీలించండి, server ను upgrade చేయండి, తరువాత adapters ను upgrade చేయండి. Database migration స్వయంచాలకంగా నడుస్తుంది. లేదా దానిని export చేసి చేతితో apply చేయవచ్చు. మార్పు అమలయ్యే ముందు దాన్ని చదవాలనుకున్నప్పుడు ఇది ఉపయోగకరంగా ఉంటుంది. Keycloak లో ప్రధాన ఖర్చు ఆ పరిశీలనకే సంబంధించినది. దాని release notes లో deprecations మరియు behaviour changes ఉంటాయి. వాటిని సులభంగా దాటవేయవచ్చు, కానీ గమనించకపోతే సమస్యను సరిచేయడం ఖరీదైనదవుతుంది.

Zitadel తన init మరియు setup phases ను running server నుంచి వేరు చేస్తుంది. Scaling సమయంలో setup పని మళ్లీ జరగకుండా వాటిని వేరుగా ఉంచాలని production guidance సిఫారసు చేస్తుంది. ఒకే VPS లో ఇది సాధారణంగా API healthy గా report చేయడానికి ముందు setup step పూర్తవ్వాలి అనే అర్థం. అందుకే compose file లో health checks ఉంటాయి, అలాగే start command --wait ను ఉపయోగిస్తుంది.

ప్రతి ప్రాజెక్ట్ ఎవరి కోసం రూపొందించబడింది, ఎక్కడ పరిమితులు ఎదురవుతాయి

Keycloak అనేది Red Hat రూపొందించిన identity server. ఇది realms, groups, role mappings మరియు ఇప్పటికే ఉన్న corporate directory కలిగిన సంస్థల కోసం రూపొందించబడింది. ఈ మూడింటిలో standards అమలు పరంగా ఇది అత్యంత సమగ్రంగా ఉంటుంది. అయితే 2 GB VPSపై నాలుగు self-hosted అప్లికేషన్లు నడుస్తూ, వాటిలో సగానికి OIDC support లేకపోతే ఇది అనుకూలంగా ఉండదు. JVM కోసం 1250 MB కేటాయించాలి. సంస్థల కోసం రూపొందించిన realm model ను నేర్చుకోవాలి. మీరు నిజంగా ఉపయోగించాలనుకున్న అప్లికేషన్ల కోసం చివరికి oauth2-proxy ను కూడా ఇన్‌స్టాల్ చేయాల్సి వస్తుంది.

authentik self-hosting వినియోగదారుల కోసం రూపొందించబడింది. దాని feature list దీనిని స్పష్టంగా చూపిస్తుంది. ఇది forward auth మరియు LDAP provider ను అందిస్తుంది. Login flows ను visual editor లో రూపొందించవచ్చు. అయితే vendor support contract లేదా ప్రతి కొన్ని వారాలకు మారని release train అవసరమైనప్పుడు ఇది పరిమితంగా ఉంటుంది. Downgrade path లేకుండా, version skipping లేకుండా calendar versioning నిర్వహించడం నిజమైన operational work అవుతుంది. మీ అసలు సమస్య ఒకే OIDC client అయినప్పుడు flow editor నేర్చుకోవడం మరో పూర్తి model ను నేర్చుకోవడంతో సమానం.

Zitadel మీరు విడుదల చేసే product లో authentication ను అంతర్గతంగా అమలు చేసే developers కోసం రూపొందించబడింది. దీనిలో బలమైన API మరియు first-class features గా multi-tenancy ఉన్నాయి. అయితే ఈ సందర్భంలోనే ఇది అనుకూలంగా ఉండదు. ఒక VPSపై password manager మరియు wiki ను వెనుక ఉంచడానికి నాలుగు containers, forward auth లేకపోవడం, ప్రతి coreకు 4 GB పరిమాణం గల database అవసరం కావడం సరైన నిర్మాణం కాదు.

నేను ఒక VPSలో అమలు చేసేది, ఎలా అమలు చేసేది

మూడు లేదా నాలుగు self-hosted అప్లికేషన్లు ఉన్న ఒక VPS కోసం authentik ను అమలు చేయండి. ఈ మూడింటిలో ప్రతి ఒక్కటి login screen ను అందిస్తుంది. నిర్ణయాత్మక విషయం ఏమిటంటే, మీ కొన్ని అప్లికేషన్లు ఎప్పటికీ OIDCకు మద్దతు ఇవ్వకపోవచ్చు. authentik దీనికి అదనపు component ను పక్కన అమలు చేయకుండా, built-in forward auth ద్వారా పరిష్కారం అందిస్తుంది.

సాధ్యమైతే దీనికి 4 GB ఇవ్వండి. దాని పక్కన నడిచే అప్లికేషన్లు చిన్నవైతే మాత్రమే 2 GB సరిపోతుంది. port 9000 ను public internet నుంచి అందుబాటులో ఉంచవద్దు. ముందున్న reverse proxy వద్ద TLS termination చేయండి. ప్రతి రాత్రి PostgreSQL dumps తీసి, వాటిని ఆ machine వెలుపల నిల్వ చేయండి. ఎందుకంటే backup లేని identity provider, దాని వెనుక ఉన్న ప్రతి అప్లికేషన్‌కు single point of failure అవుతుంది. stack ను root గా కాకుండా ప్రత్యేక unprivileged account తో అమలు చేయండి: ఈ అవసరానికి కావలసిన account మరియు file ownership వివరాలను VPSలో least privilege users ను ఏర్పాటు చేయడం వివరిస్తుంది.

మీరు రక్షించే ప్రతి అప్లికేషన్ ఇప్పటికే OIDC లేదా SAMLకు మద్దతు ఇస్తే, లేదా Keycloak realms అందించే సూక్ష్మమైన role model అవసరమైతే Keycloak ను ఎంచుకోండి. ఇతర వ్యక్తులు sign up చేయగల అప్లికేషన్‌ను నిర్మిస్తున్నప్పుడు, దాని API మరియు tenant model అవసరమైతే Zitadel ను ఎంచుకోండి. ఈ రెండూ ఈ postలో చర్చిస్తున్న ఒక machineపై మూడు అప్లికేషన్ల సందర్భానికి సరిపోవు.

మీరు మొదట ఎదుర్కొనే విఫలత పరిస్థితులు

పునఃప్రారంభం తర్వాత Keycloak లో డేటా ఉండదు. మీరు దీన్ని start-dev తో ప్రారంభించారు. ఇది local development database ను ఉపయోగిస్తుంది. volume లేని container లో container ను తొలగిస్తే realm కూడా తొలగిపోతుంది. వాస్తవ database ను ఉపయోగించేలా KC_DB=postgres ను సూచించే start కు మార్చండి.

చిన్న సిస్టమ్‌లో authentik worker container కనుమరుగవుతుంది. worker మరియు server ఒకే image ను ఉపయోగిస్తాయి. రెండింటిలోనూ Python processes నడుస్తాయి. 2 GB host memory లో PostgreSQL కు కూడా తనకు అవసరమైన memory కావాలి. ఏ service exit అయిందో నిర్ధారించడానికి docker compose ps ను నడపండి. తరువాత app లో bug కోసం వెతకడానికి ముందు out-of-memory kill జరిగిందో లేదో తెలుసుకోవడానికి dmesg ను పరిశీలించండి.

మీ proxy వెనుక Zitadel Console పనిచేయదు. Zitadel API gRPC ను ఉపయోగిస్తుంది. అందువల్ల upstream వరకు మొత్తం మార్గంలో HTTP/2 అవసరం. Requirements page upstream connections కోసం HTTP/2 కు మద్దతు ఇచ్చే reverse proxy అవసరమని చెబుతుంది. పరీక్షించిన Traefik v3.x, NGINX v1.x, Caddy v2.x మరియు Apache httpd 2.4.x versions ను కూడా అందులో పేర్కొంటుంది. upstream connection ను HTTP/1.1 కు downgrade చేసే proxy వల్ల login page లోడ్ అవుతుంది, కానీ Console విఫలమవుతుంది.

ప్రతి app మిమ్మల్ని మళ్లీ login screen కు పంపిస్తుంది. SSO server యొక్క public URL మరియు app లో configure చేసిన URL scheme మరియు port తో సహా అచ్చంగా సరిపోవాలి. Keycloak దీన్ని hostname setting అని పిలుస్తుంది. Zitadel దీన్ని external domain అని పిలుస్తుంది. ఇవి సరిపోకపోతే app server తనదిగా గుర్తించని login URL కు redirect చేస్తుంది. దాంతో browser ఆ రెండు URLల మధ్య తిరుగుతూనే ఉంటుంది.

FAQ

ఈ మూడింటిలో 2 GB VPS కు ఏది సరిపోతుంది?

authentik మరియు Keycloak. authentik పేర్కొన్న అవసరం ప్రకారం host లో కనీసం 2 CPU cores మరియు 2 GB RAM ఉండాలి. Keycloak sizing guide ప్రకారం database ను మినహాయించి server కు ప్రాథమిక memory అవసరం 1250 MB. మీరు రక్షిస్తున్న అప్లికేషన్లను కూడా చేర్చిన తర్వాత 2 GB లో రెండూ పరిమితంగానే పనిచేస్తాయి. అందువల్ల సౌకర్యవంతమైన కనీస పరిమాణంగా 4 GB ను పరిగణించండి. Zitadel మొదటి run కోసం 2 GB ను సూచిస్తుంది. అయితే దాని production guidance password hashing కోసం 4 CPU cores, ప్రతి database core కు 4 GB RAM కోరుతుంది. కాబట్టి 2 GB వాస్తవ deployment కు సరిపోదు.

స్వంత login లేని అప్లికేషన్‌ను Keycloak లేదా Zitadel రక్షించగలవా?

వాటి ద్వారా మాత్రమే కాదు. రెండింటిలోనూ forward auth component అందించబడదు. Keycloak యొక్క పాత companion proxy అయిన Louketo Proxy GitHub లో archived స్థితిలో ఉంది. దాని చివరి commit August 2023 లో జరిగింది. అందువల్ల దానిపై ఆధారపడి నిర్మించడం సరైనది కాదు. మీ reverse proxy మరియు అప్లికేషన్ మధ్య oauth2-proxy లేదా ఇలాంటి component ను ఉంచండి. దాన్ని SSO server లోని OIDC client కు point చేయండి. authentik లో ఇది సహజంగానే అందుబాటులో ఉంటుంది. దాని proxy provider ను "Forward auth (single application)" లేదా "Forward auth (domain level)" mode లో ఉపయోగించవచ్చు.

LDAP మాత్రమే మాట్లాడే అప్లికేషన్‌కు LDAP server గా ఏది పనిచేయగలదు?

authentik. దీని LDAP provider ఒక outpost పై నడుస్తుంది. authentik లోని users మరియు groups ను LDAP ద్వారా search చేయగలిగేలా చేస్తుంది. LDAPS port 636 పై అందుబాటులో ఉంటుంది. ఇది read-only. అందువల్ల bind మరియు search పనిచేస్తాయి, కానీ writes పనిచేయవు. Keycloak మరియు Zitadel దీనికి విరుద్ధంగా పనిచేస్తాయి. రెండూ ఇప్పటికే ఉన్న LDAP directory నుంచి user source గా data చదువుతాయి. అయితే ఏదీ అప్లికేషన్ నుంచి వచ్చే LDAP bind కు సమాధానం ఇవ్వదు.

authentik ను upgrade చేసేటప్పుడు versions ను దాటవచ్చా?

లేదు. Major releases క్రమాన్ని అనుసరించాల్సిందేనని documentation పేర్కొంటుంది. పాత major version నుంచి నేరుగా తాజా version కు వెళ్లకూడదు. ముందుగా ప్రతి version లోని తాజా patch release కు upgrade చేయండి. తరువాత ఒక్కోసారి ఒక version చొప్పున ముందుకు వెళ్లండి. ప్రతి దశకు ముందు PostgreSQL ను backup చేయండి. authentik downgrade కు మద్దతు ఇవ్వదు. Migrations ముందుకు మాత్రమే అమలవుతాయి.