مقارنة Cloudron وCasaOS وCoolify على خادم VPS

ما الذي ستبنيه

أنت تختار أداة بقدر ما تقوم بتثبيت أداة. تعدك ثلاث لوحات بتحويل VPS خام إلى مضيف تطبيقات يعمل بالنقر: Cloudron وCasaOS وCoolify. يضع هذا الدليل كل لوحة على نفس خادم Ubuntu 24.04 الجديد، ويثبّت تطبيقاً أول، ثم يفحص الجوانب التي لا تظهر في لقطات الشاشة: TLS، والنسخ الاحتياطية، والتحديثات، واستهلاك الذاكرة، ومدى صعوبة المغادرة. في النهاية ستعرف أيها يناسبك، أو ما إذا كانت الإجابة الصادقة هي: "لا تستخدم أياً منها، بل استخدم Docker Compose فقط."

لا توجد أداة سحرية هنا. تعمل اللوحات الثلاث كلها فوق Docker Engine نفسه الذي يمكنك تشغيله يدوياً. وما تبيعه لك اللوحة، سواءً مقابل المال أو RAM أو الارتباط بها، هو تنفيذ أربع مهام نيابةً عنك: تثبيت التطبيقات بنقرة واحدة، وشهادات TLS تلقائياً، والنسخ الاحتياطية المجدولة، وإدارة المستخدمين. إذا كانت هذه المهام الأربع تستحق النفقات الإضافية الفعلية بالنسبة إليك، فإن استخدام اللوحة مبرر. أما إذا كنت تشغّل خدمة أو خدمتين وتفضّل معرفة كل ما يوجد على خادمك بدقة، فاقرأ قسم "تجاوز اللوحات الثلاث كلها" أولاً، ووفّر على نفسك العناء.

المتطلبات المشتركة والمشكلات التي يجب معرفتها

تفترض الحلول الثلاثة استخدام خادم VPS يعمل بظ virtualisation من نوع KVM، وليس virtualisation للحاويات. يحتاج Docker إلى kernel حقيقي، كما يرفض Cloudron صراحةً OpenVZ وLXC. تحقّق باستخدام systemd-detect-virt: تكون kvm أو qemu مناسبة، بينما لا تكون openvz أو lxc مناسبة. في خطة KVM يطبع الأمر kvm، وعلى bare metal يطبع none؛ ويعني أي منهما أنّه يمكنك المتابعة.

تختلف المتطلبات الأخرى، وهذا أول ما يوجّه الاختيار.

• RAM. يعمل CasaOS بسلاسة على 1GB؛ فقد تطوّر على عتاد Raspberry Pi ولا يزال خفيفاً. يتطلب Coolify ذاكرة 2GB ونواتي CPU كحد أدنى، ويستهلك Coolify نفسه نحو 600 MB من ذلك. يحتاج Cloudron إلى 2GB كحد أدنى، ويعمل بصورة أفضل فعلياً مع 4GB، لأنّه يشغّل mail server وقاعدة بيانات قبل تثبيت تطبيق واحد.
• نطاق وDNS تتحكم فيهما. يتطلب كل من Cloudron وCoolify نطاقاً حقيقياً مع DNS يعمل. ويفضّل Cloudron إتاحة API لدى موفّر DNS حتى يتمكن من إنشاء السجلات والشهادات wildcard بنفسه. يعمل CasaOS على IP مجرّد، لكنك لن تحصل عندئذٍ على TLS.
• المنافذ. تحتاج الحلول الثلاثة إلى فتح المنفذين 80 و443 من أجل HTTP وHTTPS. ويعرض Coolify لوحة التحكم أيضاً على المنفذ 8000، ويستخدم 6001 لقناة realtime و6002 للطرفية داخل المتصفح. أبقِ المنفذ 22 مفتوحاً لـSSH في كل حل منها.

وجّه DNS إلى الخادم قبل البدء. لا يمكن للوحة التي لا تستطيع حل اسم المضيف الخاص بها طلب شهادة، وستقضي الساعة الأولى في تصحيح هذه المشكلة بدلاً من إعداد البرنامج. أنشئ سجل A يشير إلى IP الخادم، وأضف في Coolify سجل wildcard (*.apps.example.com) حتى يحصل كل تطبيق منشور على نطاق فرعي خاص به.

Cloudron: الجهاز المتكامل المصقول ذو الرأي المحدد

ما هو. Cloudron منصة تجارية تحوّل خادماً كاملاً إلى جهاز مُدار. تشغّل reverse proxy وقاعدة بيانات وحزمة بريد خاصة بها، إضافة إلى App Store منتقاة من التطبيقات المعبأة، مثل Nextcloud وWordPress وGitea وMattermost وغيرها. تستهدف المنصة من يريدون إدارة تطبيقاتهم تلقائياً، مع تحديثات وشهادات ونسخ احتياطية تلقائية، ومن يقبلون الدفع مقابل ذلك.

التثبيت. تتطلب خادماً نظيفاً وتستولي عليه بالكامل. شغّل الأمر التالي على خادم Ubuntu 24.04 (Noble) جديد، ولا تشغّل أي شيء آخر:

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

يثبّت البرنامج النصي Docker وnginx وقاعدة بيانات وحزمة البريد، ثم يعيد تشغيل الخادم. بعد عودة الخادم، افتح https://<your-ip>، واقبل الشهادة المؤقتة الموقعة ذاتياً، وأكمل الإعداد في المتصفح: اربطه بنطاقك، واختر مزود DNS، وسيجهّز لوحة التحكم الخاصة به على my.example.com.

إضافة التطبيق الأول. افتح App Store في لوحة التحكم، وانقر على Nextcloud مثلاً، واختر النطاق الفرعي files.example.com، ثم اضغط Install. ينشئ Cloudron سجل DNS، ويطلب شهادة Let's Encrypt، ويجهّز قاعدة البيانات، ويربط تسجيل الدخول الموحّد، ويجدول نسخة احتياطية، وكل ذلك دون أن تلمس ملف إعداد. هذه هي الفكرة الأساسية للمنتج، وهو يحققها فعلاً.

TLS والنسخ الاحتياطية. هذا أقوى الجوانب الثلاثة. يحصل كل نطاق فرعي لتطبيق على شهادة Let's Encrypt تلقائية تُجدَّد نيابةً عنك. تُجدول النسخ الاحتياطية وتكون مدمجة في المنصة، مع توجيهها إلى مجلد محلي أو S3 أو وحدة تخزين بعيدة أخرى، واستعادة كل تطبيق على حدة، وحتى استنساخ التطبيق إلى نطاق فرعي جديد بنقرة واحدة.

التكلفة والترخيص، اقرأ هذا قبل الالتزام. Cloudron منتج مدفوع مع خطة مجانية محدودة: تسمح الخطة المجانية بـ تطبيقين. عند تثبيت تطبيق ثالث، تصل إلى جدار الدفع؛ ويتيح الاشتراك المدفوع، Pro أو Max، مع فوترة شهرية أو سنوية وكلاهما يدعم عدداً غير محدود من التطبيقات، مزايا إضافية. هذه أهم حقيقة عن Cloudron. فهو مصقول تحديداً لأنه منتج تجاري، والخطة المجانية أقرب إلى نسخة تجريبية ممتدة منها إلى بيئة مناسبة لمجموعة تطبيقات متنامية.

نمط الفشل، قاعدة الخادم النظيف. إذا حاولت تثبيت Cloudron على خادم يشغّل شيئاً مسبقاً، يتوقف الإعداد قبل أن يغيّر أي شيء:

Error: Some packages like nginx/docker/nodejs are already installed. Cloudron requires
specific versions of these packages and will install them as part of it's installation.
Please start with a fresh Ubuntu install and run this script again.

السبب ليس التشدد بلا مبرر. يثبت Cloudron إصدارات محددة من nginx وDocker وNode ويدمجها بعمق، لذلك لا يمكنه التعايش مع النسخ الخاصة بك. الحل هو استخدام صورة Ubuntu 24.04 جديدة ولا شيء آخر: لا web server، ولا Docker، ولا حتى جدار ناري أعددته يدوياً. إذا أقلعت باستخدام الصورة الخطأ، فسيرفض الإعداد أيضاً أي نظام ليس Ubuntu LTS مدعوماً، أي 22.04 أو 24.04، على x86-64؛ أما ARM وLXC وOpenVZ فغير مدعومة إطلاقاً.

نمط الفشل الثاني، شهادات wildcard تحتاج إلى DNS API. إذا اخترت خيار DNS ‏"Manual" أثناء الإعداد بدلاً من تزويد Cloudron برمز API، فلن يتمكن من إنشاء السجلات أو إصدار شهادة wildcard نيابةً عنك. عندئذٍ يتطلب كل تطبيق جديد أن تضيف سجل DNS يدوياً قبل إصدار الشهادة، وتبقى لوحة التحكم في انتظار ذلك السجل. امنح Cloudron صلاحية API لدى مزود DNS مدعوم، مثل Cloudflare أو Route 53 أو DigitalOcean وغيرهم، وستصبح العملية كلها بنقرة واحدة.

CasaOS: لوحة التحكم المجانية للمختبر المنزلي

ماهيتها. CasaOS، من IceWhale، لوحة تحكم مجانية ومفتوحة المصدر تعمل فوق Docker وتوفّر لك شاشة رئيسية ومتجر تطبيقات ومدير ملفات. نشأت في بيئة الخوادم المنزلية، لذلك تركز على المختبر المنزلي: إعداد سريع، وواجهة سهلة، وإجراءات تشغيل محدودة. تستهدف المستخدمين الذين يريدون واجهة أفضل لـDocker دون دفع أي رسوم.

التثبيت. يكفي سطر واحد، ولا يشترط وجود نظام نظيف:

curl -fsSL https://get.casaos.io | sudo bash

يضيف المثبّت مجموعة من خدمات systemd (casaos وcasaos-gateway وcasaos-app-management وغيرها). تأكد من بدء البوابة قبل فتح المتصفح:

systemctl status casaos-gateway

بعد تشغيلها، تتوفر لوحة التحكم على http://<your-ip> (بروتوكول HTTP عادي، والمنفذ 80). أنشئ حساباً محلياً ثم سجّل الدخول.

إضافة التطبيق الأول. افتح متجر التطبيقات، واختر تطبيقاً، ثم انقر على Install. ينشئ CasaOS مشروع Docker Compose في الخلفية، ويعرض التطبيق على منفذ في الخادم، مثل http://<your-ip>:8080. يضم متجره مجموعة التطبيقات المعتادة للخوادم المنزلية، لذلك لا يتطلب إعداد خادم وسائط Jellyfin على VPS أو مكتبة صور Immich مستضافة ذاتياً سوى بضع نقرات. إذا لم تكن قد اخترت خادم صور بعد، فمن المفيد أولاً قراءة الحد الأدنى من RAM وتطبيقات الهاتف التي تميّز بين PhotoPrism وImmich، لأن هذا الاختيار يحدد، على جهاز CasaOS بسعة 1GB، ما إذا كان التطبيق سيعمل أصلاً. يمكنك أيضاً استيراد أي docker-compose.yaml تريده، وهذه هي نقطة القوة الفعلية: التطبيقات حاويات عادية وليست تنسيقاً مملوكاً.

TLS والنسخ الاحتياطية، نقطة الضعف. هنا تظهر حدود كلمة «مجاني». يقدّم CasaOS كل شيء عبر HTTP العادي افتراضياً، بما في ذلك لوحة التحكم نفسها. لا يتضمن Let's Encrypt مدمجاً، ولا يتضمن نسخاً احتياطية مجدولة. توجد بياناتك في وحدات Docker ضمن /DATA، وتقع مسؤولية نسخها الاحتياطي عليك (عبر restic أو tar يعمل بواسطة cron).

نمط الفشل: لا يوجد TLS، ولا يظهر ذلك بوضوح. لا يظهر أي خطأ. تثبّت تطبيقاً، وتفتح http://<your-ip>:8080، فيعمل عبر اتصال غير مشفّر يعرض المتصفح بجانبه عبارة "غير آمن". تنتقل كلمات المرور وملفات تعريف ارتباط الجلسات عبر الشبكة بنص واضح. والأسوأ أن لوحة تحكم CasaOS شهدت ثغرات فعلية لتنفيذ التعليمات البرمجية عن بُعد (CVE-2023-37265 وCVE-2023-37266؛ إذ أتاحت إحداها تجاوز المصادقة، ثم استُغلت للوصول الكامل إلى الخادم)، لذلك فإن تعريض منفذ HTTP مباشرة للإنترنت يمثل خطراً حقيقياً، وليس مجرد اختلاف في الأسلوب. الحل هو عدم تعريض CasaOS مباشرة للإنترنت مطلقاً. ضع reverse proxy أمامه لإنهاء TLS، مثل nginx مع شهادة Let's Encrypt من Certbot، أو Caddy، أو Cloudflare Tunnel، ووجّه الاتصالات إلى CasaOS عبر الشبكة المحلية فقط. لاحظ أن CasaOS يرتبط بالمنفذ 80 مسبقاً، لذلك سيتنافس الـproxy معه على المنفذ نفسه ما لم تنقل CasaOS إلى منفذ آخر أولاً.

التكلفة. مجاني فعلاً إلى الأبد، ومن دون حد لعدد التطبيقات. لكنك تتحمل تكاليف التشغيل: أنت المسؤول عن TLS والنسخ الاحتياطية وتعزيز الأمان.

Coolify: منصة PaaS ذاتية الاستضافة

ماهيتها. Coolify منصة مفتوحة المصدر وذاتية الاستضافة كخدمة، على غرار Heroku أو Vercel ولكن على خادمك الخاص. وحدتها الأساسية ليست «تثبيت تطبيق مُحزَّم»، بل «نشر مستودع Git»: صِل مستودعاً، وسيبنيه Coolify باستخدام Nixpacks أو Dockerfile الخاص بك، ثم ينشره ويعيد نشره مع كل push. كما يوفر قواعد بيانات وخدمات يمكن نشرها بنقرة واحدة. تستهدف المنصة المطورين الذين ينشرون شيفرتهم بأنفسهم ويريدون النشر عند تنفيذ push دون استئجار PaaS.

التثبيت.

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

يثبّت السكربت Docker ويشغّل مجموعة الحاويات الخاصة بـCoolify. تحقق من سلامتها قبل المتابعة:

docker ps --format 'table {{.Names}}\t{{.Status}}'

يجب أن ترى coolify وcoolify-db وcoolify-redis وcoolify-realtime وcoolify-proxy، وأن تعرض جميعها الحالة Up. توجد لوحة التحكم في http://<your-ip>:8000. أنشئ حساب المسؤول فوراً، لأن صفحة التسجيل تبقى مفتوحة حتى إنشاء الحساب الأول، وأول من يصل إليها يتحكم في الخادم. بعد ذلك، عيّن نطاق نسختك وأضف سجل DNS شامل (*.example.com أو *.apps.example.com) يشير إلى الخادم، حتى يتمكن Coolify من منح كل تطبيق منشور نطاقاً فرعياً خاصاً به.

إضافة أول تطبيق. صِل مصدر Git، مثل GitHub أو GitLab أو عنوان URL لمستودع عادي، واختر فرعاً، وعيّن النطاق، ثم انشر التطبيق. يوجّه Traefik المضمّن في Coolify النطاق الفرعي ويطلب الشهادة. أما البرامج الجاهزة، فينشرها كتالوج Services في بضع نقرات: حزمة n8n لأتمتة سير العمل التي قد تضطر إلى إعدادها يدوياً هي أحد الإدخالات، وكذلك Uptime Kuma لمراقبة صفحات الحالة.

TLS والنسخ الاحتياطية. يوفّر Traefik المضمّن شهادات Let's Encrypt تلقائية لكل تطبيق، ولذلك يحصل كل نطاق فرعي منشور على شهادة. تركز النسخ الاحتياطية على قواعد البيانات: يمكنك جدولة نسخ Postgres وMySQL إلى مساحة تخزين متوافقة مع S3. أما النسخ الاحتياطي الكامل للنسخة، أي إعداد Coolify نفسه الموجود تحت /data/coolify، فهو يتطلب خطوات يدوية أكثر؛ لذلك صدّره وخزّنه بنفسك.

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

حالة الفشل: يُنشر التطبيق، لكن لا يفتح نطاقه. تعمل لوحة التحكم جيداً على http://<ip>:8000، وينجح البناء، لكن عنوان URL الخاص بالتطبيق يعرض خطأ اتصال أو خطأ 404 page not found من Traefik. يشير ذلك إلى مشكلة في الـproxy أو DNS، وليس في التطبيق. هناك سببان شائعان. أولاً، كان المنفذان 80 أو 443 مستخدمين مسبقاً عندما حاول الـproxy البدء، فتوقفت حاويته وظهر خطأ من Docker:

Error response from daemon: driver failed programming external connectivity on endpoint coolify-proxy: Bind for 0.0.0.0:443 failed: port is already allocated

ثانياً، سجل DNS الشامل مفقود، ولذلك لا يتلقى Traefik طلباً لهذا اسم المضيف. أما إذا عرضت بطاقة الخادم بأكملها في Coolify العبارة "Server is not reachable"، فهذه مشكلة مختلفة: لا يستطيع Coolify الاتصال بمقبس Docker الخاص بالخادم إطلاقاً، ويكون السبب عادةً توقف Docker daemon أو تلف مفتاح SSH. اقرأ السبب الفعلي في السجلات قبل التخمين:

docker logs coolify-proxy --tail 100

أصلح المشكلة من صفحة Proxy: اضغط Restart Proxy، أو أعد إعدادات الـproxy إلى الإعدادات الافتراضية وابدأ تشغيله مجدداً، ثم انتظر نحو دقيقتين حتى يستقر. اجعل المنفذ 8000 متاحاً من عنوان IP الخاص بك فقط، أو أعد فتحه مؤقتاً عندما يتعطل الـproxy، بدلاً من تركه مفتوحاً للعالم؛ فهو يقدّم لوحة التحكم عبر HTTP غير المشفّر. وتذكر وثائق Coolify نفسها أنه يمكن إغلاق المنافذ 8000 و6001 و6002 بعد تقديم لوحة التحكم عبر نطاقها الخاص.

النفقات العامة على الموارد في VPS نفسه

تم قياس هذه القيم أثناء الخمول على الخادم نفسه بسعة 4GB، وقبل نشر أي حمل فعلي. تحقّق من خادمك باستخدام free -m وdocker stats --no-stream بدلاً من الاعتماد على رقم واحد، لأن الإجمالي يتغير بحسب مزيج التطبيقات لديك.

• CasaOS هو الأخف. تتكون لوحة التحكم من مجموعة صغيرة من خدمات Go؛ وتوقع نفقات عامة تتراوح تقريباً بين 150 و300 MB فوق ما تشغّله من حاويات.
• Coolify يشغّل عدة حاويات دعم خاصة به، بما في ذلك التطبيق وPostgres وRedis وخدمة realtime وTraefik، لذلك يستهلك نحو 600 MB إلى 1 GB أثناء الخمول قبل نشر أي شيء.
• Cloudron هو الأثقل أثناء الخمول، لأنه يشغّل nginx وقاعدة البيانات ومجموعة خدمات البريد والمراقبة الخاصة به، سواء استخدمتها أم لا؛ لذلك خصص له 1 إلى 1.5 GB أثناء الخمول. ولهذا يطلب 2GB كحد أدنى، ويعمل براحة أكبر عند 4GB.

على VPS صغير بسعة 2GB، يترك CasaOS أكبر مساحة للتطبيقات الفعلية، بينما يترك Cloudron أقل مساحة. إذا كانت خطتك بسعة 2GB وتريد تشغيل Cloudron مع خادم البريد الخاص به، فخطط لترقية الخادم.

مقارنة التحديثات والنسخ الاحتياطية والارتباط بالمنصة

التحديثات. يحدّث Cloudron المنصة وكل تطبيق وفق جدول اختبره مسبقاً: وهذا يتطلب أقل جهد ويوفر أكبر قدر من التوجيه. يحدّث Coolify نفسه من لوحة التحكم الخاصة به بنقرة واحدة. يحدّث CasaOS اللوحة من خلال برنامج التثبيت أو apt، لكنك مسؤول عن جلب التطبيقات التي ثبّتها وإعادة تشغيلها.

الارتباط بالمنصة، المشكلة التي تظهر في السنة الثانية. يرتبط CasaOS بالمنصة بدرجة أقل من غيره: فتطبيقاته مشاريع Compose عادية، ويمكنك نسخ docker-compose.yaml وvolumes الموجودة تحت /DATA إلى أي مضيف آخر ومتابعة العمل. يقع Coolify في المنتصف: عمليات النشر تعتمد على Dockerfiles ومستودعاتك، لكن إعداداتها محفوظة في قاعدة بيانات Coolify، لذلك يتطلب نقل المضيفين إعادة إنشاء المشاريع على الجانب الآخر. أما Cloudron فهو الأكثر ارتباطاً بالمنصة: فتطبيقاته مغلّفة بتنسيق Cloudron، ومع أنّ بياناتك تنتقل بسلاسة عبر نسخه الاحتياطية الممتازة، فإن التغليف لا ينتقل معها، ولذلك تعيد النشر على المنصة الوجهة. البيانات قابلة للنقل، أما مكونات التشغيل فلا.

أيّها ينبغي أن تختار

الخلاصة أولاً، ثم البديل العملي. اختر Cloudron إذا كنت تريد أقل خادم يتطلب إدارة يدوية من بين الخيارات الثلاثة، وستشغّل عدة تطبيقات جاهزة، وتقبل دفع رسوم سنوية مقابل TLS المُدار والنسخ الاحتياطية والتحديثات. اختر CasaOS إذا كان هذا مختبراً منزلياً خلف شبكتك الخاصة أو Reverse Proxy، وتريد واجهة سهلة لإدارة Docker، وترفض دفع أي رسوم. اختر Coolify إذا كنت تنشر شيفرتك الخاصة من Git، وتريد النشر عند دفع التغييرات مع TLS تلقائي، من دون تكلفة PaaS مستضاف. إذا لم ينطبق عليك أي من هذه الخيارات الثلاثة، فالقسم التالي هو الإجابة الصريحة.

تجاوزها جميعاً إذا...

كن صريحاً بشأن حجم بيئتك. إذا كنت تشغّل تطبيقاً أو تطبيقين فقط، أو تريد أن تعرف وتتحكم بدقة في كل ما يوجد على خادمك، فتجاوز لوحات الإدارة. لا تستحق الأعباء التشغيلية والارتباط بمنصة معينة ذلك في بيئة صغيرة ومستقرة. المسار اليدوي هو وضع reverse proxy أمام ملفات Compose الخاصة بك: يوفّر لك Traefik مع TLS تلقائي أمام عدة تطبيقات Docker Compose HTTPS مكافئاً لما توفره اللوحات بنقرة واحدة، من دون أعباء اللوحة، ويمكنك إجراء النسخ الاحتياطي باستخدام مهمة restic مجدولة عبر cron وتفهمها فعلياً.

services:
  whoami:
    image: traefik/whoami
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.rule=Host(`whoami.example.com`)
      - traefik.http.routers.whoami.tls.certresolver=le
    networks: [web]
networks:
  web:
    external: true

بالنسبة إلى تطبيق رئيسي واحد، تكون الحالة أوضح: يتطلب تثبيت Nextcloud على Docker مع TLS وروتين النسخ الاحتياطي الخاص به ملف Compose واحداً وشهادة واحدة. سيكون إعداد جهاز متكامل لتشغيله تكلفةً بلا فائدة. إذا كنت لا تزال تقرر ما الذي ستشغّله قبل أن تقرر كيف ستشغّله، فسيكون دليل ما يستحق الاستضافة الذاتية في 2026 نقطة بداية أفضل.

FAQ

هل أحتاج فعلاً إلى لوحة للاستضافة الذاتية؟

فقط إذا كنت تثمّن الأمور الأربعة التي تؤتمتها اللوحة عبر عدة تطبيقات: التثبيت بنقرة واحدة، وTLS التلقائي، والنسخ الاحتياطية المجدولة، وإدارة المستخدمين. بالنسبة إلى خدمة أو خدمتين، ينفّذ Docker Compose العادي خلف Traefik مهمة TLS نفسها مع عبء أقل بكثير ومن دون أي ارتهان لمورّد. تصبح اللوحات مفيدة عندما تدير تطبيقات كثيرة وتكون قيمة وقتك أعلى من تكلفة الذاكرة التي تستهلكها.

ما أفضل لوحة للمبتدئ؟

بالنسبة إلى مختبر منزلي لا يكون مكشوفاً للإنترنت غير الموثوق، يُعد CasaOS أسهل بداية: أمر واحد وواجهة سهلة، من دون رسوم. لكن يجب وضع reverse proxy ينهي TLS أمامه قبل تعريض أي شيء للإنترنت، لأنه يأتي مع HTTP عادي. إذا أردت أن تتولى الخدمة إدارة TLS والنسخ الاحتياطية نيابةً عنك، وكنت مستعداً للدفع، فإن Cloudron هو الخيار الأكثر توجيهاً للمستخدم، ضمن حدّه المجاني البالغ تطبيقين.

هل Cloudron مجاني؟

جزئياً. تتيح الخطة المجانية تطبيقين، وهذا مناسب لتجربته أو لإعداد صغير جداً. بعد ذلك، يكون Cloudron اشتراكاً مدفوعاً تُحصّل رسومه شهرياً أو سنوياً، مع تطبيقات غير محدودة في الخطط المدفوعة. إنه منتج تجاري ذو خطة مجانية محدودة، وليس برنامجاً حراً، لذلك خصّص له ميزانية إذا كان مكدسك سيتوسع.

هل يمكنني تشغيل هذه اللوحات بجانب تطبيقاتي الحالية؟

Cloudron: لا. فهو يتطلب خادماً نظيفاً يعمل بـ Ubuntu ويتوقف إذا كان nginx أو Docker أو Node مثبتاً مسبقاً، لأنه يدير الجهاز بأكمله. أما CasaOS وCoolify فهما أكثر توافقاً، إذ يثبت كل منهما مكدس Docker الخاص به ويمكنه، من حيث المبدأ، مشاركة الخادم. لكن كليهما يريد المنفذين 80 و443، لذلك سيتعارض مع أي خادم ويب أو proxy تشغّله مسبقاً. في خادم يستضيف خدمات حالياً، تكون اللوحة عادةً الأداة غير المناسبة؛ استخدم Traefik وCompose بدلاً منها.

كيف أنتقل بعيداً عن لوحة لاحقاً؟

خطط للخروج قبل أن تحتاج إليه. من CasaOS، انسخ docker-compose.yaml الخاص بالتطبيق وvolumes الخاصة به /DATA إلى الخادم الجديد، ثم شغّلهما مجدداً. من Coolify، صدّر إعدادات كل مشروع، واربطه بالمستودعات نفسها على الوجهة. من Cloudron، استعد البيانات من نسخه الاحتياطية داخل تطبيقات مثبّتة حديثاً على المنصة الجديدة، لأن حزم Cloudron لا تنتقل؛ الذي ينتقل هو البيانات فقط. في كل حالة، اختبر الاستعادة على خادم مؤقت قبل إيقاف الخادم القديم.