Portainer أم Coolify أم Dokploy؟ مقارنة لاختيار أداة إدارة التطبيقات على خادمك

عندما يكون على السيرفر Server تطبيق أو تطبيقان، فإدارة Docker من الطرفية Terminal أمر مقبول، تكتب docker ps وتقرأ السجلات Logs وتعدل ملف Compose ثم تعيد تشغيله وينتهي الموضوع، ولكن بعد أشهر قليلة سوف تجد على السيرفر عشرة تطبيقات أو أكثر، وسوف ينضم إلى الفريق مطورون يريدون أن ينشروا تعديلاتهم بأنفسهم دون أن ينتظروا من يملك صلاحية الدخول إلى السيرفر.

وهنا تبدأ في البحث عن أداة تستضيفها بنفسك وتدير بها كل ذلك من المتصفح، وسوف تجد أمامك نوعين من الأدوات، النوع الأول واجهة إدارة ترى فيها ال Containers وتعدل منها ملفات Compose التي تكتبها أنت، ومثاله الأشهر Portainer CE، والنوع الثاني منصة نشر يدفع إليها فريقك الكود Code من Git فتبنيه وتنشره وتعطيه نطاقاً وشهادة TLS بنفسها، ومن أشهر أمثلتها Coolify وDokploy، وكل واحدة من الأدوات الثلاث صممت لطريقة عمل مختلفة، لذلك لن تجد في هذا المقال فائزاً واحداً وإنما سوف تجد الأنسب لحالتك وحالة فريقك.

وهذه أدلة التثبيت والاستخدام التي نقارن بينها:

دليلتثبيت Portainer لإدارة حاويات Docker من المتصفحإذا كنت تفضل الواجهة على سطر الأوامر، فإن Portainer يتيح لك إدارة الـ Containers من المتصفح. نثبته خطوة بخطوة، ونشغل منه أول تطبيق، ونضيف إليه خادماً ثانياً.دليلتثبيت Coolify لنشر التطبيقات من Git على خادمكانشر تطبيقاتك من Git على خادمك بضغطة زر، كما تفعل في Heroku أو Vercel. نثبت Coolify بأمان، وننشر أول تطبيق بنطاق وشهادة HTTPS، ونجهز النسخ الاحتياطي لقواعد البيانات.دليلتثبيت Dokploy لنشر تطبيقاتك من Git على خادمكمنصة مفتوحة المصدر تنشر تطبيقاتك من Git على خادمك، على طريقة Vercel. نثبت Dokploy بأمان، وننشر تطبيقاً وملف Compose بنطاق وشهادة HTTPS لكل منهما، ونجهز النسخ الاحتياطي.

وسوف نناقش في هذا المقال ما يلي:

• الفرق بين واجهة الإدارة Management UI ومنصة النشر PaaS، والسؤال الذي يحدد أي النوعين تحتاج.
• معايير المقارنة التي تهمك في التشغيل اليومي، وجدول يلخص الفروق بين الأدوات الثلاث في إصداراتها الحالية.
• كل أداة على حدة بنقاط قوتها ونقاط ضعفها، مع رابط دليل التثبيت والاستخدام الخاص بها على الموقع.
• لماذا تحتاج Coolify وDokploy إلى سيرفر مستقل، وهل تشغل Portainer بجانب إحداهما.
• توصية واضحة لكل حالة، ثم الخلاصة.

ما الفرق بين واجهة الإدارة ومنصة النشر PaaS؟

Portainer واجهة ويب Web UI لإدارة Docker وDocker Swarm وKubernetes، فأنت تكتب ملف Compose أو تختار Image جاهزة، وهو ينفذها ويعرض لك الـ Containers والسجلات والـ Volumes والشبكات Networks، وبالتالي فهو يدير ما تعده أنت ولا يقرر شيئاً عن تطبيقك، ويشبه لوحة العدادات في السيارة، تريك كل شيء وتسمح لك بالتحكم، ولكن القيادة تبقى عليك.

أما Coolify وDokploy فمنصتان من نوع المنصة كخدمة Platform as a Service واختصاراً PaaS، تستضيفهما على سيرفرك على طريقة Heroku وVercel، حيث تربط المنصة بمستودع Repository في Git، فتبني Build التطبيق مع كل دفع Push وتنشره، وتسجل له نطاقاً Domain وتطلب له شهادة TLS عبر Reverse Proxy مدمج، وتنشئ أيضاً قواعد البيانات Databases وتجدول نسخها الاحتياطية Backups، وتنشر بيئة معاينة Preview Deployment مستقلة لكل طلب دمج Pull Request.

لذلك ابدأ بسؤال «من يكتب ملف التشغيل؟» قبل سؤال «أي الثلاثة أفضل؟»، فإذا كان فريق العمليات Operations يكتب ملفات Compose ويديرها فإن Portainer يكفي غالباً، وإذا أراد المطورون أن ينشروا تطبيقاتهم بأنفسهم من Git دون أن ينتظروا أحداً فأنت تبحث عن منصة PaaS، والسبب أن المنصة تأخذ عنك قرارات البناء والتوجيه والشهادات، وهذا ما تريده في الحالة الثانية وما لا تريده في الأولى.

جدول المقارنة

قبل الجدول سوف نحدد المعايير التي نقارن بها، فهي ما يهمك عندما تدير السيرفر يوماً بعد يوم، وليست قائمة الخصائص التي تجدها في الصفحة الرئيسية لكل مشروع:

• الغرض والنمط Purpose: هل الأداة واجهة تدير ما تكتبه أنت، أم منصة تبني وتنشر بالنيابة عنك، وهذا يحدد من يعمل عليها في فريقك.
• البناء والنشر Build and Deploy: هل تبني الأداة التطبيق من الكود في Git، وهل تنشره تلقائياً عند كل دفع، وهل تعطي كل طلب دمج بيئة معاينة.
• التوجيه والشهادات Routing and TLS: هل في الأداة Reverse Proxy مدمج يسجل النطاقات ويطلب شهادات Let's Encrypt، أم أن هذا عملك أنت.
• قواعد البيانات والنسخ الاحتياطي Databases and Backups: هل تنشئ الأداة قواعد البيانات وتنسخها إلى مخزن خارجي متوافق مع S3.
• تعدد السيرفرات Multi-server: كيف تضيف سيرفراً ثانياً، وهل تستطيع تكرار التطبيق على أكثر من سيرفر.
• المستخدمون والصلاحيات Users and Permissions: ماذا تعطيك النسخة المجانية، وما الذي يحتاج إلى ترخيص مدفوع.
• الترخيص والنضج License and Maturity: من يطور المشروع، ومنذ متى، وما الذي يبقى مفتوح المصدر.

والجدول التالي يلخص الفروق في الإصدارات التي اعتمدنا عليها، وأخذنا أرقامه من الوثائق الرسمية وصفحات الإصدارات حتى أكتوبر 2026، ولاحظ أن الأسعار تتغير، فراجعها في صفحة كل جهة قبل الشراء.

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

Portainer CE لمن يكتب ملفات التشغيل بنفسه

يعمل Portainer في Container واحد يتصل بـ Docker عبر الـ socket، ولا يحتاج إلى منفذ Port عام غير منفذ واجهته 9443، لذلك تستطيع أن تضيفه إلى سيرفر يعمل عليه Nginx Proxy Manager وعدد من ملفات Compose دون أن تغير شيئاً في البنية القائمة، وتجد خطوات التثبيت وتشغيل أول تطبيق وإضافة سيرفر ثان في دليل تثبيت Portainer.

الصورة التالية تبين لوحة البيئة المحلية في Portainer بعد أن ثبتناه على سيرفر تجريبي، وفيها عدد الـ Stacks والـ Containers والـ Images والـ Volumes والشبكات Networks التي على السيرفر:

نقاط القوة

• يعرض كل ما على السيرفر، سواءً أنشأته من واجهته أو من الطرفية، فتقرأ منه السجلات وتفتح طرفية داخل الـ Container دون أن تحفظ أوامر Docker.
• يدير أكثر من سيرفر من واجهة واحدة عبر Portainer Agent، أما السيرفرات التي لا تقبل اتصالاً وارداً فتضيفها عبر Edge Agent.
• ينشر Stack من مستودع Git ويحدثه تلقائياً عندما يتغير الـ Commit، بالاستطلاع الدوري أو بـ Webhook، وهذا نمط GitOps بسيط يكفي لملفات Compose التي يحفظها الفريق في Git.
• يدعم Docker Swarm وKubernetes وPodman، وبالتالي إذا تغيرت البنية لاحقاً فلن تضطر إلى تغيير الأداة.

نقاط الضعف

• لا يبني تطبيقك من الكود كما تفعل منصات PaaS، وإنما ينفذ ملف Compose أو Image جاهزة، وميزة بناء الـ Images فيه محدودة، فهي لا تقبل ADD أو COPY لملفات من السيرفر.
• لا يعطي كل تطبيق نطاقاً وشهادة تلقائياً، فهذا عملك أنت في الـ Reverse Proxy.
• الأدوار التفصيلية RBAC، وWebhook الـ Stack المستقل عن Git، ونسخ الإعدادات إلى S3 كلها في Business Edition فقط، أما في CE فتجد المدير والمستخدم العادي مع فرق تحدد من يرى أي مورد.
• نسخته الاحتياطية تشمل إعداداته فقط، ولا تشمل بيانات التطبيقات التي ينشرها، لذلك انسخ الـ Volumes بطريقة أخرى.

Coolify للنشر من Git مع خدمات جاهزة

تثبت Coolify على سيرفر مخصص لها، ثم تضيف إليها سيرفرات أخرى فتتصل بها عبر SSH وتنشر عليها التطبيقات دون Agent دائم، وتوصي صفحة التثبيت الرسمية بتثبيتها على سيرفر جديد حتى لا تتعارض مع التطبيقات القائمة، وتجد خطوات التثبيت الآمن ونشر أول تطبيق ونسخ قواعد البيانات كاملة في دليل تثبيت Coolify.

الصورة التالية تبين صفحة إضافة مورد Resource جديد في Coolify بعد أن ثبتناها على سيرفر تجريبي وأنشأنا فيها مشروعاً باسم example-shop، وفيها طرق النشر المتاحة، من مستودع Git عام أو خاص إلى Dockerfile وملف Compose وDocker Image جاهزة:

نقاط القوة

• طرق نشر متعددة، فتنشر من مستودع Git تبنيه بـ Nixpacks أو Railpack أو Dockerfile، أو من ملف Compose، أو من Image جاهزة.
• بيئات معاينة لكل طلب دمج، لكل منها نطاق مستقل ومتغيرات بيئة Environment Variables خاصة بها.
• كتالوج كبير من الخدمات تنشرها بنقرة واحدة One-click Services، وكل خدمة منها ملف Compose جاهز يصونه المشروع.
• ثمانية محركات لقواعد البيانات، خمسة منها تدعم النسخ الاحتياطي المجدول محلياً أو إلى مخزن متوافق مع S3.
• كل الميزات الحالية والقادمة مجانية في النسخة التي تستضيفها بنفسك، كما تقول صفحة المقارنة الرسمية، ولا يوجد فرق في الميزات بينها وبين Coolify Cloud.

نقاط الضعف

• الصلاحيات على مستوى الفريق كله، فلا تستطيع حصر عضو في مشروع أو بيئة بعينها، والعضو Member يقرأ فقط ولا ينشر، لذلك تحتاج إلى فريق منفصل لكل مجموعة تريد عزلها.
• دعم Docker Swarm أضيف كميزة تجريبية ولم يكتمل، وهو الآن مهمل وسوف يحذف في v5 لتحل محله النسخ المتعددة Replicas في Compose، والبديل الموصى به حتى ذلك الحين أن تنشر التطبيق على عدة سيرفرات مستقلة خلف موزع حمل Load Balancer خارجي.
• تعدل المنصة ملف Compose قبل تنفيذه، فتضيف أسماء وLabels وشبكات ومتغيرات مثل SERVICE_URL_* كما تشرح صفحة Docker Compose، والنتيجة أن ملفك لا يطابق تماماً ما يعمل فعلاً.
• تحتاج المنفذين 80 و443 لـ Reverse Proxy خاص بها، وتحتاج أيضاً المنافذ 8000 و6001 و6002 للوحة قبل أن تربطها بنطاق، والتفاصيل في صفحة جدار الحماية Firewall.

Dokploy لمن يبني على Compose وSwarm

عند التثبيت يهيئ Dokploy الـ Docker Swarm على السيرفر، ثم يشغل خدماته وTraefik فوقه، ويجب أن تكون المنافذ 80 و443 و3000 متاحة وإلا فشل التثبيت، وتجد خطوات التثبيت ونشر تطبيق وملف Compose والنسخ الاحتياطي كاملة في دليل تثبيت Dokploy.

الصورة التالية تبين صفحة مشروع تجريبي باسم example-shop في Dokploy بعد التثبيت، وعندما تضغط على Create Service تظهر لك أنواع الخدمات التي تنشئها، وهي التطبيق Application وقاعدة البيانات Database وملف Compose والقالب Template الجاهز:

نقاط القوة

• دعم Compose بنمطين، الأول Docker Compose العادي، والثاني Stack الذي ينشر الملف على Swarm، ولاحظ أن build لا يعمل في نمط Stack.
• ثلاثة خيارات لمكان التشغيل، الأول سيرفر Dokploy نفسه، والثاني سيرفرات بعيدة مستقلة عبر SSH لكل منها Traefik خاص، والثالث عقد Swarm تكرر التطبيق على أكثر من سيرفر، وهنا يحتاج العنقود إلى Container Registry تسحب منه العقد الـ Images.
• صلاحيات مجانية لكل مشروع وخدمة وبيئة، فتستطيع مثلاً أن تسمح لعضو بإنشاء الخدمات في مشروع واحد فقط.
• نسخ مجدول لقواعد البيانات إلى S3، ونسخ للـ Volumes المسماة، ونشر تلقائي عبر Webhooks أو API.
• قوالب Templates جاهزة للخدمات الشائعة، محفوظة في مستودع مستقل.

نقاط الضعف

• ما زال في سلسلة 0.x والإصدارات متقاربة، لذلك اقرأ ملاحظات الإصدار قبل كل تحديث Upgrade.
• بيئات المعاينة مصممة لتطبيقات GitHub، وتنصح الوثائق بعدم تفعيلها في المستودعات العامة، والسبب أن أي شخص يفتح طلب دمج يستطيع عندها تشغيل بناء على سيرفرك.
• الأدوار المخصصة وسجل التدقيق والدخول الموحد وSCIM وتغيير العلامة Whitelabeling ميزات Enterprise تحتاج إلى ترخيص تجاري.
• لا ينظف Dokploy مساحة التخزين تلقائياً على عقد العنقود غير سيرفره الرئيسي، فعليك أن تجدول ذلك بنفسك.
• لا توجد نسخ مجدولة لقواعد Redis، فإذا كانت فيها بيانات تحتاجها فانسخ الـ Volume الخاص بها.

ماذا يعني ترخيص Dokploy عملياً؟

يقول ملف الترخيص إن كل ما في المستودع مرخص بـ Apache-2.0 إلا المجلدات المسماة proprietary، فهذه تخضع لـ Dokploy Source Available License ولا يجوز استخدامها في بيئة الإنتاج Production دون اتفاق تجاري، وفيها ميزات Enterprise المذكورة أعلاه، وبالتالي فالنشر من Git وقواعد البيانات والنسخ والسيرفرات البعيدة والعنقود كلها برخصة مفتوحة، أما إدارة الهوية والتدقيق فمدفوعة.

لماذا تحتاج Coolify وDokploy إلى سيرفر مستقل؟

كل منصة منهما تشغل Traefik خاصاً بها على المنفذين 80 و443، والسبب أنها تسجل نطاقات التطبيقات وتطلب شهاداتها تلقائياً، ولا يستطيع برنامجان الاستماع على المنفذ نفسه، فإذا كان على سيرفرك Nginx Proxy Manager أو Caddy أو Nginx فسوف يرفض Dokploy التثبيت، وسوف تتعارض Coolify مع الـ Reverse Proxy القائم.

وتسمح Coolify بـ تعطيل الـ Proxy المدمج واستخدام توجيه خارجي، ولكنك عندها تخسر أهم ما تأخذه من المنصة، وهو النطاق والشهادة التلقائيان لكل تطبيق، لذلك خصص للمنصة سيرفراً جديداً أو أكثر، واترك السيرفر القائم بملفاته وNginx Proxy Manager كما هو. ولفهم الفرق بين هذه الأدوات راجع مقارنة Nginx Proxy Manager وTraefik وHAProxy ودليل تثبيت Traefik.

أما حجم السيرفر، فالحد الأدنى الرسمي لـ Coolify معالجان 2 CPU و2 GB ذاكرة و10 GB قرص، ولـ Dokploy 2 GB ذاكرة و30 GB قرص، وهذه الأرقام للمنصة وحدها، فأضف إليها ما تستهلكه عمليات البناء وقواعد البيانات والتطبيقات. وإذا وضعت التطبيقات على سيرفرات بعيدة، فالسيرفر الذي يشغل الواجهة وحدها يستهلك قرابة 250 MB من الذاكرة بحسب وثائق Dokploy، ولتقدير الموارد واختيار المزود راجع كيف تختار خادماً افتراضياً VPS.

هل تشغل Portainer بجانب Coolify أو Dokploy؟

نعم، وكل منصة منهما توفره قالباً جاهزاً، وهما قالب Coolify وقالب Dokploy، ويفيدك Portainer هنا في العرض والتشخيص Troubleshooting، فترى فيه كل الـ Containers والـ Volumes على السيرفر، وتقرأ السجلات، وتفتح طرفية داخل Container عند الحاجة، ولكن انتبه إلى أربعة أمور:

• المنصة هي المرجع، فأي تعديل تجريه من Portainer على Container أنشأته Coolify أو Dokploy سوف يمحوه النشر التالي، والسبب أن المنصة تعيد إنشاء الـ Container من إعداداتها.
• يستخدم القالبان وسوماً Tags متغيرة للـ Image، وهي alpine في قالب Coolify وlatest في قالب Dokploy، لذلك ثبت الوسم على إصدار محدد كما يفعل دليل Portainer.
• يصل Portainer إلى /var/run/docker.sock، وهذا يعني أن من يدخل إليه يملك السيرفر عملياً، فقيد الوصول إليه بكلمة مرور قوية، والأفضل أن يكون عبر شبكة خاصة.
• يعمل Dokploy في نمط Swarm، فتظهر خدماته في Portainer على أنها Swarm Services، وإذا ربطت عقداً إضافية فراجع طريقة إضافة بيئة Swarm عبر Agent لترى العنقود كاملاً.

أيها تختار؟

لديك ملفات Compose وNginx Proxy Manager تعمل منذ مدة

اختر Portainer، والسبب أنه يضيف لك الواجهة والسجلات وإدارة الـ Stacks دون أن يلمس منافذك أو الـ Reverse Proxy القائم، وإذا كانت ملفاتك في Git ففعل تحديث الـ Stack من المستودع، فيصبح لديك نشر تلقائي بسيط دون منصة كاملة، وإذا كان السيرفر جديداً فابدأ من تثبيت Docker على Ubuntu ثم انتقل إلى دليل Portainer.

فريق تطوير ينشر تطبيقاته من Git ويحتاج إلى بيئات معاينة

اختر Coolify أو Dokploy على سيرفر مستقل، فكلاهما يبني من الكود، ويعطي كل تطبيق نطاقاً وشهادة، وينشر بيئة معاينة لكل طلب دمج. وإذا كانت مستودعاتك على GitLab أو Bitbucket أو Gitea فتأكد من الوثائق أن بيئات المعاينة تدعم مزودك قبل أن تعتمد عليها، والسبب أن الوثائق الحالية للمنصتين تركز على GitHub، ولا تفعل بيئات المعاينة في مستودع عام، ففي Coolify يبقى الخيار Allow Public PR Deployments معطلاً إلا إذا قبلت أن يشغل أي شخص كوده على سيرفرك.

ولاحظ أن المنصة التي تربطها بحسابك في GitHub تحتفظ بتوكن Token أو مفتاح تطبيق GitHub App يصل إلى مستودعاتك، فإذا وصل مخترق إلى سيرفر المنصة وصل معه إلى الكود وإلى ما فيه من أسرار، لذلك امنح التطبيق المستودعات التي تنشرها فقط وليس كل مستودعات المؤسسة، ولا تحفظ الأسرار Secrets في الكود.

تريد تشغيل خدمات مفتوحة المصدر جاهزة بأقل جهد

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

تعتمد على Docker Compose كثيراً، أو تحتاج إلى عدة عقد في Swarm

Dokploy أنسب لك، والسبب أنه يقبل ملفات Compose كما هي ويضيف إليها التوجيه، وينشرها على Swarm عند الحاجة، ويسمح بعنقود من عدة عقد في نسخته المجانية، وصلاحياته لكل مشروع مفيدة إذا كان لكل فريق مشروعه، وضع في حسابك أن الدخول الموحد وسجل التدقيق يحتاجان إلى ترخيص Enterprise.

مؤسسة تشترط الدخول الموحد وسجل التدقيق

هنا تحدد الميزانية الخيار بقدر ما تحدده التقنية، فهذه المتطلبات في Portainer ضمن Business Edition، وفي Dokploy ضمن Enterprise، أما Coolify فتدعم الدخول عبر OAuth من GitHub وGitLab وBitbucket وAzure وغيرها، ولكن صلاحياتها أقل تفصيلاً، لذلك قارن الخطط المدفوعة بحسب متطلبات الامتثال Compliance لديك وليس بحسب السعر وحده.

القرار في جدول واحد

الخلاصة

• Portainer لمن يكتب ملفات التشغيل بنفسه ويريد أن يراها ويديرها من المتصفح، ويعمل بجانب أي بنية قائمة، وخطواته في دليل تثبيت Portainer.
• Coolify لمن يريد منصة نشر مجانية بكل ميزاتها مع كتالوج خدمات كبير، على سيرفر مخصص لها، وخطواتها في دليل تثبيت Coolify.
• Dokploy لمن يبني على Compose وSwarm ويريد صلاحيات لكل مشروع، مع العلم أن ميزات الهوية والتدقيق فيه مدفوعة، وخطواته في دليل تثبيت Dokploy.
• لا تثبت Coolify أو Dokploy على سيرفر يعمل عليه Reverse Proxy آخر، وأنشئ حساب المدير فور انتهاء التثبيت، وامنح المنصة أقل صلاحية على مستودعاتك.

سجل التحديثات (Changelog)

• أكتوبر 2026: كتابة المقال.
• أكتوبر 2026: مراجعة تقنية على Portainer CE 2.45.1 LTS وCoolify v4.3.23 وDokploy v0.30.8، فصححنا طرق البناء في Dokploy (Railpack وHeroku Buildpacks وPaketo Buildpacks ونوع Static) وفي Coolify (نوع Static)، وأوضحنا أن نسخ Dokploy المجدول لا يشمل Redis، وأن Coolify تقبل Caddy أو العمل بدون Proxy، وأن دعم Swarm فيها تجريبي ويحذف في v5، وأضفنا روابط أدلة التثبيت الثلاثة ونقاط الضعف لكل أداة وجدول القرار.
• أكتوبر 2026: أضفنا لقطة شاشة لكل أداة من تثبيت تجريبي قمنا به بأنفسنا، ومربعاً في نهاية قسم كل أداة يوصلك إلى دليل تثبيتها، وربطنا أسماء الأدوات في جدول المقارنة بأدلتها.