Keycloak أم authentik أم Zitadel على VPS واحد؟

أي خادم SSO يناسب VPS واحداً

يُعد Keycloak وauthentik وZitadel خوادم تسجيل الدخول الموحّد (SSO) المستضافة ذاتياً التي يُلجأ إليها عند الحاجة إلى تسجيل دخول واحد لجميع التطبيقات على الخادم. لكنها ليست بدائل متكافئة على VPS صغير واحد. يُعد authentik الخيار الافتراضي الآمن لخادم يشغّل ثلاثة أو أربعة تطبيقات مستضافة ذاتياً، لأنه الوحيد من بين هذه الخوادم الثلاثة الذي يستطيع عرض شاشة تسجيل دخول أمام تطبيق لا يوفّر تسجيل الدخول بنفسه. يكون Keycloak الخيار المناسب عندما تتحدث كل التطبيقات التي تريد حمايتها ببروتوكول قياسي، وعندما تتوفر لديك ذاكرة كافية لتشغيل آلة Java الافتراضية (JVM). صُمّم Zitadel للمطورين الذين يطرحون منتجاً عبر واجهة API، وهو الخيار الذي لا أوصي بمحاولة تشغيله بأقل من 4 GB.

اختر أولاً، ثم ثبّت. بعد اختيارك، يشرح دليل تثبيت authentik عملياً على VPS خطوات الإعداد بالتفصيل.

ما مقدار RAM الذي يحتاجه كل نظام فعلياً؟

ابدأ بالحد الأدنى للموارد، لأنه يحدد القائمة المختصرة قبل النظر في أي ميزة. الأرقام أدناه هي الأرقام التي نشرتها المشاريع نفسها، كما جرى الاطلاع عليها في August 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. يذكر دليل تحديد الحجم أن «الاستخدام الأساسي للذاكرة في Pod، بما في ذلك ذاكرة التخزين المؤقت لبيانات Realm و10,000 جلسة مخزنة مؤقتاً، يبلغ 1250 MB من RAM». وتغطي هذه 1250 MB عملية Java بحد ذاتها، قبل إضافة قاعدة البيانات. وتشرح الصفحة نفسها سبب أهمية حد الحاوية إلى هذا الحد: يستخدم Keycloak نسبة 70% من حد الذاكرة كـheap، ويحتاج إلى نحو 300 MB إضافية من الذاكرة خارج الـheap. إذا منحت الحاوية 1 GB، فستحسب heap بحجم يقارب 717 MB، مع استمرار حاجتها إلى 300 MB من الذاكرة خارج الـheap. لذلك يكون الحد قد استُهلك بالكامل قبل دخول أي بيانات جلسات إلى ذاكرة التخزين المؤقت.

تطلب صفحة compose الخاصة بـZitadel أيضاً 2 GB، أي 2048 MB نفسها، لكن هذا الرقم مخصص للتشغيل الأول. أما صفحة الإنتاج فهي المرجع الأهم. تحتاج عملية Zitadel نفسها إلى «نحو 512MB من RAM، ويمكنها العمل بأقل من نواة CPU واحدة». أما قاعدة البيانات فهي الجزء الأكثر استهلاكاً للموارد: «نحو نواة CPU واحدة لكل 100 طلب في الثانية (req/s)، و4GB من RAM لكل نواة». كما تحتاج عملية تجزئة كلمات المرور إلى «4 من أنوية CPU متاحة لهذا الغرض»، لأن زيادة تسجيلات الدخول المفاجئة تتحول إلى ارتفاع حاد في استخدام CPU. يشغّل compose الرسمي لـv4 عدد 4 من الحاويات قبل إضافة أي شيء: Traefik باعتباره الـproxy، وواجهة Zitadel البرمجية، وحاوية Login UI مستقلة، وPostgreSQL. ويعمل Redis ومجمّع OpenTelemetry خلف ملفات تعريف compose اختيارية.

يمكن تشغيل Keycloak وauthentik على VPS بسعة 4 GB مع ترك مساحة للتطبيقات التي تحميها. سيبدأ Zitadel على 2 GB، ثم سيتنافس مع PostgreSQL الخاص به على الذاكرة عند كل عملية تسجيل دخول. لا أنصح بتشغيل Zitadel بأقل من 4 GB، وعلى خادم يستضيف تطبيقات أيضاً سأفضّل 8 GB.

ما الذي يشغّله كل منها فعلياً على خادمك

authentik هو PostgreSQL ونسختان من صورة واحدة، واحدة للخادم وأخرى للعامل. يستجيب الخادم لطلبات HTTP ويحتوي على outpost مضمّن. ينفّذ العامل مهام في الخلفية، مثل مزامنة الأدلة وإرسال البريد الإلكتروني. ملف التثبيت المنشور قصير.

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. ضع reverse proxy مع شهادة حقيقية أمامه قبل إتاحة هذا المنفذ من الإنترنت.

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 بدلاً من ذلك، مع PostgreSQL حقيقي عبر KC_DB واسم مضيف عام عبر 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

عيّن ZITADEL_MASTERKEY في .env قبل التشغيل الأول. إنه المفتاح المؤلف من 32 حرفاً الذي يستخدمه Zitadel لتشفير الأسرار في قاعدة البيانات، ولذلك فإن فقدانه يعني فقدان إمكانية الوصول إلى تلك الأسرار. إذا لم تكن معتاداً على تشغيل مكدسات من هذا النوع، فإن أساسيات Docker Compose لخادم VPS تشرح خيارات volume وسياسة إعادة التشغيل التي تحدد ما إذا كان موفّر الهوية سيستمر بعد إعادة التشغيل.

ما البروتوكولات التي يدعمها كل منها؟

تدعم المنتجات الثلاثة OpenID Connect (OIDC)، وهي طبقة تسجيل الدخول المبنية على OAuth 2.0 التي تستخدمها التطبيقات الحديثة. كما تدعم المنتجات الثلاثة SAML 2.0 (لغة ترميز تأكيدات الأمان)، وهو المعيار الأقدم الذي لا يزال برنامج المؤسسات يُصدر دعماً له. يكمن الفرق الفعلي في LDAP (بروتوكول الوصول الخفيف إلى الدليل)، إذ يشير المصطلح نفسه إلى وظيفتين متعاكستين.

القراءة من LDAP تعني أن خادم SSO يتحقق من كلمات المرور مقابل دليل تديره مسبقاً. ينفّذ Keycloak ذلك عبر user federation. ويدعمه Zitadel أيضاً؛ إذ توضّح وثائقه كيفية "ربط خادم LDAP بوصفه موفّر هوية في ZITADEL".

تقديم LDAP يعني أن تطبيقاً لا يتحدث إلا LDAP يمكنه إجراء bind على خادم SSO لديك كما لو كان هذا الخادم هو الدليل. يدعم authentik هذه الوظيفة وحده. يتيح موفّر LDAP فيه "البحث عن جميع المستخدمين والمجموعات في قاعدة بيانات authentik عبر دليل LDAP" من خلال LDAP outpost مخصص، مع إتاحة LDAPS على المنفذ 636. هذا الموفّر للقراءة فقط، لذلك يعمل bind والبحث، بينما لا تعمل عمليات الكتابة. يُلحق رمز لمرة واحدة بكلمة المرور باستخدام فاصلة منقوطة، كما في password;123456، ولا تُدعم موفّرات المصادقة عبر SMS أثناء bind.

إذا كان أحد التطبيقات في قائمتك لا يتحدث إلا LDAP، تنتهي المقارنة عند هذه النقطة. لا يستطيع Keycloak وZitadel الاستجابة لعملية bind هذه، ولذلك ستحتاج إلى تشغيل دليل ثانٍ بجوارهما ومزامنة قائمتي المستخدمين.

ماذا عن التطبيقات التي لا توفّر تسجيل دخول على الإطلاق؟

المصادقة بالوكالة هي الحل، وهذا من أكثر السيناريوهات شيوعاً على الخوادم ذاتية الاستضافة. يطلب الـReverse Proxy من خادم SSO التحقق مما إذا كان الطلب مسموحاً به قبل تمريره إلى الخدمة الخلفية. لا يعرف التطبيق خلفه أي شيء عن SSO. فهو يستقبل طلبات تحقّق منها الـReverse Proxy مسبقاً، وعادةً ما يكون اسم المستخدم موجوداً في ترويسة.

يوفّر authentik ذلك عبر ثلاثة أوضاع موثّقة. في وضع "Proxy"، يمرّر authentik outpost حركة المرور إلى التطبيق الخلفي بنفسه. في وضع "Forward auth (single application)" تبقى حركة المرور لدى الـReverse Proxy الحالي، ويُستخدم authentik للتحقق من المصادقة فقط. في وضع "Forward auth (domain level)" تُحمى كل التطبيقات ضمن نطاق رئيسي واحد باستخدام موفّر واحد. وضع النطاق هو الخيار الأسهل، لكنه يفرض حداً موثّقاً: "لا يمكنه فرض قواعد تفويض مختلفة على مستوى التطبيق لكل تطبيق محمي"، لذلك تشترك كل التطبيقات ضمن ذلك النطاق في مجموعة واحدة من السياسات.

لا يوفّر Keycloak أياً من ذلك. أُعيدت تسمية الـproxy المرافق له، Keycloak Gatekeeper، إلى Louketo Proxy، ثم أُرشف مستودعه على GitHub، وكان آخر commit له في August 2023. لحماية تطبيق لا يدعم OIDC، شغّل مكوّناً منفصلاً أمامه، وعادةً ما يكون oauth2-proxy، مع توجيهه إلى عميل في Keycloak. لا يوفّر Zitadel أيضاً وضع forward auth خاصاً به، لذلك يكون الحل هو نفسه: تثبيت مكوّن إضافي ومراقبته وترقيته.

تلك القفزة الإضافية هي النقطة التي يتوقف عندها إعداد الـReverse Proxy عن كونه بسيطاً، لذلك اقرأ كيفية وضع Traefik أمام عدة تطبيقات Docker Compose قبل ربط middleware للمصادقة به.

ما مدى صعوبة مسار الترقية؟

اعتباراً من August 2026، الإصدارات الحالية هي Keycloak 26.7.1 وauthentik 2026.5.6 وZitadel v4.16.3. تنفّذ المنتجات الثلاثة عمليات ترحيل للمخطط على PostgreSQL، وهذا يعني أن كل ترقية تغيّر قاعدة البيانات. خذ نسخة احتياطية من قاعدة البيانات أولاً في كل مرة. هذه العادة الواحدة أهم من أي ميزة في هذه المقارنة.

لدى authentik القاعدة الأكثر صرامة، ويذكرها بوضوح: "يجب أن تتبع الترقيات تسلسل الإصدارات الرئيسية؛ لا تنتقل مباشرة من إصدار رئيسي أقدم إلى أحدث إصدار." انتقل إلى أحدث إصدار تصحيحي داخل كل إصدار قبل الانتقال إلى الإصدار الرئيسي التالي، و"لا يدعم authentik الرجوع إلى إصدار أقدم". إذا تأخرت عاماً عن مشروع يستخدم إصدارات مرتبطة بالتقويم، تتحول ترقية واحدة إلى سلسلة من الترقيات، ولكل منها ترحيل قاعدة بيانات خاص بها.

يوضح دليل ترقية Keycloak الترتيب الذي يجب اتباعه: راجع تغييرات الترحيل منذ الإصدار السابق، ثم رقِّ الخادم، وبعد ذلك رقِّ الـadapters. تُنفّذ عملية ترحيل قاعدة البيانات تلقائياً، أو يمكنك تصديرها وتطبيقها يدوياً. يفيد ذلك عندما تريد قراءة التغيير قبل تطبيقه. تكمن كلفة Keycloak في عملية القراءة هذه. تتضمن ملاحظات الإصدار عناصر deprecated وتغييرات في السلوك يسهل تجاوزها، ويكون تفويتُها مكلفاً.

يفصل Zitadel مرحلتي init وsetup عن الخادم قيد التشغيل، وتوصي إرشادات التشغيل في بيئة الإنتاج بإبقائهما منفصلتين حتى لا تؤدي عملية التوسعة إلى تكرار أعمال الإعداد. على VPS واحد، يعني ذلك غالباً أن خطوة setup يجب أن تكتمل قبل أن تعلن API عن سلامتها، ولذلك يوفّر ملف compose health checks ويستخدم أمر البدء --wait.

لمن صُمّم كل مشروع، وأين يواجه القيود

صُمّم Keycloak، وهو خادم الهوية من Red Hat، للمؤسسات التي تستخدم realms وgroups وrole mappings ودليلاً مؤسسياً قائماً. وهو الأكثر اكتمالاً في تطبيق المعايير بين المشاريع الثلاثة. لكنه لا يناسب VPS بسعة 2 GB يشغّل أربعة تطبيقات مستضافة ذاتياً، نصفها لا يدعم OIDC. ستستهلك JVM مقدار 1250 MB، وستتعلم نموذج realms المصمم لشركة، ثم ستثبّت oauth2-proxy رغم ذلك للتطبيقات التي تحتاج إليها فعلياً.

صُمّم authentik لمستخدمي الاستضافة الذاتية، وتوضح قائمة ميزاته ذلك. فهو يوفّر forward auth وموفّر LDAP، كما يتيح إنشاء تدفقات تسجيل الدخول عبر محرر مرئي. لكنه لا يناسب الحالات التي تحتاج فيها إلى عقد دعم من المورّد أو إلى مسار إصدارات لا يتغير كل بضعة أسابيع. يتطلب ترقيم الإصدارات وفق التقويم، من دون مسار للرجوع إلى إصدار أقدم ومن دون إمكانية تخطي الإصدارات، عملاً تشغيلياً فعلياً. كما أن محرر التدفقات يفرض نموذجاً كاملاً لتعلّمه عندما تكون مشكلتك الفعلية هي عميل OIDC واحد.

صُمّم Zitadel للمطورين الذين يدمجون المصادقة في منتج يطلقونه، مع API قوي ودعم multi-tenancy كميزة أساسية. لكنه لا يناسب هذه الحالة تحديداً. أربعة containers، ومن دون forward auth، وقاعدة بيانات بحجم 4 GB لكل core؛ هذه بنية غير مناسبة لـVPS واحد يستضيف مدير كلمات مرور وwiki خلفه.

ما الذي سأشغّله على VPS واحد، وكيف

بالنسبة إلى VPS واحد يستضيف 3 أو 4 تطبيقات ذاتية الاستضافة، شغّل authentik. توفّر المنتجات الثلاثة شاشة تسجيل دخول. العامل الحاسم هو أن بعض تطبيقاتك لن تدعم OIDC مطلقاً، ويعالج authentik ذلك من خلال forward auth مضمّنة فيه، بدلاً من إضافة مكوّن آخر بجانبه.

خصص له 4 GB إن أمكن، واستخدم 2 GB فقط إذا كانت التطبيقات الأخرى صغيرة. أبقِ المنفذ 9000 بعيداً عن الإنترنت العام، وأنهِ TLS عند reverse proxy أمامه. أنشئ نسخاً احتياطية لقاعدة PostgreSQL كل ليلة وخزّنها خارج الخادم، لأن موفّر الهوية الذي لا يملك نسخة احتياطية يصبح نقطة فشل واحدة لكل تطبيق خلفه. شغّل المكدس باستخدام حساب مخصص غير ذي امتيازات بدلاً من root: يشرح إعداد حسابات ذات أقل قدر من الامتيازات على VPS الحساب وملكية الملفات المطلوبة لذلك.

اختر Keycloak بدلاً منه عندما تكون جميع التطبيقات التي تحميها تدعم OIDC أو SAML مسبقاً، أو عندما تحتاج إلى نموذج الأدوار الدقيق الذي توفّره Keycloak realms. اختر Zitadel عندما تبني تطبيقاً ليسجّل أشخاص آخرون حساباتهم فيه، وتريد استخدام API ونموذج المستأجرين الخاصين به. لا يناسب أيٌّ من هذين الخيارين حالة 3 تطبيقات على خادم واحد التي يتناولها هذا المنشور.

أنماط الفشل التي ستواجهها أولاً

لا توجد بيانات في Keycloak بعد إعادة التشغيل. شغّلته باستخدام start-dev، الذي يستخدم قاعدة بيانات محلية مخصّصة للتطوير. في حاوية لا تحتوي على volume، تؤدي إزالة الحاوية إلى إزالة realm. انتقل إلى start باستخدام KC_DB=postgres، واضبطه للإشارة إلى قاعدة بيانات فعلية.

تختفي حاوية عامل authentik على خادم صغير. يعمل العامل والخادم باستخدام الصورة نفسها، ويحتوي كلاهما على عمليات Python، بينما تستهلك PostgreSQL حصتها من ذاكرة مضيف تبلغ 2 GB. شغّل docker compose ps للتأكد من الخدمة التي توقفت، ثم افحص dmesg بحثاً عن عملية قتل بسبب نفاد الذاكرة قبل أن تبدأ البحث عن خلل في التطبيق.

لا تعمل Console في Zitadel خلف الـproxy. تستخدم واجهة Zitadel API بروتوكول gRPC، الذي يتطلب استمرار HTTP/2 حتى الخادم upstream. تطلب صفحة المتطلبات reverse proxy يدعم اتصالات HTTP/2 مع الخوادم upstream، وتذكر الإصدارات المختبرة من Traefik v3.x وNGINX v1.x وCaddy v2.x وApache httpd 2.4.x. إذا خفّض الـproxy اتصال upstream إلى HTTP/1.1، فستحصل على صفحة تسجيل دخول تُحمّل، بينما تفشل Console.

تعيدك كل التطبيقات إلى شاشة تسجيل الدخول. يجب أن يتطابق عنوان URL العام لخادم SSO مع عنوان URL المكوَّن في التطبيق تطابقاً تاماً، بما في ذلك scheme والمنفذ. يطلق Keycloak على ذلك إعداد hostname، بينما يطلق عليه Zitadel اسم external domain. عند اختلافهما، يعيد التطبيق توجيهك إلى تسجيل دخول لا يتعرّف الخادم إليه على أنه عنوانه، فيتنقل المتصفح ذهاباً وإياباً بين العنوانين.

FAQ

أيّ من الخيارات الثلاثة يناسب VPS بسعة 2 GB؟

authentik وKeycloak. يتطلب authentik، وفق متطلباته المعلنة، مضيفاً يحتوي على نواتي CPU على الأقل و2 GB من RAM، بينما يحدد دليل التحجيم الخاص بـKeycloak الذاكرة الأساسية للخادم بـ1250 MB قبل إضافة قاعدة البيانات. يستهلك كلا الخيارين موارد كبيرة على 2 GB بعد إضافة التطبيقات التي تحميها، لذلك اعتبر 4 GB الحد الأدنى المريح. ينشر Zitadel متطلب 2 GB للتشغيل الأول، لكن إرشادات الإنتاج لديه تطلب 4 نوى CPU لتجزئة كلمات المرور و4 GB من RAM لكل نواة قاعدة بيانات، لذلك لا تمثل 2 GB عملية نشر فعلية.

هل يستطيع Keycloak أو Zitadel حماية تطبيق لا يوفّر تسجيل دخول خاصاً به؟

ليس بمفرده. لا يتضمن أي منهما مكوّناً لـforward auth. أما Louketo Proxy، وهو الـproxy المرافق القديم لـKeycloak، فقد أُرشف على GitHub وكان آخر commit له في August 2023، لذلك لا ينبغي الاعتماد عليه في بناء جديد. ضع oauth2-proxy أو مكوّناً مشابهاً بين الـreverse proxy والتطبيق، ووجّهه إلى OIDC client على خادم SSO. ينفّذ authentik ذلك أصلاً من خلال proxy provider في وضع "Forward auth (single application)" أو "Forward auth (domain level)".

أيّ منها يمكنه العمل كخادم LDAP لتطبيق لا يتحدث إلا LDAP؟

authentik. يعمل LDAP provider الخاص به على outpost، ويتيح البحث عن المستخدمين والمجموعات في authentik عبر LDAP، مع توفر LDAPS على المنفذ 636. وهو للقراءة فقط، لذلك يعمل bind والبحث، بينما لا تعمل عمليات الكتابة. يعمل Keycloak وZitadel في الاتجاه المعاكس: يقرأ كلاهما من دليل LDAP موجود بصفته مصدراً للمستخدمين، ولا يستجيب أي منهما لطلب LDAP bind صادر من تطبيق.

هل يمكنني تخطي الإصدارات عند ترقية authentik؟

لا. توضّح الوثائق أن الترقيات يجب أن تتبع تسلسل الإصدارات الرئيسية، وأنه لا ينبغي الانتقال مباشرة من إصدار رئيسي قديم إلى أحدث إصدار. انتقل أولاً إلى أحدث patch release داخل كل إصدار، ثم ارتقِ إصداراً واحداً في كل مرة. أنشئ نسخة احتياطية من PostgreSQL قبل كل خطوة، لأن authentik لا يدعم الرجوع إلى إصدار أقدم، ولأن عمليات الترحيل تعمل في اتجاه واحد فقط.