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

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

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

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

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

ابدأ بالحد الأدنى للموارد، لأنه يحدد القائمة المختصرة قبل النظر في أي ميزة. الأرقام أدناه هي الأرقام المنشورة من كل مشروع نفسه، وقد جرى الاطلاع عليها في October 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 "مضيفاً يضم نواتي 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، وتضيف الذاكرة خارج الـheap، التي تبلغ نحو 300 MB، ليصبح الإجمالي نحو 1017 MB. وهذا لا يترك إلا مساحة إضافية ضئيلة جداً تحت الحد، بينما يبلغ الرقم الأساسي في الدليل نفسه، مع ذاكرات التخزين المؤقت لبيانات Realm و10,000 جلسة، 1250 MB.

تطلب صفحة compose الخاصة بـZitadel أيضاً 2 GB، أي 2048 MB نفسها، ويغطي هذا الرقم كلاً من مرحلة البدء السريع ومرحلة homelab أو شبه الإنتاج. ولتحديد الحجم بعد ذلك، راجع صفحة الإنتاج الخاصة به. تحتاج عملية Zitadel نفسها إلى "نحو 512MB من RAM، ويمكنها العمل بأقل من نواة CPU واحدة". أما قاعدة البيانات فهي الجزء الأعلى استهلاكاً: "نحو نواة CPU واحدة لكل 100 طلب في الثانية (req/s)، و4GB من RAM لكل نواة". ويتطلب تجزئة كلمات المرور بعد ذلك "توفير 4 أنوية CPU لهذا الغرض"، لأن دفعة من عمليات تسجيل الدخول تتحول إلى ارتفاع مفاجئ في استخدام CPU. يشغّل compose الرسمي للإصدار v4 عدد 4 من الحاويات قبل إضافة أي شيء: Traefik باعتباره proxy، وZitadel API، وحاوية Login UI منفصلة، وPostgreSQL. ويعمل Redis ومجمّع OpenTelemetry خلف profiles اختيارية في 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.8.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" من خلال نقطة وصول (outpost) مخصصة لـ LDAP، مع توفر LDAPS على المنفذ 636. تقتصر وثائقها على عمليات الربط والبحث فقط ولا تصف أي عمليات كتابة، لذا تعامل معها كدليل للقراءة فقط. يتم إلحاق رمز الاستخدام لمرة واحدة بكلمة المرور باستخدام فاصلة منقوطة، كما في password;123456، ولا يتم دعم مصادقات الرسائل القصيرة (SMS) أثناء عملية الربط.

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

ماذا عن التطبيقات التي لا تملك نظام تسجيل دخول على الإطلاق؟

المصادقة الأمامية (Forward auth) هي الحل، وهي حالة يواجهها أي خادم ذاتي الاستضافة باستمرار. يسأل الـ Reverse Proxy خادم SSO عما إذا كان الطلب مسموحاً به قبل تمريره إلى التطبيق. لا يعرف التطبيق الموجود في الخلفية شيئاً عن SSO؛ فهو يتلقى طلبات فحصها الوكيل مسبقاً، وعادة ما يتضمن ذلك اسم المستخدم في ترويسة (header).

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

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

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

ما مدى سوء مسار الترقية؟

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

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

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

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

الفئات المستهدفة لكل مشروع، ومواطن القصور في كل منها

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

authentik صُمم لجمهور الاستضافة الذاتية، وتظهر هذه الغاية في قائمة ميزاته. يوفر التطبيق ميزة forward auth ومزود LDAP، كما يتيح بناء مسارات تسجيل الدخول عبر محرر مرئي. يفشل هذا الخيار عندما تحتاج إلى دعم فني من المطور دون ميزانية مؤسساتية ضخمة، أو عندما لا ترغب في وتيرة إصدارات تتغير كل بضعة أسابيع. الدعم الفني متاح فقط عبر اشتراك مدفوع: دعم التذاكر متاح في اشتراكات Enterprise التي تتجاوز 1000 دولار، والدعم المخصص مع اتفاقيات مستوى الخدمة (SLAs) متاح في اشتراكات Enterprise Plus التي تبدأ من 20000 دولار سنوياً. الاعتماد على إصدارات تقويمية دون مسار للرجوع إلى إصدار سابق أو تخطي إصدارات يمثل عبئاً تشغيلياً حقيقياً، كما أن محرر المسارات يمثل نموذجاً كاملاً يجب تعلمه بينما تكمن مشكلتك الفعلية في عميل OIDC واحد فقط.

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

ما الذي سأشغّله على 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 كمتطلب أدنى وجود معالج بنواتين وذاكرة RAM بسعة 2 GB على الأقل، بينما يحدد دليل قياس Keycloak ذاكرة أساسية قدرها 1250 MB للخادم قبل احتساب قاعدة البيانات. كلاهما يستهلك موارد كبيرة عند سعة 2 GB بمجرد إضافة التطبيقات التي تحميها، لذا اعتبر 4 GB هي الحد الأدنى المريح. يذكر دليل التشغيل الخاص بـ Zitadel سعة 2 GB أيضاً ويعمل ضمن إعدادات المختبر المنزلي أو بيئات الإنتاج المحدودة، لكن توجيهات الإنتاج الخاصة به تطلب 4 أنوية للمعالج لتجزئة كلمات المرور و 4 GB من ذاكرة RAM لكل نواة قاعدة بيانات، لذا توقع أن تصبح سعة 2 GB محدودة بمجرد وصول حركة مرور تسجيل دخول فعلية.

هل يمكن لـ Keycloak أو Zitadel حماية تطبيق لا يملك نظام تسجيل دخول خاص به؟

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

أي منها يمكنه العمل كخادم LDAP لتطبيق لا يدعم إلا بروتوكول LDAP؟

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

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

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