ایک VPS پر Keycloak، authentik یا Zitadel؟

ایک VPS کے لیے کون سا SSO server موزوں ہے

Keycloak، authentik اور Zitadel self-hosted single sign-on (SSO) servers ہیں۔ جب کوئی شخص اپنے server پر موجود ہر app کے لیے ایک ہی login چاہتا ہے تو عموماً یہی options سامنے آتے ہیں۔ ایک چھوٹے VPS پر یہ ایک دوسرے کے متبادل نہیں ہیں۔ تین یا چار self-hosted apps چلانے والے server کے لیے authentik محفوظ default ہے، کیونکہ ان تینوں میں صرف authentik ہی ایسی app کے سامنے login screen لگا سکتا ہے جس کا اپنا login موجود نہ ہو۔ Keycloak اس وقت درست انتخاب ہے جب جن apps کو آپ محفوظ کرنا چاہتے ہیں وہ پہلے ہی کسی standard protocol کو support کرتی ہوں، اور آپ Java virtual machine (JVM) کے لیے کافی memory دے سکتے ہوں۔ Zitadel ان developers کے لیے بنایا گیا ہے جو API کے ذریعے product جاری کرتے ہیں، اور 4 GB سے کم memory والے server پر میں اسے استعمال کرنے کی کوشش نہیں کروں گا۔

پہلے انتخاب کریں، پھر install کریں۔ انتخاب کے بعد، VPS پر authentik کی عملی installation میں setup کا مرحلہ وار طریقہ دیا گیا ہے۔

ہر ایک کو حقیقت میں کتنی RAM درکار ہوتی ہے؟

پہلے وسائل کی کم از کم ضرورت دیکھیں، کیونکہ کسی بھی feature سے پہلے یہی shortlist طے کرتی ہے۔ ذیل کے اعداد و شمار ہر project کے اپنے شائع کردہ figures ہیں، جنہیں 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 installation page پر "a host with at least 2 CPU cores and 2 GB of RAM" درکار ہے، یعنی 2048 MB، اور اس کی شائع کردہ compose file 3 containers چلاتی ہے: PostgreSQL، server، اور worker۔

Keycloak، 3 میں سب سے مخصوص figure شائع کرتا ہے۔ اس کی sizing guide کے مطابق، "the base memory usage for a Pod including caches of Realm data and 10,000 cached sessions is 1250 MB of RAM"۔ یہ 1250 MB صرف Java process کے لیے ہیں، database شامل نہیں ہے۔ اسی page پر یہ بھی بتایا گیا ہے کہ container limit اتنی اہم کیوں ہے: Keycloak memory limit کا 70% heap کے لیے لیتا ہے اور اس کے علاوہ تقریباً 300 MB non-heap memory استعمال کرتا ہے۔ اگر container کو 1 GB دیں تو یہ تقریباً 717 MB کا heap مقرر کرتا ہے، جبکہ اسے مزید 300 MB non-heap memory بھی درکار ہوتی ہے۔ اس طرح cache میں session data آنے سے پہلے ہی limit استعمال ہو جاتی ہے۔

Zitadel کے compose page پر بھی 2 GB، یعنی وہی 2048 MB، درکار ہیں، لیکن یہ figure پہلی run کے لیے ہے۔ اس کا production page زیادہ اہم ہے۔ خود Zitadel process کو "approximately 512MB of RAM and can operate with less than one CPU core" درکار ہے۔ مہنگا حصہ database ہے: "about one CPU core per 100 requests per second (req/s) and 4GB of RAM per core"۔ Password hashing کے لیے پھر "4 CPU cores available for this purpose" درکار ہوتے ہیں، کیونکہ login requests کا اچانک اضافہ CPU spike پیدا کرتا ہے۔ 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 بھی host کرتا ہو، میں 8 GB چاہوں گا۔

آپ کے سرور پر ہر ایک اصل میں کیا چلاتا ہے

authentik ایک PostgreSQL database اور ایک ہی image کی دو copies پر مشتمل ہے: ایک server اور ایک worker۔ server HTTP requests کا جواب دیتا ہے اور embedded outpost بھی چلاتا ہے۔ worker background tasks چلاتا ہے، جیسے directory syncs اور email delivery۔ شائع شدہ 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 publish کرتا ہے۔ port 9000 پر پہلی visit initial setup flow چلاتی ہے، جہاں آپ default akadmin user کا password مقرر کرتے ہیں۔ اس port کو internet سے reachable بنانے سے پہلے اس کے سامنے حقیقی certificate والا reverse proxy رکھیں۔

Keycloak ایک process اور آپ کے فراہم کردہ database پر مشتمل ہے۔ quickstart ایک single 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 مقرر کریں۔ یہ 32 character key ہے جسے Zitadel database میں secrets encrypt کرنے کے لیے استعمال کرتا ہے، اس لیے اسے کھو دینے کا مطلب ان secrets تک رسائی کھو دینا ہے۔ اگر آپ ایسی stacks چلانے میں نئے ہیں تو VPS کے لیے Docker Compose کی بنیادی باتیں ان volume اور restart-policy انتخاب کی وضاحت کرتی ہیں جو طے کرتے ہیں کہ reboot کے بعد آپ کا identity provider برقرار رہے گا یا نہیں۔

ہر ایک کون سے protocols استعمال کرتا ہے؟

تینوں 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 سے پڑھنے کا مطلب ہے کہ SSO server ان passwords کی directory کے خلاف تصدیق کرتا ہے جسے آپ پہلے سے چلا رہے ہیں۔ Keycloak یہ کام user federation کے ذریعے کرتا ہے۔ Zitadel بھی ایسا ہی کرتا ہے۔ اس کی documentation میں بتایا گیا ہے کہ "connect an LDAP server as an identity provider in ZITADEL"۔

LDAP فراہم کرنے کا مطلب ہے کہ ایسی app جو صرف LDAP استعمال کرتی ہو، آپ کے SSO server سے اس طرح bind کر سکے جیسے وہی directory ہو۔ یہ کام صرف authentik کرتا ہے۔ اس کا LDAP provider dedicated LDAP outpost کے ذریعے "all users and groups in authentik's database searchable via the LDAP directory" بناتا ہے، اور LDAPS port 636 پر دستیاب ہوتا ہے۔ یہ read-only ہے، اس لیے bind اور search کام کرتے ہیں، لیکن writes نہیں۔ ایک one-time code کو semicolon کے ذریعے password کے آخر میں شامل کیا جاتا ہے، جیسا کہ password;123456 میں ہے۔ bind کے دوران SMS authenticators supported نہیں ہیں۔

اگر آپ کی فہرست میں کوئی app صرف LDAP استعمال کرتی ہے تو موازنہ وہیں ختم ہو جاتا ہے۔ Keycloak اور Zitadel اس bind کا جواب نہیں دے سکتے۔ اس لیے آپ کو ان کے ساتھ دوسری directory چلانی ہوگی اور دو user lists کو ہم آہنگ رکھنا ہوگا۔

ایسی ایپس کے بارے میں کیا کیا جائے جن میں login بالکل نہیں ہوتا؟

اس کا حل forward auth ہے، اور self-hosted سرور پر یہ صورتِ حال بار بار پیش آتی ہے۔ آپ کا reverse proxy کسی request کو upstream تک بھیجنے سے پہلے SSO server سے پوچھتا ہے کہ آیا یہ request مجاز ہے۔ اس کے پیچھے موجود app کو SSO کے بارے میں کچھ معلوم نہیں ہوتا۔ اسے وہ requests موصول ہوتی ہیں جنہیں proxy پہلے ہی check کر چکا ہوتا ہے، عموماً header میں username کے ساتھ۔

authentik کا proxy provider اس مقصد کے لیے دستاویزی طور پر تین modes فراہم کرتا ہے۔ "Proxy" mode میں authentik outpost خود traffic کو upstream app تک پہنچاتا ہے۔ "Forward auth (single application)" mode میں traffic آپ کے موجودہ reverse proxy کے پاس رہتا ہے اور authentik صرف authentication check کے لیے استعمال ہوتا ہے۔ "Forward auth (domain level)" mode ایک parent domain کے تحت موجود ہر app کو ایک ہی provider کے ذریعے محفوظ بناتا ہے۔ Domain level آسان آپشن ہے، لیکن اس کی ایک دستاویزی حد ہے: یہ "ہر محفوظ app کے لیے مختلف application-level authorization rules نافذ نہیں کر سکتا"۔ اس لیے اس domain کے تحت ہر app ایک ہی policy set استعمال کرتی ہے۔

Keycloak میں اس مقصد کے لیے کوئی built-in طریقہ نہیں ہے۔ اس کا companion proxy، Keycloak Gatekeeper، بعد میں Louketo Proxy کے نام سے جاری ہوا اور پھر GitHub پر archived کر دیا گیا؛ اس کا آخری commit August 2023 میں تھا۔ OIDC support نہ رکھنے والی app کو محفوظ بنانے کے لیے اس کے سامنے ایک الگ component چلانا پڑتا ہے، عموماً oauth2-proxy، جسے Keycloak client کی طرف point کیا جاتا ہے۔ Zitadel میں بھی اپنا forward auth mode موجود نہیں، اس لیے وہاں بھی یہی حل ہے کہ ایک اضافی component install، monitor اور upgrade کیا جائے۔

یہ اضافی hop وہ مرحلہ ہے جہاں reverse proxy configuration سادہ نہیں رہتی۔ اس لیے auth middleware شامل کرنے سے پہلے دیکھیں کہ Traefik متعدد Docker Compose apps کے سامنے کیسے کام کرتا ہے۔

اپ گریڈ کا راستہ کتنا مشکل ہے؟

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." پہلے ہر version کے اندر latest patch تک upgrade کریں، پھر اگلے major version پر جائیں، اور "authentik does not support downgrading"۔ Calendar-versioned project میں ایک سال پیچھے رہ جانے سے ایک upgrade کئی مسلسل upgrades میں بدل جاتا ہے، اور ہر upgrade اپنی database migration کے ساتھ آتا ہے۔

Keycloak کی upgrade guide ایک مخصوص ترتیب دیتی ہے: پچھلے version سے ہونے والی migration changes کا جائزہ لیں، server کو upgrade کریں، پھر adapters کو upgrade کریں۔ Database migration خودکار طور پر چلتی ہے، یا آپ اسے export کرکے دستی طور پر apply کر سکتے ہیں۔ یہ اس وقت مفید ہے جب آپ تبدیلی کے نافذ ہونے سے پہلے اسے پڑھنا چاہتے ہوں۔ Keycloak کے ساتھ اصل لاگت یہی مطالعہ ہے۔ اس کے release notes میں deprecations اور behaviour changes شامل ہوتے ہیں، جنہیں نظرانداز کرنا آسان اور نہ پڑھنا مہنگا پڑ سکتا ہے۔

Zitadel اپنے init اور setup phases کو running server سے الگ رکھتا ہے، اور اس کی production guidance تجویز کرتی ہے کہ انہیں الگ رکھا جائے تاکہ scaling کے دوران setup کا کام دوبارہ نہ ہو۔ ایک 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 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 درکار ہو جو ہر چند ہفتوں بعد تبدیل نہ ہو، تو یہ کمزور پڑتا ہے۔ Calendar versioning، downgrade path کی عدم موجودگی، اور version skipping نہ کر سکنا حقیقی operational work بن جاتا ہے۔ جب آپ کا اصل مسئلہ صرف ایک OIDC client ہو، تو flow editor سیکھنے کے لیے ایک مکمل نیا model بن جاتا ہے۔

Zitadel ان developers کے لیے بنایا گیا ہے جو اپنی ship کی جانے والی product میں authentication شامل کرتے ہیں۔ اس میں مضبوط API ہے اور multi-tenancy کو first-class feature بنایا گیا ہے۔ لیکن اسی صورتِ حال میں یہ موزوں نہیں رہتا۔ چار containers، forward auth کی عدم موجودگی، اور ہر core کے لیے 4 GB کے حساب سے بنائی گئی database sizing، password manager اور wiki کو ایک VPS پر چلانے کے لیے غلط architecture ہے۔

ایک VPS پر میں کیا چلاؤں گا، اور کیسے

ایک VPS پر تین یا چار self-hosted ایپس کے لیے authentik چلائیں۔ تینوں آپشنز آپ کو login screen دیتے ہیں۔ فیصلہ کن بات یہ ہے کہ آپ کی کچھ ایپس کبھی OIDC استعمال نہیں کریں گی، اور authentik کسی اضافی component کے بجائے built-in forward auth کے ذریعے اس مسئلے کو حل کرتا ہے۔

اگر ممکن ہو تو اسے 4 GB دیں، اور 2 GB صرف اس صورت میں دیں جب اس کے ساتھ چلنے والی ایپس چھوٹی ہوں۔ port 9000 کو public internet سے دور رکھیں اور اس کے سامنے موجود reverse proxy پر TLS termination کریں۔ ہر رات PostgreSQL dumps بنائیں اور انہیں سرور سے باہر محفوظ کریں، کیونکہ backup کے بغیر identity provider اس کے پیچھے موجود ہر ایپ کے لیے single point of failure بن جاتا ہے۔ stack کو root کے بجائے dedicated unprivileged account کے طور پر چلائیں: VPS پر least privilege users ترتیب دینا میں اس کے لیے درکار account اور file ownership کا احاطہ کیا گیا ہے۔

Keycloak اس وقت منتخب کریں جب آپ کی حفاظت کی جانے والی ہر ایپ پہلے ہی OIDC یا SAML استعمال کرتی ہو، یا جب آپ کو Keycloak realms کی فراہم کردہ باریک سطح کے role model کی ضرورت ہو۔ Zitadel اس وقت منتخب کریں جب آپ دوسرے لوگوں کے sign up کرنے کے لیے application بنا رہے ہوں اور آپ کو اس کی API اور tenant model درکار ہو۔ ان دونوں میں سے کوئی بھی اس پوسٹ کے موضوع، یعنی ایک ہی box پر تین ایپس چلانے، کے لیے موزوں معاملہ نہیں ہے۔

آپ کو درپیش آنے والی ابتدائی failure modes

Restart کے بعد Keycloak میں کوئی data موجود نہیں رہتا۔ آپ نے اسے start-dev کے ساتھ شروع کیا تھا، جو local development database استعمال کرتا ہے۔ کسی volume کے بغیر container میں container ہٹانے سے realm بھی حذف ہو جاتا ہے۔ start پر منتقل ہوں اور KC_DB=postgres کو حقیقی database کی طرف configure کریں۔

چھوٹے host پر authentik worker container غائب ہو جاتا ہے۔ worker اور server ایک ہی image چلاتے ہیں اور دونوں Python processes رکھتے ہیں، جبکہ PostgreSQL کو 2 GB host میں اپنے حصے کی memory درکار ہوتی ہے۔ docker compose ps چلائیں تاکہ معلوم ہو سکے کہ کون سی service exit ہوئی، پھر dmesg میں out-of-memory kill تلاش کریں۔ اس کے بعد ہی ایپ میں bug تلاش کریں۔

Proxy کے پیچھے Zitadel کا Console کام نہیں کرتا۔ Zitadel API gRPC استعمال کرتی ہے، جس کے لیے upstream تک پورے راستے میں HTTP/2 درکار ہے۔ Requirements page ایسے reverse proxy کا تقاضا کرتی ہے جو upstream connections کے لیے HTTP/2 کو support کرے، اور 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 URL پر redirect ہوتی ہے جسے server اپنا URL تسلیم نہیں کرتا، اور browser دونوں کے درمیان مسلسل redirect ہوتا رہتا ہے۔

FAQ

2 GB VPS کے لیے ان تینوں میں سے کون سا موزوں ہے؟

authentik اور Keycloak۔ authentik کی بیان کردہ ضرورت کم از کم 2 CPU cores اور 2 GB RAM والا host ہے، جبکہ Keycloak کی sizing guide کے مطابق database کے بغیر server کے لیے بنیادی memory 1250 MB ہے۔ آپ کی محفوظ کی جانے والی apps شامل کرنے کے بعد 2 GB دونوں کے لیے بہت کم رہتی ہے، اس لیے 4 GB کو آرام دہ کم از کم حد سمجھیں۔ Zitadel پہلی بار چلانے کے لیے 2 GB شائع کرتا ہے، لیکن اس کی production guidance 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 August 2023 میں ہوا تھا۔ اس لیے اسے بنیاد بنا کر deployment تیار نہ کریں۔ اپنے reverse proxy اور app کے درمیان oauth2-proxy یا اسی نوعیت کا component رکھیں، اور اسے SSO server پر موجود OIDC client کی طرف point کریں۔ authentik یہ کام اپنے proxy provider کے ذریعے native طور پر کرتا ہے۔ اس کے لیے "Forward auth (single application)" یا "Forward auth (domain level)" mode استعمال کریں۔

ایسی app کے لیے، جو صرف LDAP سمجھتی ہو، LDAP server کے طور پر کون کام کر سکتا ہے؟

authentik۔ اس کا LDAP provider ایک outpost پر چلتا ہے اور authentik کے users اور groups کو LDAP کے ذریعے searchable بناتا ہے۔ LDAPS، port 636 پر دستیاب ہے۔ یہ read-only ہے، اس لیے bind اور search کام کرتے ہیں، لیکن writes نہیں ہو سکتیں۔ Keycloak اور Zitadel اس کے برعکس کام کرتے ہیں: دونوں کسی موجودہ LDAP directory سے user source کے طور پر data پڑھتے ہیں، اور دونوں میں سے کوئی بھی application کی جانب سے آنے والے LDAP bind کا جواب نہیں دیتا۔

کیا authentik کو upgrade کرتے وقت versions چھوڑ سکتا ہوں؟

نہیں۔ documentation کے مطابق upgrades کو major releases کی ترتیب میں مکمل کرنا ضروری ہے، اور پرانے major version سے براہ راست تازہ ترین version پر نہیں جانا چاہیے۔ پہلے ہر version کے اندر latest patch release پر جائیں، پھر ایک وقت میں صرف ایک version آگے بڑھیں۔ ہر مرحلے سے پہلے PostgreSQL کا backup لیں، کیونکہ authentik downgrade کی حمایت نہیں کرتا اور migrations صرف آگے کی سمت چلتی ہیں۔