Cloudron مقابل CasaOS مقابل Coolify على VPS

ما الذي تبنيه

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

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

المتطلبات المشتركة والمطبات الصريحة

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

وفيما عدا ذلك تتباين الأرقام، وهذا أول ما يوجّه الاختيار.

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

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

Cloudron: الجهاز الجاهز الأنيق والمتشدد في اختياراته

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

التثبيت. يصرّ Cloudron على جهاز نظيف ويستولي عليه بالكامل. نفّذ هذا على خادم 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.

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

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 حديثة ولا شيء غيرها: لا خادم ويب، ولا Docker، ولا حتى جدار حماية تكون قد ضبطته يدويًا. وإذا كنت قد أقلعت الصورة الخطأ، يرفض الإعداد أيضًا أي شيء ليس إصدار LTS مدعومًا من Ubuntu (22.04 أو 24.04) على معمارية x86-64؛ فـARM وLXC وOpenVZ غير مدعومة إطلاقًا.

نمط الفشل الثاني: الشهادات الشاملة تحتاج إلى API لـ DNS. اختر خيار DNS «Manual» أثناء الإعداد بدلًا من إعطاء Cloudron رمز API، ولن يستطيع عندها إنشاء سجلات أو شهادة شاملة نيابة عنك. كل تطبيق جديد بعدها يفرض عليك إضافة سجل 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 وأخواتها). تأكد من أن البوابة (gateway) بدأت قبل أن تفتح متصفحًا:

systemctl status casaos-gateway

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

إضافة أول تطبيق. افتح متجر التطبيقات، اختر تطبيقًا، انقر تثبيت. يكتب CasaOS مشروع Docker Compose من خلف الكواليس ويعرض التطبيق على منفذ في المضيف، مثلًا http://<your-ip>:8080. يحمل متجره التشكيلة المعتادة لخوادم المنزل، لذا فإن خادم وسائط Jellyfin على VPS أو مكتبة صور Immich مستضافة ذاتيًا على بُعد نقرتين. ويمكنك أيضًا استيراد أي ملف 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 مباشرة أبدًا. ضع أمامه وكيلًا عكسيًا ينهي TLS، مثل nginx بشهادة Let's Encrypt من Certbot، أو Caddy، أو Cloudflare Tunnel، ووجّه الاتصال إلى CasaOS على الشبكة المحلية فقط. لاحظ أن CasaOS يشغل المنفذ 80 مسبقًا، لذا سيتنازع وكيلك العكسي وCasaOS على هذا المنفذ ما لم تنقل CasaOS إلى منفذ آخر أولًا.

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

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

ما هو. Coolify منصة كخدمة (PaaS) مفتوحة المصدر ومستضافة ذاتيًا، على غرار Heroku أو Vercel لكن على جهازك الخاص. وحدته الأصلية ليست «ثبّت هذا التطبيق المعبأ» بل «انشر هذا المستودع من Git»: اربط مستودعًا، ويبنيه Coolify (عبر Nixpacks أو ملف Dockerfile خاص بك) وينشره، معيدًا النشر مع كل دفعة (push). كما يقدّم قواعد بيانات وخدمات بنقرة واحدة. يستهدف المطورين الذين ينشرون شيفرتهم الخاصة ويريدون نشرًا بالدفع (push-to-deploy) من دون استئجار 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 أو رابط مستودع بسيط)، اختر فرعًا، اضبط النطاق، وانشر. يوجّه وكيل Traefik المدمج في Coolify النطاق الفرعي ويطلب الشهادة. أما بالنسبة إلى البرمجيات الجاهزة، فإن كتالوج الخدمات ينشر الأشياء في نقرتين: فـحزمة أتمتة سير العمل n8n نفسها التي كنت لتوصّلها يدويًا لولا ذلك مُدخل واحد فيه، وكذلك Uptime Kuma لمراقبة صفحة الحالة.

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

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

نمط الفشل: التطبيق يُنشر لكن نطاقه لا يفتح. تعمل واجهة التحكم جيدًا على http://<ip>:8000، ويصبح البناء أخضر، لكن رابط التطبيق نفسه يعيد خطأ اتصال أو رسالة 404 page not found من Traefik. هذا يشير إلى الوكيل أو إلى DNS، لا إلى تطبيقك. سببان شائعان. أولًا، كان المنفذ 80 أو 443 مأخوذًا مسبقًا حين حاول الوكيل أن يبدأ، فماتت حاويته بخطأ من 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 (socket) الخاص بالخادم إطلاقًا، وعادة ما يكون السبب خدمة Docker متوقفة أو مفتاح SSH معطوبًا. اقرأ السبب الحقيقي في السجلات قبل أن تخمّن:

docker logs coolify-proxy --tail 100

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

العبء على الموارد في الجهاز نفسه

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

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

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

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

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

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

أيها تختار

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

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

كن صادقًا بشأن حجمك. إذا كنت تشغّل تطبيقًا أو تطبيقين فقط، أو تريد أن تفهم وتتحكم بالضبط بما هو موجود على جهازك، فتجاوز اللوحات. العبء والتقيّد لا يستحقان العناء من أجل مكدّس صغير ومستقر. المسار اليدوي هو وكيل عكسي أمام ملفات 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 نفسها بعبء أقل بكثير وبلا أي تقيّد. تُثمر اللوحات حين تشغّل تطبيقات كثيرة ووقتك يساوي أكثر من ذاكرة RAM التي تكلفك إياها.

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

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

هل Cloudron مجاني؟

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

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

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

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

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