إذا كنت قد غادرت بالفعل منصّة PaaS المُدارة، فقد جُهّز VPS الخاص بك، وأُضيف مفتاح SSH، ومؤشّر الطرفية يومض على سطر التثبيت. السؤال الوحيد المتبقّي: هل تشغّل curl ... | bash لـ Coolify، أم لـ Dokploy؟
يُثبَّت كلا الأداتين بأمر واحد. ويمنحك كلاهما نشرًا عبر Git-push، وSSL تلقائيًا، وواجهة ويب، وبروكسي عكسي فوق Docker. الاختلافات المثيرة للاهتمام هي تلك التي تظهر في الإنتاج: كيف يتعامل كل منهما مع docker-compose.ymlقياسي، وما يحدث أثناء النشر، وكيف استجاب كل مشروع للأخبار التي أعادت تشكيل هذه المقارنة في 2026. خبران يحملان معظم الوزن هنا: إفصاحات Coolify عن ثغرات CVE في يناير 2026 و إعادة هيكلة ترخيص Dokploy من الشهر نفسه.
يطابق هذا المنشور كل أداة مع حالة استخدام محدّدة بدلًا من تتويج فائز. بنهايته ستعرف، كما نأمل، أيهما يناسب سير عملك.
الخلاصة السريعة
- Coolify أقدم وله نظام بيئي أكبر (~55k نجمة على GitHub، و300+ قالب خدمة بنقرة واحدة)، أثقل عند الخمول، Apache 2.0 بالكامل، دون مستوى مدفوع على جانب الاستضافة الذاتية.
- Dokploy أحدث (~34k نجمة)، أخف عند الخمول، نواة Apache 2.0 إضافة إلى Source Available License منفصلة تحكم المزايا المدفوعة المستقبلية (SSO وRBAC وسجلّات التدقيق والعلامة البيضاء).
- لا يستطيع Coolify اليوم تنفيذ نشر دون توقّف عبر Docker Compose؛ بل فقط عبر Dockerfile أو Nixpacks أو نشر بصورة واحدة. يأتي Dokploy بـ Docker Swarm كوضع من الدرجة الأولى؛ بينما يُوصف Swarm في Coolify بأنه تجريبي.
- ثغرات Coolify CVE لشهر يناير 2026 مُصلَحة في v4.0.0 (April 27, 2026). حدّث Coolify ولا تعرّض اللوحة للإنترنت العام.
عندما لا تكون أي من الأداتين هي الإجابة الصحيحة
كل من Coolify وDokploy غير مناسب الشكل لبعض الإعدادات. ثلاثة بدائل تستحق المعرفة، باختصار:
- Kamal (من 37signals): للفرق التي لديها تطبيق أو اثنان وتريد صفر واجهة؛ فقط
kamal deployمن حاسوبك المحمول. أبسط بكثير من Coolify أو Dokploy والخيار الصحيح عندما لا تريد لوحة تحكّم. - Dokku، النموذج الكلاسيكي القائم على Git-push وخادم واحد. أقدم، ونطاق أصغر، ومستقر جدًا. النسخة الأصلية من "Heroku على VPS واحد".
- GitHub Actions + Docker Compose على VPS عارٍ، أصغر حزمة ممكنة. لا واجهة تنسيق، ولكن لا عبء تنسيق أيضًا. مناسب لتطبيق واحد حيث يكون تدفّق النشر
docker compose pull && docker compose up -dمُشغَّلًا من CI.
إذا كان شكلك تطبيقًا واحدًا على خادم واحد، فربما يكون كل من Coolify وDokploy مبالغًا فيه؛ جرّب أحد الخيارات أعلاه أولًا. أما إذا كان لديك تطبيقات متعدّدة أو قواعد بيانات متعدّدة أو فريق فيه أعضاء غير تقنيين يحتاجون إلى واجهة لتشغيل الأمور، فإن خيار Coolify مقابل Dokploy هو الخيار الصحيح. للاطّلاع على مسح أوسع للخيارات في هذه الفئة، راجع تجميعتنا لـ منصات السحابة ذاتية الاستضافة مع واجهة ويب.
نظرة عامة على Coolify وDokploy
Coolify v4.0.0 المستقر صدر في April 27, 2026، بعد دورة بيتا طويلة. وDokploy على v0.29.4 حتى May 11, 2026. كلاهما مشروعا PaaS مفتوحا المصدر مُستضافان ذاتيًا في فئة بدائل Heroku/Render/Vercel، وكلاهما يغلّف Docker بواجهة، وبروكسي عكسي يعمل بـ HTTPS افتراضيًا (Traefik)، ونشر قائم على Git.
| الميزة | Coolify | Dokploy |
|---|---|---|
| أحدث إصدار مستقر | v4.0.0 (April 27, 2026) | v0.29.4 (May 11, 2026) |
| الترخيص | Apache 2.0 | نواة Apache 2.0 + Source Available للمزايا المدفوعة |
| حزمة التقنيات | PHP / Laravel | TypeScript / Node.js |
| نجوم GitHub | ~55,000 | ~34,000 |
| الحد الأدنى لـ RAM (رسمي) | 2 GB | 2 GB |
| الحد الأدنى لـ CPU (رسمي) | نواتان | غير محدّد |
| استهلاك RAM عند الخمول (وفق تقارير المجتمع) | 500 MB – 1.2 GB | 300 – 400 MB |
| نشر Docker Compose دون توقّف | غير مدعوم (Dockerfile/Nixpacks فقط) | معالجة قياسية لـ Compose |
| تجميع متعدّد الخوادم | Docker Swarm (تجريبي) | Docker Swarm (أصلي) |
| دعم ARM64 | نعم (بما في ذلك Raspberry Pi OS) | غير مُعلَن عنه في الوثائق |
| أنظمة البناء | Nixpacks وDockerfile وصورة Docker | Nixpacks وDockerfile وصورة Docker وHeroku Buildpacks وPaketo وRailpack |
| بروكسي عكسي | Traefik | Traefik |
| نطاق المراقبة المُستضاف ذاتيًا | مقاييس مدمجة + عارض سجلّات | مقاييس موارد أساسية + تحليل سجلّات/أخطاء بناء بالذكاء الاصطناعي (v0.29.0+) |
رأينا: اختر Dokploy إن أردت عبئًا أقل عند الخمول، ودعمًا أصليًا متعدّد الخوادم، ومعالجة قياسية لـ Docker Compose دون تعديلات خاصة بالمنصّة. اختر Coolify إن أردت مكتبة تطبيقات أكبر بنقرة واحدة، أو دعم ARM64/Raspberry Pi، أو Apache 2.0 خالصًا دون مستوى مدفوع مستقبلي ينتظر في الكواليس.
بصمة الموارد وتحديد حجم VPS
يمكن لمنصّة PaaS مُستضافة ذاتيًا أن توفّر عليك تكلفة Heroku. لكن إذا التهمت طبقة التنسيق 1.5 GB من VPS سعته 2 GB عند الخمول، فلن يتبقّى لديك شيء لتنشر عليه. لذا فإن السؤال العملي الأول على خادم صغير هو: كم تكلّفك كل أداة قبل أن تنشر تطبيقًا واحدًا؟
يعتمد استهلاك Coolify لـ RAM عند الخمول على ما يُفعَّل من مراقبة، مع بصمة CPU أساسية بنسبة 5–7% ترتفع فجأة عند تشغيل عملية جمع المقاييس. تستخدم وثائق Coolify نفسها عبء عمل إنتاجي نموذجي بسعة 8 GB من RAM، و4 أنوية، و150 GB من التخزين يشغّل 3 تطبيقات Node.js، و4 مواقع ثابتة، وبضع قواعد بيانات. وهذا مرجع تحجيم معقول إن كانت حزمتك مشابهة.
Dokploy، في المقابل، يعمل أخف بكثير، أقل بكثير من 2% من CPU عندما لا يجري أي نشر.
A تقرير LogRocket الإنتاجي الذي شغّل الأداتين جنبًا إلى جنب وصل إلى الخلاصة نفسها في الاتجاه: إن docker stop && docker start على تطبيق Dokploy لا يُطلق إعادة بناء كاملة، بينما العملية نفسها على Coolify تفعل. وهذا وحده يحوّل التكلفة في الحالة المستقرة لصالح Dokploy، خصوصًا على خطط VPS الأصغر حيث تلتهم عواصف إعادة البناء ميزانية CPU لديك.
لتحديد الحجم، إليك إعداد VPS الذي أوصي به:
- Coolify، عبء عمل خفيف: 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
- Coolify، عبء عمل بمعيار الإنتاج: 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
- Dokploy، عبء عمل خفيف: 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
- Dokploy، هامش إنتاجي: 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.
نصيحة محترفة: يتناسب استهلاك Coolify لـ RAM عند الخمول مع إعدادات المراقبة. إن كنت محدود الذاكرة، قلّل فاصل جمع المقاييس (أو عطّل المراقبة المدمجة تمامًا إن كنت تشغّل Prometheus/Grafana في مكان آخر) قبل أن توفّر خادمًا أكبر.
حقيقة النشر: Docker Compose وDockerfile والنشر دون توقّف
تصل معظم الفرق إلى إحدى هاتين الأداتين بملف docker-compose.yml موجود وتوقّع: الصق الملف، انقر نشر، شاهد التطبيق يعمل. وكيف تتعامل كل منصّة مع Compose القياسي، وما يحدث للطلبات قيد التنفيذ أثناء النشر التالي، هو حيث يظهر الفرق العملي.
يدعم Coolify كلًا من Docker Compose وDockerfile وNixpacks (الكشف التلقائي من ملفات المشروع) ونشر صور Docker مباشرة. لكن هناك مشكلة تستحق التوضيح: النشر دون توقّف (التحديثات المتدرّجة، النشر الأزرق/الأخضر) يعمل في Coolify فقط عبر Dockerfile أو Nixpacks أو نشر بصورة واحدة. ولا يعمل عبر Docker Compose. أكّد أحد مشرفي Coolify في نقاش على GitHub أنه "بالنسبة للنشر القائم على compose، تُوقَف جميع الحاويات قبل بدء الحاويات الجديدة، ولا يوجد حاليًا تحديث متدرّج للنشر القائم على compose." دعم النشر المتدرّج لـ Compose مدرَج في خارطة الطريق لـ v5؛ ولن يحصل عليه v4. والحل البديل الذي يقترحه المشرف هو تقسيم حزمة Compose إلى خدمات Coolify منفردة، وهو ترحيل غير هيّن إن كان ملف Compose الخاص بك يعبّر عن علاقات حقيقية بين الخدمات.
تظهر النتيجة التي يواجهها المستخدم في سلسلة نقاش على Hacker News حول Coolify، حيث وضعها أحد المشغّلين بصراحة: "أي طلب معلّق عند تحديث تطبيق يُقتَل ببساطة." وهذا دقيق بالنسبة لنشر Compose اليوم.
تضيف طبقة Compose في Coolify أيضًا ما يسمّيه المشروع "المتغيّرات السحرية". أي الحقن التلقائي لصور مساعدة، وإعادة كتابة الشبكة، وتجاوزات البيئة. القصد هو أن يكون أكثر كفاءة؛ والأثر الجانبي هو أن docker-compose.yml يعمل بنظافة على حاسوبك المحمول يحتاج أحيانًا إلى تعديل ليعمل بنظافة على Coolify. سلسلة نقاش Hacker News نفسها تكشف عن حالة نموذجية: "أُضيف 8 متغيّرات داخل docker-compose، ولم يُتعرَّف إلا على 7 منها." إن كانت حزمة Compose الخاصة بك صغيرة وقياسية، فقد لا تواجه هذه المشكلات. وإن كانت كبيرة أو غير معتادة، فستواجهها.
موقف Dokploy مختلف. وجد تقرير LogRocket العملي أن Dokploy "يستطيع نشر ملف docker-compose.yml موجود بتعديل قليل أو دون تعديل" ويبقى قريبًا من نموذج التوجيه الأصلي القائم على التسميات في Docker. ويشير التقرير نفسه إلى أن إيقاف/تشغيل الحاوية في Dokploy لا يُطلق إعادة بناء كاملة، بينما العملية نفسها على Coolify تفعل. وهذه إشارة اتجاهية حول سلوك التشغيل أكثر من كونها "ضمان نشر دون توقّف" رسميًا من وثائق Dokploy، لكنها تتوافق مع ما يبلّغ عنه المستضيفون ذاتيًا على نسخ VPS الأصغر.
يدعم Dokploy أيضًا Heroku Buildpacks وPaketo Buildpacks وRailpack إضافة إلى Nixpacks وDockerfile. للفرق القادمة من Heroku بسير عمل قائم على heroku.yml أو على buildpacks، فهذا مسار المقاومة الأقل.
الخلاصة الأساسية للقسم: إن كانت خدماتك الحالية حزمة Docker Compose حقيقية، فسيطالبك Coolify إما بإعادة هيكلة استراتيجية النشر أو قبول توقّف قصير مع كل دفعة. أما Dokploy فلن يفعل.
الأمان: إفصاحات Coolify عن ثغرات CVE في يناير 2026
أقرأ القصة الأوسع هكذا: Coolify آمن للتشغيل اليوم إن أبقيته محدَّثًا ولم تعرّض اللوحة للإنترنت العام. الإفصاح لا يُسقط المشروع. فقد اتُّبع الإفصاح المسؤول وصدرت الترقيعات. لكن ما يكشفه هو أن سطح الهجوم المتاح لمستخدم مصادَق منخفض الصلاحية كان أوسع مما ينبغي. وهذا درس تصميمي للمشروع ودرس تشغيلي للمشغّل: شدّد نموذج التعرّض الآن.
نصيحة محترفة: حتى بعد الترقيع، تعامل مع لوحة Coolify كما تتعامل مع SSH. اربطها بشبكة خاصة، أو ضعها خلف VPN، أو ضع أمامها Tailscale. لا تعرّض المنفذ 8000 للإنترنت العام لمجرد أن سكربت التثبيت يجعل ذلك سهلًا.
Dokploy ليس معفًى من هذا النوع من المشكلات أيضًا. تُقرّ ملاحظات إصدار v0.29.3 بثغرة أمنية حُدِّدت في Dokploy وتأتي بسكربت ترقيع أمني يُتوقَّع منك تشغيله مع الترقية. سطح أصغر، وتاريخ مشروع أقصر، لكن الانضباط التشغيلي نفسه ينطبق: حدّث يوم صدور الترقيعات، ولا تترك اللوحة على الإنترنت العام.
الخلاصة الأساسية للقسم: قصة CVE هي علامة صفراء على ممارسة Coolify التشغيلية، لا علامة حمراء ضد المشروع، لكنها ترفع سقف انضباط التحديث وطريقة تعريض اللوحة.
الترخيص: ما هو مجاني وما ليس كذلك
أُعيدت هيكلة ترخيص Dokploy في January 21, 2026. إليك ما تغيّر وما يعنيه للمستضيفين ذاتيًا.
Dokploy الآن Apache 2.0 قياسي للنواة، ليحلّ محل Apache 2.0 المُعدَّل غير القياسي السابق الذي أربك المستخدمين بشأن ما هو مفتوح المصدر وما ليس كذلك. وتحكم الآن Source Available License منفصلة من Dokploy الكود في proprietary/ المجلدات: مصدر مرئي، مدفوع للاستخدام الإنتاجي. المزايا التي يقول Dokploy إنها ستعيش خلف هذا الترخيص:
- تسجيل الدخول الموحّد (SSO/SAML) وضوابط وصول متقدّمة
- علامة تجارية مخصّصة وعلامة بيضاء
- توفّر عالٍ، وتوسّع تلقائي، وتعافٍ من الكوارث
- مراقبة متقدّمة، وعمليات تكامل، ومزايا امتثال
التزم المشروع صراحة بعدم نقل أي ميزة مفتوحة المصدر موجودة إلى المستوى المدفوع أبدًا؛ والوظائف المدفوعة المستقبلية موجَّهة للمؤسسات التي تحتاج إلى أدوات ربط للمؤسسات. يقع 2FA اليوم بالفعل خلف مستوى Startup على صفحة تسعير Dokploy.
وضع Coolify بسيط. المشروع Apache 2.0 على GitHub؛ وكل ميزة في النسخة المُستضافة ذاتيًا مجانية. هناك عرض Coolify Cloud للفرق التي تريد من المشرف استضافته، لكن النسخة المُستضافة ذاتيًا منتج كامل دون أي بوّابات مزايا ودون مسار ترقية إلى مستوى مدفوع لا تملكه اليوم.
قراءتي: بالنسبة للمطوّرين الأفراد والفرق الصغيرة التي تستضيف ذاتيًا على VPS الخاص بها، فإن Dokploy مجاني عمليًا وسيبقى كذلك. أما المؤسسة التي تحتاج في النهاية إلى SSO أو RBAC دقيق أو سجلّات تدقيق أو علامة بيضاء، فسيدفعها Dokploy في النهاية نحو مستوى مدفوع. أما Coolify فلن يفعل، لأنه لا يملك ذلك المستوى في خارطة الطريق.
توضيح يستحق الذكر عبر المصادر: تتضمّن نسخة Dokploy المُستضافة ذاتيًا فعلًا مقاييس موارد أساسية (CPU والذاكرة والتخزين والشبكة)، وأضاف v0.29.0 تحليل سجلّات وأخطاء بناء مدعومًا بالذكاء الاصطناعي. نظام مراقبة Dokploy سحابي فقط لمزايا المراقبة الأكثر تقدّمًا. لكن المراقبة لا تزال تعمل محليًا على التثبيت المُستضاف ذاتيًا لمقاييس الموارد الأساسية قبل الحاوية.
تعدّد الخوادم والتجميع: الواقع مقابل التسويق
عاجلًا أم آجلًا لن يكفي VPS واحد، وكلا المشروعين يسوّق دعم تعدّد الخوادم بشكل بارز على صفحات هبوطه. لكن الواقع على الأرض ليس هو نفسه.
وثائق التوسّع الرسمية لـ Coolify صريحة بشأنه: دعم Docker Swarm موصوف بأنه تجريبي. النمط القياسي لتعدّد الخوادم يستخدم خوادم بعيدة مُتحقَّق منها متّصلة عبر SSH مع Docker Registry مشتركة بينها، ونسخ Traefik تعمل لكل خادم. يتطلّب وضع Swarm حدًا أدنى من ثلاثة خوادم بالبنية نفسها (كلها ARM، أو كلها AMD64). أما Kubernetes؟ "مخطَّط فقط، لكنه ليس في خارطة الطريق بعد، لذا لا موعد متوقّع." إن قرأت صفحة Coolify نفسها حول هذا، فالنسخة المختصرة هي: تعدّد الخوادم يعمل، وSwarm بيتا، وKubernetes رؤية.
يأتي Dokploy بـ Docker Swarm كوضع من الدرجة الأولى دون علامة تجريبية. يتعامل Traefik مع التوجيه في كل من إعدادات الخادم الواحد وSwarm. أضاف إصدار v0.29.0 دعم تعدّد الخوادم دون root، ما يسدّ فجوة حقيقية (لا مزيد من SSH بصلاحية root فقط لإضافة العُقد البعيدة).
إن كان التجميع متعدّد العُقد شيئًا ستحتاجه في الأشهر الستة المقبلة، لا "يومًا ما على شريحة عرض"، فإن Dokploy هو الخيار الأقل خطورة اليوم.
الخلاصة الأساسية للقسم: إن كان التجميع على خارطة طريقك القريبة، فإن فرق Swarm يقلب التوصية نحو Dokploy بغضّ النظر عن المحاور الأخرى.
أنظمة البناء ودعم اللغات
ستهتم الفرق القادمة من Heroku أكثر شيء بمعرفة أي أنظمة buildpack البيئية تدعمها كل أداة، لأن ذلك يحدّد مقدار إعادة الكتابة التي يحتاجها مشروعك قبل أول نشر.
مسار بناء Coolify هو Nixpacks (افتراضي، مكتشَف تلقائيًا من ملفات مشروعك)، أو Dockerfile، أو صورة Docker مبنية مسبقًا. Nixpacks متين للحالات الشائعة (Node وPython وPHP وGo وRust)، لكن للكشف التلقائي حواف خشنة. يستحق التحقّق لحزمتك: مشكلة في Nixpacks في يناير 2026 أثّرت في مشاريع Laravel التي تحتوي كليهما composer.json و package.json أنتجت كتل location مكرّرة في Nginx، ما عطّل فئة من عمليات النشر حتى أصلحها المصدر الأعلى.
يدعم Dokploy كلًا من Nixpacks وDockerfile وصورة Docker، ويضيف Heroku Buildpacks وPaketo Buildpacks وRailpack فوقها. إن كان مشروعك يُبنى بنظافة بالفعل بـ heroku.yml أو بـ buildpack، فإن Dokploy يتيح لك الإبقاء على ذلك السير. أما Coolify فسيطلب منك التحويل.
على السطح تبدو الأداتان متماثلتين: نشر عبر Git-push من GitHub وGitLab وBitbucket، وSSL تلقائي من Let's Encrypt، وواجهة ويب لمتغيّرات البيئة وإدارة قواعد البيانات. اتساع نظام البناء هو أحد الأماكن القليلة التي يتفوّق فيها Dokploy بوضوح.
كتالوجات التطبيقات بنقرة واحدة
بالنسبة للمشغّلين غير التقنيين الذين يريدون نشر خدمات مفتوحة المصدر معروفة (n8n وPlausible وSupabase وGhost وListmonk، الباقة المعتادة المُستضافة ذاتيًا)، فإن حجم مكتبة القوالب بنقرة واحدة عامل تمييز حقيقي. وبالنسبة لبعض المستخدمين، هذا أهم من مجالات أخرى مثل الأداء أو خفّة الوزن.
يقدّم Coolify أكثر من 300 خدمة بنقرة واحدة عبر نحو 40 فئة: الذكاء الاصطناعي، والتحليلات، والأتمتة، وقواعد البيانات، والأمان، والتخزين، والباقي. إنها المكتبة الأكبر بفارق كبير والإجابة العملية لغير المطوّرين الذين يريدون نشر خدمة دون كتابة ملف Compose.
مكتبة قوالب Dokploy أصغر. ووثائق Dokploy الحالية لا تنشر عددًا واضحًا، لذا لن أعطيك رقمًا.
الإجابة العملية: إن كان سير عملك هو "انشر n8n وSupabase وPlausible بنقرتين لكل منها"، فإن Coolify يفوز في هذا المحور بوضوح. أما إن كنت تكتب تطبيقاتك الخاصة وتريد نشرها فحسب، فحجم الكتالوج لا يهم وتهم المحاور الأخرى.
كيف تختار: توصيات حسب حالة الاستخدام
لا يوجد فائز واحد هنا. بل توجد تطابقات بين الأداة وشكل النشر:
- فريق غير تقني يريد مكتبة خدمات: Coolify. كتالوج الـ 300+ قالب ميزة ذات وزن.
- مطوّر يعمل بـ Docker أصليًا ويريد خفّة وزن + معالجة قياسية لـ Compose: Dokploy.
- عتاد ARM64 (Raspberry Pi، أو VPS قائم على ARM): Coolify. لا يُعلن Dokploy عن دعم ARM64 في الوثائق الحالية؛ إن كنت على ARM، فاجعل Coolify الخيار الافتراضي حتى تتأكّد من خلاف ذلك.
- تجميع متعدّد العُقد ستستخدمه هذا الربع: Dokploy. Swarm الأصلي مقابل Swarm التجريبي هو العامل المرجّح.
- Apache 2.0 خالص، دون أي مستوى مدفوع مستقبلي محتمل: Coolify.
- الانتقال من Heroku والرغبة في الإبقاء على Heroku Buildpacks: Dokploy.
- قلق بشأن ثغرات CVE في يناير 2026: فإن Coolify المحدَّث (v4.0.0+) جيّد. السؤال الحقيقي هو نموذج تعريضك. إن لم تستطع ربط اللوحة بشبكة خاصة أو VPN، فإن Dokploy هو الخيار الأقل توترًا: سطح أصغر وتاريخ أقصر من الإفصاحات عالية الخطورة.
ملاحظة حول نشر أي من الأداتين
بمجرد أن تختار، يكون التثبيت نفسه أمرًا واحدًا على أي من المشروعين، لكن هناك اختصارًا يستحق المعرفة. كل من Coolify وDokploy متاح كنشر بنقرة واحدة في سوقنا، مع Ubuntu 24.04 وDocker مُثبَّتين مسبقًا واللوحة متاحة بالفعل. إن أردت تخطّي الإعداد اليدوي، فإن إدراجات السوق لـ Coolify و Dokploy هي أسرع مسار. وإن كنت تفضّل البدء من نظام تشغيل نظيف وتشغيل المثبّت الرسمي بنفسك، فإن كلا المشروعين ينشر سكربتًا من سطر واحد؛ اختر ما يناسب سير توفيرك.
الأسئلة الشائعة
هل لا يزال Dokploy مفتوح المصدر بعد تغيير الترخيص في 2026؟
نعم بالنسبة للمنصّة الأساسية. اعتبارًا من January 21, 2026، نواة Dokploy هي Apache 2.0 قياسي. وتحكم الآن Source Available License منفصلة من Dokploy الكود في proprietary/ المجلدات، المحصورة حاليًا في مزايا المؤسسات المستقبلية (SSO/SAML، وRBAC دقيق، وسجلّات تدقيق، وعلامة بيضاء). بالنسبة للاستخدام الفردي والمُستضاف ذاتيًا للفرق الصغيرة، فإن Dokploy مفتوح المصدر عمليًا.
هل لا تزال ثغرات Coolify الأمنية لشهر يناير 2026 مدعاة للقلق؟
ثغرات CVE الـ11 المُفصَح عنها مُصلَحة في Coolify v4.0.0 (الصادر في April 27, 2026). إن كنت تشغّل v4.0.0 أو أحدث، فإن الثغرات المُفصَح عنها مُعالَجة. ما يتبقّى هو التعرّض: أبقِ Coolify محدَّثًا ولا تعرّض اللوحة للإنترنت العام. اربطها بشبكة خاصة أو ضعها خلف VPN.
