Keycloak vs authentik vs Zitadel: एक VPS के लिए सही चुनाव

एक VPS के लिए कौन सा SSO सर्वर उपयुक्त है

Keycloak, authentik और Zitadel ऐसे self-hosted single sign-on (SSO) सर्वर हैं जो तब चर्चा में आते हैं जब कोई अपने सर्वर पर मौजूद सभी apps के लिए एक ही login चाहता है। एक छोटे VPS पर ये एक-दूसरे के विकल्प नहीं हो सकते। authentik उन सर्वर के लिए एक सुरक्षित विकल्प है जहाँ तीन या चार self-hosted apps चल रहे हों, क्योंकि यह इन तीनों में एकमात्र ऐसा विकल्प है जो किसी ऐसी app के सामने login screen लगा सकता है जिसमें अपना कोई login सिस्टम नहीं है। Keycloak तब सही विकल्प है जब आपकी सुरक्षित की जाने वाली प्रत्येक app पहले से ही किसी standard protocol का समर्थन करती हो और आप Java virtual machine (JVM) के लिए आवश्यक memory दे सकें। Zitadel को उन developers के लिए बनाया गया है जो API के माध्यम से कोई product release कर रहे हैं, और मैं इसे 4 GB RAM से कम वाले सर्वर पर इस्तेमाल करने की सलाह नहीं दूँगा।

पहले चुनाव करें, फिर install करें। एक बार चुनाव कर लेने के बाद, VPS पर authentik install करने की व्यावहारिक मार्गदर्शिका में setup के चरणों को विस्तार से समझाया गया है।

प्रत्येक को वास्तव में कितनी RAM की आवश्यकता है?

संसाधन की न्यूनतम सीमा (resource floor) से शुरुआत करें, क्योंकि किसी भी फीचर से पहले यही तय करता है कि कौन सा विकल्प shortlist में रहेगा। नीचे दिए गए आंकड़े प्रत्येक प्रोजेक्ट द्वारा प्रकाशित किए गए हैं, जिन्हें अगस्त 2026 में देखा गया था। ये वेंडर के सुझाव हैं, न कि लोड टेस्ट के परिणाम।

[
  {
    "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 इंस्टॉलेशन पेज "कम से कम 2 CPU कोर और 2 GB RAM वाले होस्ट" की मांग करता है, जो कि 2048 MB है। इसकी प्रकाशित compose फाइल 3 कंटेनर चलाती है: PostgreSQL, सर्वर और वर्कर।

Keycloak 3 का सबसे सटीक आंकड़ा प्रकाशित करता है। इसकी साइजिंग गाइड बताती है कि "Realm डेटा के कैश और 10,000 कैश किए गए सत्रों (sessions) सहित एक Pod के लिए आधार मेमोरी उपयोग 1250 MB RAM है"। ये 1250 MB केवल Java प्रोसेस के लिए हैं, डेटाबेस से पहले। वही पेज बताता है कि कंटेनर लिमिट क्यों महत्वपूर्ण है: Keycloak मेमोरी लिमिट का 70% हिस्सा heap के रूप में लेता है और उसके ऊपर लगभग 300 MB गैर-heap मेमोरी का उपयोग करता है। यदि आप कंटेनर को 1 GB देते हैं, तो यह लगभग 717 MB का heap बनाता है और साथ ही 300 MB गैर-heap मेमोरी की आवश्यकता होती है, इसलिए किसी भी सत्र डेटा के कैश में आने से पहले ही लिमिट समाप्त हो जाती है।

Zitadel का compose पेज भी 2 GB की मांग करता है, जो कि 2048 MB है, लेकिन यह आंकड़ा केवल पहली बार चलाने के लिए है। आपको इसके प्रोडक्शन पेज को पढ़ना चाहिए। Zitadel प्रोसेस को स्वयं "लगभग 512 MB RAM की आवश्यकता होती है और यह एक CPU कोर से कम पर भी काम कर सकता है"। डेटाबेस सबसे महंगा हिस्सा है: "प्रति 100 अनुरोध प्रति सेकंड (req/s) के लिए लगभग एक CPU कोर और प्रति कोर 4 GB RAM"। पासवर्ड हैशिंग के लिए "इस उद्देश्य हेतु 4 CPU कोर उपलब्ध" होने चाहिए, क्योंकि लॉगिन का अचानक बढ़ना CPU स्पाइक का कारण बनता है। आधिकारिक v4 compose में कुछ भी जोड़ने से पहले 4 कंटेनर चलते हैं: प्रॉक्सी के रूप में Traefik, Zitadel API, एक अलग Login UI कंटेनर और PostgreSQL। Redis और OpenTelemetry कलेक्टर वैकल्पिक compose प्रोफाइल के पीछे होते हैं।

इसलिए Keycloak और authentik 4 GB के VPS पर उन ऐप्स के लिए जगह छोड़कर फिट हो सकते हैं जिनकी आप सुरक्षा कर रहे हैं। Zitadel 2 GB पर शुरू तो हो जाएगा, लेकिन हर लॉगिन पर मेमोरी के लिए अपने ही PostgreSQL के साथ प्रतिस्पर्धा करेगा। मैं Zitadel को 4 GB से कम पर नहीं चलाऊंगा, और यदि किसी ऐसे सर्वर पर जहाँ अन्य ऐप्स भी होस्ट हैं, तो मुझे 8 GB की आवश्यकता होगी।

आपके सर्वर पर प्रत्येक का संचालन

authentik में PostgreSQL के साथ एक ही इमेज की दो प्रतियां होती हैं, एक सर्वर और एक वर्कर। सर्वर HTTP अनुरोधों का उत्तर देता है और इसमें एक एम्बेडेड आउटपोस्ट होता है। वर्कर बैकग्राउंड कार्य जैसे डायरेक्टरी सिंक और ईमेल चलाता है। प्रकाशित इंस्टॉलेशन संक्षिप्त है।

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

सर्वर 9000 और 9443 पोर्ट प्रकाशित करता है। पोर्ट 9000 पर पहली बार जाने पर प्रारंभिक सेटअप फ्लो चलता है, जहाँ आप डिफ़ॉल्ट akadmin उपयोगकर्ता के लिए पासवर्ड सेट करते हैं। इंटरनेट से उस पोर्ट तक पहुँचने से पहले उसके सामने एक वास्तविक सर्टिफिकेट वाला रिवर्स प्रॉक्सी लगाएँ।

Keycloak एक प्रोसेस और आपके द्वारा प्रदान किए गए डेटाबेस का संयोजन है। क्विकस्टार्ट एक सिंगल कंटेनर है।

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 केवल देखने के लिए है। यह एक स्थानीय डेवलपमेंट डेटाबेस के साथ चलता है और इसमें कोई TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) नहीं होता है, इसलिए इस तरह शुरू किया गया और बाद में हटाया गया कंटेनर आपके रीयल्म (realm) को भी हटा देता है। प्रोडक्शन का अर्थ है start का उपयोग करना, जिसमें KC_DB के माध्यम से एक वास्तविक PostgreSQL और KC_HOSTNAME के माध्यम से एक सार्वजनिक होस्टनाम होता है। Keycloak की प्रोडक्शन गाइड यह भी बताती है कि सर्वर से आने-जाने वाले सभी संचार के लिए एक सुरक्षित चैनल की आवश्यकता होती है, इसलिए वहां HTTPS वैकल्पिक नहीं है।

Zitadel ऊपर वर्णित चार-कंटेनर वाला स्टैक है।

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 सेट करें। यह 32 कैरेक्टर की वह कुंजी है जिसका उपयोग Zitadel डेटाबेस में सीक्रेट्स को एन्क्रिप्ट करने के लिए करता है, इसलिए इसे खोने का मतलब है उन सीक्रेट्स तक पहुंच खो देना। यदि आप इस तरह के स्टैक चलाने में नए हैं, तो VPS के लिए Docker Compose की बुनियादी बातें उन वॉल्यूम और रीस्टार्ट-पॉलिसी विकल्पों को कवर करती हैं जो यह तय करते हैं कि आपका आइडेंटिटी प्रोवाइडर रीबूट के बाद सुरक्षित रहेगा या नहीं।

प्रत्येक कौन से प्रोटोकॉल का उपयोग करता है?

ये तीनों OpenID Connect (OIDC) का उपयोग करते हैं, जो OAuth 2.0 के ऊपर स्थित लॉगिन लेयर है जिसका उपयोग आधुनिक ऐप्स करते हैं, और ये तीनों SAML 2.0 (security assertion markup language) का भी उपयोग करते हैं, जो कि एक पुराना मानक है जिसे एंटरप्राइज सॉफ्टवेयर आज भी सपोर्ट करता है। मुख्य अंतर LDAP (lightweight directory access protocol) में है, जहाँ एक शब्द दो विपरीत कार्यों को दर्शाता है।

LDAP से पढ़ना (Reading from LDAP) का अर्थ है कि SSO सर्वर आपके द्वारा पहले से चलाए जा रहे डायरेक्टरी के विरुद्ध पासवर्ड की जाँच करता है। Keycloak इसे user federation के माध्यम से करता है। Zitadel भी ऐसा ही करता है: इसका डॉक्यूमेंटेशन बताता है कि कैसे "ZITADEL में एक identity provider के रूप में LDAP सर्वर को कनेक्ट करें"।

LDAP सर्व करना (Serving LDAP) का अर्थ है कि कोई ऐप जो केवल LDAP समझता है, वह आपके SSO सर्वर के साथ ऐसे bind हो सकता है जैसे कि वह स्वयं एक डायरेक्टरी हो। केवल authentik ऐसा करता है। इसका LDAP provider एक समर्पित LDAP outpost के माध्यम से "authentik के डेटाबेस में मौजूद सभी users और groups को LDAP डायरेक्टरी के जरिए खोजने योग्य" बनाता है, जिसमें port 636 पर LDAPS उपलब्ध होता है। यह read-only है, इसलिए bind और search कार्य करते हैं लेकिन write कार्य नहीं करते। पासवर्ड के अंत में एक semicolon के साथ एक one-time code जोड़ा जाता है, जैसा कि password;123456 में है, और bind के दौरान SMS authenticators समर्थित नहीं हैं।

यदि आपकी सूची का कोई ऐप केवल LDAP का उपयोग करता है, तो तुलना वहीं समाप्त हो जाती है। Keycloak और Zitadel उस bind का उत्तर नहीं दे सकते, इसलिए आपको उनके साथ एक दूसरी डायरेक्टरी चलानी होगी और दो user lists को सिंक में रखना होगा।

जिन ऐप्स में कोई लॉगिन ही नहीं है, उनका क्या?

Forward auth इसका समाधान है, और यह एक ऐसी स्थिति है जिसका सामना self-hosted सर्वर पर लगातार होता है। आपका reverse proxy upstream पर request भेजने से पहले SSO सर्वर से पूछता है कि क्या यह request मान्य है। इसके पीछे चल रहे ऐप को SSO के बारे में कुछ पता नहीं चलता। उसे ऐसी requests प्राप्त होती हैं जिन्हें proxy पहले ही जांच चुका होता है, आमतौर पर header में username के साथ।

authentik का proxy provider इसे तीन documented modes के साथ कवर करता है। "Proxy" में authentik outpost खुद traffic को upstream ऐप तक भेजता है। "Forward auth (single application)" में traffic आपके मौजूदा reverse proxy के पास ही रहता है और authentik का उपयोग केवल authentication जांच के लिए किया जाता है। "Forward auth (domain level)" एक ही parent domain के अंतर्गत आने वाले हर ऐप को एक ही provider के साथ सुरक्षित करता है। Domain level सबसे सुविधाजनक है और इसकी एक documented सीमा है: यह "प्रत्येक सुरक्षित एप्लिकेशन के लिए अलग-अलग एप्लिकेशन-स्तरीय प्राधिकरण नियम लागू नहीं कर सकता", इसलिए उस domain के अंतर्गत आने वाले सभी ऐप्स एक ही policy set साझा करते हैं।

Keycloak में ऐसा कुछ नहीं है। इसके companion proxy, Keycloak Gatekeeper का नाम बदलकर Louketo Proxy कर दिया गया था और फिर इसे GitHub पर archive कर दिया गया, जिसका आखिरी commit अगस्त 2023 में था। OIDC सपोर्ट के बिना किसी ऐप को सुरक्षित करने के लिए आप उसके सामने एक अलग component चलाते हैं, आमतौर पर oauth2-proxy, जिसे Keycloak client की ओर point किया जाता है। Zitadel में भी अपना कोई forward auth mode नहीं है, इसलिए वहां भी समाधान वही है कि एक अतिरिक्त component इंस्टॉल, मॉनिटर और अपग्रेड किया जाए।

वह अतिरिक्त hop ही वह बिंदु है जहां reverse proxy configuration सरल नहीं रह जाती, इसलिए Traefik कई Docker Compose ऐप्स को कैसे संभालता है इसे जरूर पढ़ें, इससे पहले कि आप इसमें कोई auth middleware जोड़ें।

अपग्रेड पाथ कितना कठिन है?

अगस्त 2026 तक, वर्तमान releases Keycloak 26.7.1, authentik 2026.5.6 और Zitadel v4.16.3 हैं। ये तीनों PostgreSQL पर schema migrations चलाते हैं, जिसका अर्थ है कि प्रत्येक अपग्रेड एक डेटाबेस परिवर्तन है। हर बार, सबसे पहले डेटाबेस का बैकअप लें। यह एक आदत इस तुलना में किसी भी फीचर से अधिक मूल्यवान है।

authentik के नियम सबसे सख्त हैं और वे इसे स्पष्ट रूप से बताते हैं: "अपग्रेड को प्रमुख releases के क्रम का पालन करना चाहिए; सीधे पुराने major version से नवीनतम version पर न जाएं।" आपको अगले version पर जाने से पहले प्रत्येक version के भीतर नवीनतम patch पर जाना होगा, और "authentik downgrading का समर्थन नहीं करता है"। कैलेंडर-आधारित versioning वाले प्रोजेक्ट में एक साल पीछे रह जाने पर एक अपग्रेड, अपग्रेड की एक श्रृंखला में बदल जाता है, जिसमें प्रत्येक का अपना डेटाबेस माइग्रेशन होता है।

Keycloak की अपग्रेड गाइड पालन करने के लिए एक क्रम देती है: पिछले version से माइग्रेशन परिवर्तनों की समीक्षा करें, सर्वर को अपग्रेड करें, फिर एडेप्टर को अपग्रेड करें। डेटाबेस माइग्रेशन स्वचालित रूप से चलता है, या आप इसे export करके मैन्युअल रूप से लागू कर सकते हैं, जो तब उपयोगी होता है जब आप परिवर्तन लागू होने से पहले उसे पढ़ना चाहते हैं। Keycloak के साथ लागत उस पढ़ने की प्रक्रिया में है। इसके release notes में deprecations और व्यवहार संबंधी परिवर्तन होते हैं जिन्हें छोड़ना आसान है और अनदेखा करना महंगा पड़ता है।

Zitadel अपने init और setup चरणों को रनिंग सर्वर से अलग रखता है, और इसके प्रोडक्शन मार्गदर्शन में उन्हें अलग रखने की सलाह दी जाती है ताकि स्केलिंग के दौरान सेटअप का काम बार-बार न हो। एक सिंगल VPS पर इसका मुख्य अर्थ यह है कि API के healthy होने की रिपोर्ट करने से पहले सेटअप चरण पूरा हो जाना चाहिए, यही कारण है कि compose file में health checks शामिल हैं और start कमांड --wait का उपयोग करती है।

प्रत्येक प्रोजेक्ट किसके लिए बनाया गया है, और कहाँ प्रत्येक विफल होता है

Keycloak Red Hat का identity server है, जिसे realms, groups, role mappings और मौजूदा corporate directory वाली संस्थाओं के लिए बनाया गया है। यह इन तीनों में सबसे पूर्ण standards implementation है। यह 2 GB VPS पर विफल हो जाता है जहाँ चार self-hosted apps चल रहे हों और उनमें से आधे में OIDC support न हो। आप JVM के लिए 1250 MB खर्च करते हैं, एक कंपनी के लिए डिज़ाइन किया गया realm model सीखते हैं, और फिर भी उन apps के लिए oauth2-proxy इंस्टॉल करते हैं जिनकी आपको वास्तव में परवाह थी।

authentik को self-hosting करने वाले उपयोगकर्ताओं के लिए बनाया गया है, और feature list इसे दर्शाती है। यह forward auth और LDAP provider के साथ आता है, और यह visual editor में login flows बनाता है। यह तब विफल होता है जब आपको vendor support contract की आवश्यकता हो या ऐसी release train की जो हर कुछ हफ्तों में न बदले। बिना downgrade path और बिना version skipping के calendar versioning एक वास्तविक operational कार्य है, और flow editor सीखने के लिए एक पूरा model है जबकि आपकी वास्तविक समस्या केवल एक OIDC client है।

Zitadel को उन डेवलपर्स के लिए बनाया गया है जो अपने द्वारा बेचे जाने वाले product में authentication जोड़ते हैं, जिसमें एक मजबूत API और multi-tenancy प्रथम-श्रेणी की विशेषताएं हैं। यह ठीक इसी मामले में विफल होता है। चार containers, कोई forward auth नहीं, और प्रति core 4 GB की database size, एक ऐसे VPS के लिए गलत ढांचा है जिसके पीछे एक password manager और एक wiki चल रहा हो।

एक VPS पर क्या चलाएं और कैसे

तीन या चार self-hosted applications वाले एक VPS के लिए, authentik चलाएं। ये तीनों ही आपको एक login screen प्रदान करते हैं। निर्णायक कारक यह है कि आपकी कुछ applications कभी भी OIDC का उपयोग नहीं करेंगी, और authentik इसके लिए एक अलग component के बजाय built-in forward auth की सुविधा देता है।

यदि संभव हो तो इसे 4 GB RAM दें, और केवल तभी 2 GB दें यदि इसके साथ चलने वाली applications छोटी हों। port 9000 को public internet से दूर रखें और इसके सामने एक reverse proxy पर TLS termination करें। हर रात PostgreSQL के dumps लें और उन्हें server से बाहर कहीं store करें, क्योंकि बिना backup वाला identity provider उन सभी applications के लिए single point of failure बन जाता है जो इसके पीछे चल रही हैं। इस stack को root के बजाय एक dedicated unprivileged account के रूप में चलाएं: VPS पर least privilege users सेट करना इस प्रक्रिया के लिए आवश्यक account और file ownership को कवर करता है।

Keycloak तब चुनें जब आपके द्वारा सुरक्षित की जाने वाली हर application पहले से ही OIDC या SAML का समर्थन करती हो, या जब आपको Keycloak realms द्वारा प्रदान किए जाने वाले सूक्ष्म (fine-grained) role model की आवश्यकता हो। Zitadel तब चुनें जब आप दूसरों के sign up करने के लिए कोई application बना रहे हों और आपको इसके API तथा tenant model की आवश्यकता हो। इनमें से कोई भी उस 'एक box पर तीन-apps' वाले मामले के लिए नहीं है जिसके बारे में यह post है।

वे विफलता मोड जिनका आप सबसे पहले सामना करेंगे

Restart के बाद Keycloak में कोई डेटा नहीं है। आपने इसे start-dev के साथ शुरू किया था, जो एक local development database का उपयोग करता है। बिना volume वाले container में, container को हटाने से realm भी हट जाता है। start पर जाएँ और KC_DB=postgres को एक वास्तविक database की ओर point करें।

छोटे सर्वर पर authentik worker container गायब हो जाता है। worker और server एक ही image चलाते हैं और दोनों में Python processes होती हैं, और PostgreSQL को 2 GB host का अपना हिस्सा चाहिए होता है। यह पुष्टि करने के लिए कि कौन सी service exit हुई है, docker compose ps चलाएँ, फिर ऐप में बग खोजने से पहले out-of-memory kill के लिए dmesg की जाँच करें।

Zitadel का Console आपके proxy के पीछे काम नहीं करता है। Zitadel API gRPC का उपयोग करता है, जिसे upstream तक HTTP/2 की आवश्यकता होती है। requirements page ऐसे reverse proxy की मांग करती है जो HTTP/2 upstream connections का समर्थन करता हो और इसमें Traefik v3.x, NGINX v1.x, Caddy v2.x और Apache httpd 2.4.x के tested versions का उल्लेख है। जो proxy upstream connection को HTTP/1.1 पर downgrade कर देता है, वह आपको एक login page तो देता है जो load हो जाता है, लेकिन Console विफल हो जाता है।

हर ऐप आपको वापस login screen पर भेज देता है। SSO server का public URL और ऐप में configure किया गया URL बिल्कुल मेल खाना चाहिए, जिसमें scheme और port भी शामिल हैं। Keycloak इसे hostname setting कहता है, Zitadel इसे external domain कहता है। जब वे मेल नहीं खाते, तो ऐप ऐसे login पर redirect करता है जिसे server अपना नहीं मानता, और browser दोनों के बीच bounce करता रहता है।

FAQ

2 GB VPS के लिए इन तीनों में से कौन सा उपयुक्त है?

authentik और Keycloak। authentik की निर्धारित आवश्यकता कम से कम 2 CPU cores और 2 GB RAM वाला host है, और Keycloak की sizing guide के अनुसार database को छोड़कर सर्वर के लिए आधारभूत memory 1250 MB है। जिन apps को आप सुरक्षित कर रहे हैं, उन्हें जोड़ने के बाद 2 GB पर दोनों ही बहुत सीमित हो जाते हैं, इसलिए 4 GB को एक आरामदायक न्यूनतम सीमा मानें। Zitadel पहली बार चलाने के लिए 2 GB का सुझाव देता है, लेकिन production के लिए इसके दिशा-निर्देशों में password hashing के लिए 4 CPU cores और प्रति database core 4 GB RAM की मांग की गई है, इसलिए 2 GB एक वास्तविक deployment नहीं है।

क्या Keycloak या Zitadel किसी ऐसी app को सुरक्षित कर सकते हैं जिसका अपना कोई login नहीं है?

स्वयं नहीं। इनमें से कोई भी forward auth component के साथ नहीं आता है। Keycloak का पुराना companion proxy, Louketo Proxy, GitHub पर archived है और इसका अंतिम commit अगस्त 2023 में था, इसलिए इस पर निर्भर रहना उचित नहीं है। आप अपने reverse proxy और app के बीच oauth2-proxy या इसी तरह का कोई component लगा सकते हैं और उसे SSO सर्वर पर मौजूद OIDC client की ओर point कर सकते हैं। authentik इसे अपने proxy provider के माध्यम से "Forward auth (single application)" या "Forward auth (domain level)" mode में natively करता है।

कौन सा विकल्प ऐसी app के लिए LDAP सर्वर के रूप में कार्य कर सकता है जो केवल LDAP समझती है?

authentik। इसका LDAP provider एक outpost पर चलता है और authentik में मौजूद users और groups को LDAP के माध्यम से खोजने योग्य बनाता है, जिसमें port 636 पर LDAPS उपलब्ध रहता है। यह read-only है, इसलिए bind और search कार्य करते हैं जबकि writes नहीं होते। Keycloak और Zitadel विपरीत दिशा में कार्य करते हैं: दोनों ही user source के रूप में मौजूदा LDAP directory से पढ़ते हैं, और कोई भी किसी application से आने वाले LDAP bind का उत्तर नहीं देता है।

क्या मैं authentik upgrade करते समय versions छोड़ सकता हूँ?

नहीं। documentation के अनुसार upgrades को major releases के क्रम का पालन करना चाहिए, और आपको किसी पुराने major version से सीधे सबसे हालिया version पर नहीं जाना चाहिए। पहले प्रत्येक version के भीतर latest patch release पर जाएँ, फिर एक-एक करके version बढ़ाएँ। प्रत्येक चरण से पहले PostgreSQL का backup लें, क्योंकि authentik downgrading को support नहीं करता है और migrations केवल आगे की ओर ही चलती हैं।