एका VPS वर Keycloak, authentik की Zitadel?

एका VPS साठी कोणता SSO सर्व्हर योग्य आहे

Keycloak, authentik आणि Zitadel हे self-hosted single sign-on (SSO) सर्व्हर आहेत. सर्व अॅप्ससाठी एकच login हवा असताना त्यांचा विचार केला जातो. एका लहान VPS वर हे सर्व एकमेकांचे पर्याय नाहीत. तीन किंवा चार self-hosted अॅप्स चालणाऱ्या सर्व्हरसाठी authentik हा सुरक्षित default पर्याय आहे. कारण स्वतःची login सुविधा नसलेल्या अॅपसमोर login screen ठेवू शकणारा या तिघांमधील तो एकमेव पर्याय आहे. संरक्षित करायचे प्रत्येक अॅप आधीपासून standard protocol वापरत असेल आणि Java virtual machine (JVM) साठी पुरेशी memory उपलब्ध असेल, तर Keycloak योग्य पर्याय आहे. Zitadel हे API द्वारे product ship करणाऱ्या developers साठी तयार केले आहे. 4 GB पेक्षा कमी memory असलेल्या सर्व्हरवर ते वापरण्याचा मी प्रयत्न करणार नाही.

आधी पर्याय निवडा, त्यानंतर install करा. पर्याय निवडल्यानंतर, VPS वर authentik install करण्याची प्रत्यक्ष मार्गदर्शिका setup ची प्रत्येक पायरी समजावते.

प्रत्येकाला प्रत्यक्षात किती RAM आवश्यक आहे?

संसाधनांची किमान आवश्यकता आधी पाहा. कोणतीही सुविधा विचारात घेण्यापूर्वी तीच प्राथमिक पर्यायांची यादी ठरवते. खालील आकडे प्रत्येक प्रकल्पाने प्रकाशित केलेले असून ते August 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 पृष्ठावर "किमान 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 limit इतकी महत्त्वाची का आहे हे त्याच पृष्ठावर स्पष्ट केले आहे: 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 पृष्ठावरही 2 GB, म्हणजेच तेच 2048 MB, आवश्यक असल्याचे नमूद केले आहे. परंतु हा आकडा first run साठी आहे. Production पृष्ठ अधिक उपयुक्त आहे. Zitadel process ला स्वतःला "सुमारे 512MB RAM आवश्यक आहे आणि तो one CPU core पेक्षा कमी क्षमतेवर चालू शकतो." Database हा अधिक संसाधनखाऊ भाग आहे: "प्रति 100 requests per second (req/s) सुमारे one CPU core आणि प्रति core 4GB RAM." Password hashing साठी "या कामासाठी 4 CPU cores उपलब्ध" असणे आवश्यक आहे, कारण login च्या अचानक वाढलेल्या लाटेमुळे CPU spike निर्माण होतो. अधिकृत v4 compose मध्ये तुम्ही काहीही जोडण्यापूर्वी 4 containers चालतात: proxy म्हणून Traefik, Zitadel API, स्वतंत्र Login UI container आणि PostgreSQL. Redis आणि OpenTelemetry collector optional compose profiles अंतर्गत असतात.

म्हणून Keycloak आणि authentik हे 4 GB VPS वर, तुम्ही सुरक्षित करत असलेल्या apps साठी काही RAM शिल्लक ठेवून, चालू शकतात. Zitadel 2 GB वर सुरू होईल; परंतु प्रत्येक login वेळी ते स्वतःच्या PostgreSQL सोबत memory साठी स्पर्धा करेल. मी Zitadel 4 GB पेक्षा कमी RAM वर चालवणार नाही. ज्या server वर apps देखील hosted असतील, तिथे मला 8 GB RAM हवी असेल.

तुमच्या सर्व्हरवर प्रत्यक्षात काय चालते

authentik म्हणजे PostgreSQL आणि एकाच image च्या दोन प्रती: एक 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 ports 9000 आणि 9443 प्रकाशित करतो. port 9000 ला पहिल्यांदा भेट दिल्यावर initial setup flow सुरू होतो. या 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

पहिल्यांदा सुरू करण्यापूर्वी .env मध्ये ZITADEL_MASTERKEY सेट करा. database मधील secrets encrypt करण्यासाठी Zitadel ही 32 character key वापरतो. त्यामुळे ती हरवल्यास त्या secrets चा access गमावता. अशा stack चालवण्याचा अनुभव नसल्यास, VPS साठी Docker Compose ची मूलभूत माहिती volume आणि restart-policy मधील त्या निवडींचे वर्णन करते ज्यावर reboot नंतर तुमचा identity provider उपलब्ध राहतो की नाही हे ठरते.

प्रत्येक प्रणाली कोणते protocol वापरते?

तिन्ही प्रणाली OpenID Connect (OIDC) वापरतात. आधुनिक अॅप्स वापरत असलेला हा OAuth 2.0 वरील login layer आहे. तिन्ही प्रणाली SAML 2.0 (security assertion markup language) देखील वापरतात. हा जुना standard आहे, जो enterprise software अजूनही release करते. खरा फरक LDAP (lightweight directory access protocol) मध्ये आहे. LDAP या एकाच शब्दाने दोन परस्परविरोधी कामे दर्शवली जातात.

LDAP मधून वाचणे म्हणजे SSO server तुम्ही आधीपासून चालवत असलेल्या directory विरुद्ध passwords तपासतो. Keycloak हे user federation द्वारे करते. Zitadel देखील हे करते. त्याच्या documentation मध्ये “ZITADEL मध्ये identity provider म्हणून LDAP server connect करणे” याचे वर्णन आहे.

LDAP उपलब्ध करून देणे म्हणजे केवळ LDAP बोलणारा अॅप तुमच्या SSO server शी bind करू शकतो आणि तो directory असल्याप्रमाणे त्याचा वापर करू शकतो. हे फक्त authentik करते. त्याचा LDAP provider dedicated LDAP outpost द्वारे “authentik च्या database मधील सर्व users आणि groups LDAP directory मधून searchable करतो”. 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 समक्रमित ठेवाव्या लागतील.

ज्या अॅपमध्ये login ची सुविधाच नाही, त्यांचे काय?

यासाठी forward auth हा उपाय आहे. Self-hosted सर्व्हरवर अशी परिस्थिती वारंवार येते. विनंती upstream कडे पाठवण्यापूर्वी तुमचा reverse proxy SSO server कडे ती विनंती अनुमत आहे का, हे विचारतो. त्यामागील अॅपला SSO बद्दल काहीही माहिती नसते. त्याला proxy ने आधीच तपासलेल्या विनंत्या मिळतात. सहसा username header मध्ये दिलेले असते.

authentik च्या proxy provider मध्ये यासाठी दस्तऐवजीकरण केलेले 3 modes आहेत. "Proxy" mode मध्ये authentik outpost स्वतः upstream अॅपकडे traffic पाठवतो. "Forward auth (single application)" mode मध्ये traffic तुमच्या विद्यमान reverse proxy कडेच राहतो आणि authentik फक्त authentication check साठी वापरले जाते. "Forward auth (domain level)" mode मध्ये एका parent domain अंतर्गत असलेल्या प्रत्येक अॅपचे संरक्षण एकाच provider द्वारे होते. Domain level हा सोयीचा पर्याय आहे. त्याला दस्तऐवजीकरणात एक मर्यादा दिली आहे: तो "cannot enforce different application-level authorization rules for each protected application". त्यामुळे त्या domain अंतर्गत असलेल्या सर्व अॅप्ससाठी policy चा एकच संच लागू होतो.

Keycloak मध्ये यापैकी कोणतीही सुविधा नाही. त्याचा companion proxy Keycloak Gatekeeper चे नाव बदलून Louketo Proxy करण्यात आले. त्यानंतर GitHub वर तो archived करण्यात आला. त्याचा शेवटचा commit August 2023 मध्ये होता. OIDC support नसलेल्या अॅपचे संरक्षण करण्यासाठी त्याच्या समोर स्वतंत्र component चालवावा लागतो. सहसा oauth2-proxy वापरले जाते आणि ते Keycloak client कडे निर्देशित केले जाते. Zitadel मध्येही स्वतःचा forward auth mode नाही. त्यामुळे तिथेही install, monitor आणि upgrade करण्यासाठी तोच अतिरिक्त component वापरावा लागतो.

Reverse proxy configuration साधी राहात नाही, ते याच अतिरिक्त hop मुळे. त्यामुळे त्यात auth middleware जोडण्यापूर्वी अनेक Docker Compose अॅप्ससमोर Traefik कसे ठेवावे हे वाचा.

अपग्रेडची प्रक्रिया किती कठीण आहे?

August 2026 पर्यंत सध्याच्या 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." पुढील major version वर जाण्यापूर्वी सध्याच्या version मधील latest patch वर upgrade करा. तसेच "authentik does not support downgrading". Calendar-versioned project मध्ये एक वर्ष मागे राहिल्यास एक upgrade अनेक टप्प्यांच्या साखळीत बदलतो. प्रत्येक टप्प्यात स्वतंत्र database migration असते.

Keycloak च्या upgrade guide मध्ये अनुसरण्याचा क्रम दिला आहे: मागील version पासून झालेले migration changes तपासा, server upgrade करा आणि त्यानंतर adapters upgrade करा. Database migration आपोआप चालते. किंवा ती export करून manually लागू करता येते. बदल लागू होण्यापूर्वी ते वाचायचे असल्यास हा पर्याय उपयुक्त ठरतो. Keycloak मधील खर्चाचा भाग म्हणजे हे वाचन. त्याच्या release notes मध्ये deprecations आणि behaviour changes असतात. ते सहज वगळले जाऊ शकतात आणि लक्षात न आल्यास त्यांची किंमत मोठी ठरू शकते.

Zitadel त्याचे init आणि setup phases चालू server पासून वेगळे ठेवते. Scaling मुळे setup work पुन्हा होऊ नये म्हणून production guidance मध्ये ही phases वेगळी ठेवण्याची शिफारस केली आहे. एका single VPS वर याचा अर्थ साधारणपणे असा होतो की API healthy स्थिती कळवण्यापूर्वी 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 memory द्यावी लागते. कंपनीसाठी तयार केलेले realm model शिकावे लागते. आणि प्रत्यक्षात आवश्यक असलेल्या अॅप्ससाठी oauth2-proxy तरीही install करावे लागते.

authentik हा self-hosting करणाऱ्या वापरकर्त्यांसाठी तयार केला आहे आणि त्याची feature list हे स्पष्ट करते. तो forward auth आणि LDAP provider देतो. तसेच visual editor मध्ये login flows तयार करता येतात. मात्र vendor support contract किंवा दर काही आठवड्यांनी बदलत नसलेला release train आवश्यक असेल, तर तो कमी पडतो. Calendar versioning, downgrade path नसणे आणि version skipping ला support नसणे यामुळे प्रत्यक्ष ऑपरेशनल काम वाढते. तुमची खरी समस्या एक OIDC client इतकीच असताना flow editor शिकण्यासाठी संपूर्ण model समजून घ्यावे लागते.

Zitadel हा developers साठी तयार केला आहे. ते developers स्वतः release करत असलेल्या product मध्ये authentication समाविष्ट करतात. त्यात मजबूत API आणि first-class features म्हणून multi-tenancy आहेत. मात्र याच परिस्थितीत तो कमी पडतो. एका VPS वर password manager आणि wiki यांच्या मागे चार containers चालवायचे असतील आणि forward auth उपलब्ध नसेल, तर 4 GB per core प्रमाणे आकारलेला database योग्य रचना ठरत नाही.

एका VPS वर मी काय चालवेन आणि कसे

एका VPS वर तीन किंवा चार self-hosted अॅप्स असतील, तर authentik चालवा. तिन्ही पर्यायांमध्ये login screen मिळते. निर्णायक मुद्दा असा आहे की तुमच्या काही अॅप्समध्ये OIDC साठी समर्थन कधीच येणार नाही. authentik मध्ये forward auth अंगभूत आहे. त्यामुळे त्याच्या बाजूला आणखी एक component ठेवण्याची गरज पडत नाही.

शक्य असल्यास त्याला 4 GB द्या. त्याच्या शेजारील अॅप्स लहान असतील तरच 2 GB द्या. port 9000 सार्वजनिक इंटरनेटपासून दूर ठेवा आणि समोरील reverse proxy वर TLS termination करा. दररोज रात्री PostgreSQL dumps घ्या आणि ते सर्व्हरच्या बाहेर साठवा. Backup नसलेला identity provider त्यामागील प्रत्येक अॅपसाठी single point of failure ठरतो. Stack root म्हणून न चालवता dedicated unprivileged account म्हणून चालवा: VPS वर least privilege वापरकर्ते सेट करणे या लेखात आवश्यक account आणि file ownership ची माहिती दिली आहे.

तुम्ही संरक्षित करत असलेल्या प्रत्येक अॅपमध्ये OIDC किंवा SAML साठी आधीपासून समर्थन असल्यास, किंवा Keycloak realms देत असलेले सूक्ष्म role model आवश्यक असल्यास Keycloak निवडा. इतर लोकांनी sign up करावा असे application तयार करत असाल आणि त्यासाठी त्याचे API व tenant model हवे असेल, तर Zitadel निवडा. या दोन्ही पर्यायांचा संबंध या लेखातील एका box वर तीन अॅप्स चालवण्याच्या परिस्थितीशी नाही.

तुम्हाला प्रथम आढळणाऱ्या अपयशाच्या स्थिती

रीस्टार्टनंतर Keycloak मध्ये कोणताही डेटा दिसत नाही. तुम्ही ते start-dev सह सुरू केले. यात स्थानिक development database वापरला जातो. volume नसलेल्या container मध्ये container काढल्यास realm देखील काढला जातो. start वर जा आणि KC_DB=postgres द्वारे खऱ्या database कडे निर्देश करा.

लहान मशीनवर authentik worker container नाहीसा होतो. worker आणि server एकच image वापरतात आणि दोन्ही Python processes चालवतात. त्याच वेळी PostgreSQL ला 2 GB host मधील स्वतःचा हिस्सा आवश्यक असतो. कोणती service बंद झाली हे निश्चित करण्यासाठी docker compose ps चालवा. त्यानंतर app मधील bug शोधण्यापूर्वी out-of-memory मुळे process बंद झाला आहे का हे पाहण्यासाठी dmesg तपासा.

तुमच्या proxy मागे Zitadel's Console कार्य करत नाही. Zitadel API gRPC वापरते. त्यामुळे upstream पर्यंत संपूर्ण मार्गावर HTTP/2 आवश्यक असतो. Requirements page मध्ये HTTP/2 upstream connections समर्थित करणारा 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 देतो जी load होते, पण Console कार्य करत नाही.

प्रत्येक app तुम्हाला पुन्हा login screen कडे पाठवते. SSO server ची public URL आणि app मध्ये configure केलेली URL scheme आणि port यांसह तंतोतंत जुळली पाहिजे. Keycloak याला hostname setting म्हणते, तर Zitadel याला external domain म्हणते. दोन्ही वेगवेगळे असल्यास app अशा login कडे redirect करते ज्याला server स्वतःची URL म्हणून ओळखत नाही. त्यामुळे browser दोन्ही URL दरम्यान सतत redirect होत राहतो.

FAQ

2 GB VPS साठी यापैकी कोणता योग्य आहे?

authentik आणि Keycloak. authentik साठी किमान 2 CPU cores आणि 2 GB RAM असलेला host आवश्यक असल्याचे नमूद केले आहे. Keycloak च्या sizing guide नुसार database वगळून server साठी base memory 1250 MB आहे. तुम्ही संरक्षित करत असलेले apps जोडल्यावर 2 GB मध्ये दोन्हींची क्षमता मर्यादित राहते. त्यामुळे 4 GB ही व्यवहार्य किमान क्षमता माना. Zitadel पहिल्या run साठी 2 GB प्रकाशित करते. मात्र त्याच्या production मार्गदर्शकानुसार password hashing साठी 4 CPU cores आणि प्रत्येक database core साठी 4 GB RAM आवश्यक आहे. त्यामुळे 2 GB वर प्रत्यक्ष deployment करणे योग्य नाही.

स्वतःचे login नसलेल्या app चे संरक्षण Keycloak किंवा Zitadel करू शकतात का?

स्वतःहून नाही. यापैकी कोणतेही product forward auth component सह येत नाही. Keycloak चा जुना companion proxy, Louketo Proxy, GitHub वर archived आहे आणि त्याचा शेवटचा commit August 2023 मध्ये झाला. त्यामुळे त्यावर आधारित नवीन रचना करू नका. तुमच्या reverse proxy आणि app यांच्या मध्ये oauth2-proxy किंवा तत्सम component ठेवा. त्याला SSO server वरील OIDC client कडे निर्देशित करा. authentik मध्ये हे मूळतः उपलब्ध आहे. त्याच्या proxy provider मध्ये "Forward auth (single application)" किंवा "Forward auth (domain level)" mode वापरा.

केवळ LDAP बोलणाऱ्या app साठी LDAP server म्हणून कोणते product वापरता येते?

authentik. त्याचा LDAP provider outpost वर चालतो. त्यामुळे authentik मधील users आणि groups LDAP द्वारे शोधता येतात. LDAPS port 636 वर उपलब्ध आहे. हा provider read-only आहे. त्यामुळे bind आणि search कार्य करतात; writes कार्य करत नाहीत. Keycloak आणि Zitadel याउलट कार्य करतात. दोन्ही user source म्हणून विद्यमान LDAP directory मधून माहिती वाचतात. यापैकी कोणतेही product app कडून आलेल्या LDAP bind ला उत्तर देत नाही.

authentik upgrade करताना versions वगळता येतात का?

नाही. Documentation नुसार upgrade major releases च्या क्रमाने करणे आवश्यक आहे. जुन्या major version वरून थेट सर्वात अलीकडील version वर जाऊ नये. प्रत्येक version मधील latest patch release वर प्रथम जा. त्यानंतर एका वेळी एक version पुढे जा. प्रत्येक टप्प्यापूर्वी PostgreSQL चा backup घ्या. authentik downgrade समर्थित करत नाही. तसेच migrations फक्त पुढील दिशेने चालतात.