طريقة تثبيت Cloudron على VPS جديد

تثبيت Cloudron على VPS: النسخة المختصرة

لتثبيت Cloudron على VPS، تحتاج إلى خادم Ubuntu جديد، وذاكرة RAM بسعة 2 GB على الأقل، ونطاق يمكنك تعديل سجلات DNS الخاصة به. يتطلب التثبيت نفسه تنفيذ 3 أوامر وإعادة تشغيل واحدة. تحدث معظم المشكلات قبل هذه الخطوة، بسبب استخدام صورة أساسية أو نوع افتراضية غير صحيح، أو بعدها، بسبب DNS أو البريد أو النسخ الاحتياطية.

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

يثبّت Cloudron التطبيقات المستضافة ذاتياً ويحدّثها وينشئ لها شهادات TLS (أمان طبقة النقل) وينفّذ نسخاً احتياطية منها. يعمل كل تطبيق داخل Docker، ويعمل nginx أمام جميع التطبيقات، ويحصل كل تطبيق على نطاق فرعي خاص ضمن نطاقك. ولهذا السبب تبدأ خطوات DNS أولاً هنا.

سبب تشدد Cloudron بشأن نظام التشغيل الأساسي

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

• Ubuntu فقط، وثلاثة إصدارات محددة فقط. عند استخدام أي خيار آخر يتوقف السكربت مع Cloudron requires Ubuntu 20.04, 22.04, 24.04. لا يدعم Debian أو Rocky أو Alpine. يحتاج Ubuntu 24.04 إلى Cloudron 8 أو إصدار أحدث، ويتحقق السكربت من ذلك نيابةً عنك.
• معالجات Intel أو AMD ذات 64 بت فقط: Error: Cloudron only supports amd64/x86_64. لا يمكن تشغيله على VPS يستخدم ARM.
• المحاكاة الافتراضية الكاملة للأجهزة فقط. على VPS قائم على الحاويات يتوقف السكربت مع Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization، لأنه يكتشف الحاوية باستخدام systemd-detect-virt --container. KVM مناسب. أما OpenVZ وLXC فغير مدعومين.
• يجب أن يكون نظام الملفات الجذر ext4 أو xfs. عند استخدام أي نظام آخر يظهر Error: Cloudron requires '/' to be ext4 or xfs، وهذا هو سبب فشل صور btrfs وzfs.
• يجب توفير 941 MB على الأقل من الذاكرة و20 GB على /، ويُقاس ذلك باستخدام free -m وحجم نظام الملفات الجذر.
• يجب أن يكون الخادم جديداً فعلياً. إذا كان nginx أو docker أو node مثبتاً بالفعل، يرفض السكربت المتابعة مع Error: Some packages like nginx/docker/nodejs are already installed.

هذا هو الفحص الذي يختلف الناس حوله، والسبب هو الآتي. يثبت Cloudron إصدارات محددة من Docker وnginx وNode.js وMySQL، ويكتب إعداد nginx لكل تطبيق يستضيفه، ويدير قواعد جدار iptables بنفسه. إن إصدار Docker الذي ثبته بالأمس هو الإصدار غير الصحيح، كما تُستبدل ملفات مواقع nginx الموجودة لديك. يملك Cloudron الخادم بأكمله، لذلك خصص له VPS مستقلاً.

من السهل تفويت فحص آخر. على معالج قديم لا يدعم AVX (امتدادات المتجهات المتقدمة)، يطبع السكربت CPU has no AVX support. MongoDB will be disabled، ويصبح كل تطبيق يحتاج إلى MongoDB غير قابل للتثبيت. افحص المعالج قبل الالتزام باستخدام grep -m1 -o avx /proc/cpuinfo، إذ يطبع avx على مضيف قادر على تشغيله ولا يطبع شيئاً على مضيف قديم.

ما مقدار RAM الذي يحتاج إليه Cloudron؟

يرفض البرنامج النصي العمل بأقل من 941 MB، مع Error: Cloudron requires atleast 1GB physical memory، وتطلب الوثائق 2 GB من RAM و20 GB من مساحة القرص. هذان الرقمان هما الحد الأدنى للمنصة، وليس للمنصة مع تطبيقاتك. قبل تثبيت تطبيق واحد، يكون Cloudron قد شغّل Docker وnginx وخدمة box الخاصة به وحاويات قواعد البيانات التي يوفّرها للتطبيقات (MySQL وPostgreSQL وMongoDB) وRedis ومجموعة خدمات البريد. شغّل docker ps على تثبيت جديد، ثم احسب عددها.

تُضاف حدود ذاكرة التطبيقات إلى هذه القاعدة. تأتي كل حزمة تطبيق بحد افتراضي منخفض، ويمكنك رفعه باستخدام شريط التمرير في طريقة عرض Resources الخاصة بالتطبيق. عندما يتجاوز التطبيق حده، يُعاد تشغيله، ويُرسل إليك إشعار OOM (نفاد الذاكرة). لذلك، يكون الخادم الذي يعيد تشغيل تطبيق واحد باستمرار غالباً يعاني من مشكلة في الحد، لا من خلل برمجي.

هذه هي مواصفات الخادم التي أوصي بطلبها. إنها توصيات لخادم لن تضطر إلى إعادة بنائه في الشهر المقبل. وليست نتائج قياس أداء فعلية.

[
  {
    "label": "2 apps (free tier)",
    "vcpu": 2,
    "ram_gb": 4,
    "disk_gb": 60
  },
  {
    "label": "5 apps",
    "vcpu": 4,
    "ram_gb": 8,
    "disk_gb": 120
  },
  {
    "label": "10 apps",
    "vcpu": 6,
    "ram_gb": 16,
    "disk_gb": 240
  }
]

يمكن تشغيل تطبيقين براحة على 4 GB من RAM و60 GB من مساحة القرص. تحتاج نحو عشرة تطبيقات إلى 16 GB و240 GB، لأن قاعدة المنصة لا تتقلص أبداً، ويضيف كل تطبيق صورة Docker وقاعدة بيانات وبياناته الخاصة. تمتلئ مساحة القرص أسرع مما يتوقعه الناس: إذ تشترك الصور وبيانات التطبيقات والنسخ الاحتياطية المحلية في وحدة تخزين واحدة إلى أن تنقل النسخ الاحتياطية خارج الخادم.

يمنح Cloudron كل تطبيق مساحة swap غير محدودة، لذلك ينطبق حد الذاكرة الذي تحدده على RAM فقط. في صورة VPS لا تحتوي على ملف swap، لا يعرض swapon --show أي مخرجات إطلاقاً، ويتحول ضغط الذاكرة مباشرة إلى عمليات إعادة تشغيل بسبب OOM بدلاً من تباطؤ التطبيق. تُعد إضافة 2 GB من swap إجراءً احتياطياً منخفض التكلفة، لكنها لا تحل محل الذاكرة الفعلية. الفارق بين خطط VPS صغير مقارنة بالساعات التي ستقضيها في ضبط الحدود، لذلك راجع التكلفة الفعلية لـVPS واشترِ الحجم التالي الأكبر.

DNS: سجل wildcard الذي يتيح عمل النطاقات الفرعية للتطبيقات

يضع Cloudron لوحة التحكم على my.example.com وكل تطبيق على نطاق فرعي مستقل، لذلك يُعد DNS متطلباً أساسياً وليس خطوة لاحقة. وجّه هذه السجلات إلى عنوان IP العام للخادم قبل فتح لوحة التحكم للمرة الأولى:

• my.example.com كسجل A. هذه هي لوحة التحكم.
• *.example.com كسجل A. هذا هو السجل الذي يتيح عمل النطاقات الفرعية للتطبيقات، لذلك سيُحلّ wiki.example.com وgit.example.com فور تثبيت هذين التطبيقين.
• example.com كسجل A، فقط إذا أردت تشغيل تطبيق على النطاق الأساسي من دون نطاق فرعي.

تكون أولوية سجل wildcard أقل من أولوية السجل الصريح، لذلك سيستمر السجل الموجود www.example.com، إذا كان يشير إلى مكان آخر، في العمل.

أثناء الإعداد، تختار كيفية تعامل Cloudron مع DNS بعد ذلك:

• موفّر API. يخزّن Cloudron token خاصاً بـ Cloudflare أو DigitalOcean أو Route53 أو Hetzner أو Porkbun أو Linode أو deSEC أو Gandi أو Namecheap ونحو عشرين موفراً آخر، ثم ينشئ كل سجل بنفسه، بما في ذلك سجلات البريد.
• Wildcard. تضيف سجل * يدوياً، ولا ينشئ Cloudron أي سجلات.
• Manual. يعرض Cloudron كل سجل وينتظر إضافته، قبل تثبيت كل تطبيق على حدة.

سجل wildcard في DNS ليس شهادة wildcard. موفّر الشهادة الافتراضي هو Let's Encrypt Prod - Wildcard، وهو يثبت ملكية النطاق عبر DNS، لذلك لا يعمل إلا مع موفّر API. عند استخدام Wildcard أو Manual، ستعود إلى شهادة واحدة لكل تطبيق، ويُتحقق منها عبر HTTP، ما يعني ضرورة إبقاء المنفذ 80 الوارد مفتوحاً دائماً. إذا كان المسجّل أو مضيف DNS لديك مدرجاً في قائمة API، فاستخدمه؛ عندها لن تعود سجلات البريد والشهادات من مسؤوليتك.

تحقق قبل المتابعة. يجب أن يعرض dig +short my.example.com وdig +short anything.example.com عنوان IP الخاص بخادمك. إذا لم يعرض استعلام wildcard أي نتيجة، فسيفشل تشغيل التطبيقات لاحقاً، بينما ستعمل لوحة التحكم بصورة طبيعية.

إذا كان النطاق خلف Cloudflare، فاضبط السجلات على DNS only. يمرر الوكيل HTTP وHTTPS فقط، لذلك ستتعطل منافذ البريد، وسيرى كل تطبيق عنوان Cloudflare بدلاً من عنوان الزائر.

شغّل برنامج الإعداد

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

شغّله بصفة root أو باستخدام sudo، لأن أول ما يطبعه خلاف ذلك هو This script should be run as root.. يستغرق التثبيت عدة دقائق، ولا يعرض مخرجات أثناء عمله، لأن مخرجات apt وعمليات السحب من Docker تُكتب في ملف سجل. راقب الملف من جلسة SSH ثانية:

tail -f /var/log/cloudron-setup.log

في النهاية، يطبع After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. متبوعاً بعنوان خادمك، ثم يسألك The server has to be rebooted to apply all the settings. Reboot now ? [Y/n]. أجب بنعم. يتوفر الخيار --skip-reboot إذا احتجت إلى جدولة إعادة التشغيل، لكن لا يمكن استخدام Cloudron حتى يعود الخادم إلى العمل.

الإقلاع الأول: النطاق وواجهة DNS الخلفية وحساب المسؤول

افتح https://<server-ip> واقبل تحذير المتصفح. الشهادة موقعة ذاتياً لأن Cloudron لا يعرف نطاقك بعد، ولذلك لا يملك ما يطلب بسببه شهادة من جهة إصدار الشهادات. في Chrome انقر على Advanced، ثم Proceed to <ip> (unsafe). في Firefox انقر على Advanced، ثم Accept the Risk and Continue.

تطلب الشاشة الأولى نطاقك. أدخل example.com، ثم تصبح لوحة التحكم متاحة على my.example.com. يمكنك استخدام نطاق فرعي مثل cloudron.example.com بدلاً من ذلك، وعندها تصبح لوحة التحكم متاحة على my.cloudron.example.com. اختر واجهة DNS الخلفية، والصق رمز API إذا كان لديك واحد، وأنشئ حساب المسؤول باستخدام عنوان بريد إلكتروني تتابعه فعلاً؛ إذ يُستخدم هذا العنوان لتسجيل Let's Encrypt ولكل تنبيهات المنصة.

عند الحفظ، يطلب Cloudron الشهادات وينقل لوحة التحكم إلى https://my.example.com. يتوقف عنوان URL الذي يستخدم عنوان IP عن العمل عندئذ، لذا احفظ العنوان الجديد في الإشارات المرجعية.

الشهادات: ما الذي يجدّدها، ومتى يتوقف التجديد

يتم تجديد الشهادة تلقائياً وفق ACME Renewal Information (ARI)، وهو الجدول الذي تنشره الجهة المصدرة للشهادة. وعملياً، يحدث التجديد قبل انتهاء الصلاحية بنحو شهر. يرسل التجديد الفاشل رسالة بريد إلكتروني إلى حساب المسؤول، وتعود الخدمة عند انتهاء صلاحية الشهادة إلى الشهادة الموقّعة ذاتياً المضمّنة. وهذا ما يعنيه تحذير المتصفح عند زيارة موقع كان يعمل في اليوم السابق.

هناك سببان وراء معظم الحالات. يتطلب التحقق عبر HTTP استقبال الاتصالات الواردة على المنفذ 80. لذلك، يؤدي إغلاق المنفذ 80 بحجة أن «كل شيء يستخدم HTTPS على أي حال» إلى تعطيل التجديد لكل تطبيق يستخدم Wildcard أو Manual DNS كخلفية. ويتطلب التحقق عبر DNS رمز API لا يزال يملك صلاحية الكتابة. لذلك، يؤدي تدوير هذا الرمز أو تقليص صلاحياته إلى تعطيل التجديد بصمت، إلى أن تصل رسالة التحذير عبر البريد الإلكتروني.

تحتوي واجهة Domains على زر Renew All لفرض محاولة التجديد فوراً، كما توفر موفّر Let's Encrypt Staging للاختبار. تكون شهادات Staging غير موثوقة من المتصفحات عمداً، وهذا هو الغرض منها: يمكنك إعادة المحاولة بالقدر الذي تريده من دون استهلاك حد معدل الإنتاج.

هل ينبغي استخدام خادم البريد المضمّن؟

يأتي Cloudron مع منظومة بريد كاملة تتضمن صناديق بريد IMAP، والإرسال عبر submission، ومرشحات sieve، وتوقيع DKIM (domainkeys identified mail). يمكنك تفعيله لكل نطاق من قسم Email في لوحة التحكم. تكمن الصعوبة الحقيقية في إيصال البريد، وهذه الصعوبة ليست من Cloudron.

• يحظر معظم موفري VPS المنفذ الصادر 25 للحد من الرسائل المزعجة. وقد يفتحونه بعد إرسال طلب إلى الدعم. اختبر ذلك من الخادم باستخدام nc -zv aspmx.l.google.com 25 (ثبّت netcat-openbsd إذا لم يكن الأمر متاحاً). يعرض فحص المنافذ النتيجة succeeded، بينما يظل المنفذ المحظور عالقاً حتى انتهاء مهلة الاتصال.
• يضبط موفر VPS سجل PTR (نظام DNS العكسي)، وليس مضيف DNS، ويجب أن يطابق اسم مضيف البريد. تصل الرسائل المرسلة من عنوان ذي سجل PTR عام إلى مجلدات الرسائل المزعجة.
• تُنشأ سجلات SPF وDKIM وDMARC تلقائياً عند استخدام واجهة DNS المعتمدة على API. أما في واجهتي Wildcard وManual، فعليك إضافتها يدوياً. ويعني غياب سجل DKIM أن كل رسالة توقّعها لا يمكن التحقق منها.

الإعداد المناسب لمعظم المستخدمين هو استقبال البريد على Cloudron وإرساله عبر مرحّل مثل SendGrid أو Postmark أو Mailgun أو Amazon SES، بعد ضبطه من عرض Email. يجب أن يسمح المرحّل بالإرسال باستخدام أي عنوان على نطاقك، وإلا فستُرفض إشعارات التطبيقات المرسلة من عناوين مختلفة. إذا كان البريد هو السبب الرئيسي لشراء الخادم، فشغّل خادم بريد مخصصاً مثل Mailcow على جهاز مستقل له سمعته الخاصة لعنوان IP.

إذا لم تستخدم Cloudron Email إطلاقاً، فاحظر المنافذ 25 و465 و587 و993 و4190 في جدار الحماية لدى موفر الخدمة. نفّذ ذلك هناك وليس على الخادم، لأن Cloudron يكتب قواعد iptables بنفسه ويتوقع أن يديرها. وهذا عكس VPS عادي، حيث تدير قواعد ufw بنفسك.

اضبط وجهة النسخ الاحتياطي قبل أن تحتاج إليها

تُحفظ النسخ الاحتياطية افتراضياً في نظام الملفات المحلي ضمن /var/backups، على القرص نفسه الذي توجد عليه بقية البيانات. توضح الوثائق ذلك بصرامة: "وجود النسخ الاحتياطية على القرص الفعلي نفسه الذي يوجد عليه خادم المنصة أمر خطير." فأي قرص يتعطل يؤدي إلى فقدان التطبيقات والنسخ الاحتياطية معاً.

افتح Backups، ثم Backup Sites، وحدد وجهة مختلفة منذ اليوم الأول. عادةً ما يكون تخزين الكائنات المتوافق مع S3 هو الخيار المناسب، مثل Backblaze B2 وWasabi وCloudflare R2 وDigitalOcean Spaces أو حاوية MinIO على خادم ثانٍ، كما تتوفر وجهات SSHFS وNFS وCIFS ونظام الملفات العادي أيضاً.

تحدد 3 إعدادات ما إذا كانت هذه النسخة الاحتياطية مفيدة فعلاً:

• Format. ينشئ tgz أرشيفاً مضغوطاً واحداً لكل تطبيق، ثم يعيد رفعه بالكامل في كل تشغيل. أما rsync فيرفع الملفات التي تغيّرت فقط، وهذا أقل تكلفة بكثير مع تطبيق Nextcloud كبير، لكنه يزيد عدد الطلبات المرسلة إلى واجهة برمجة التخزين.
• Encryption. تشفير اختياري باستخدام AES-256، ويشمل محتوى الملفات وأسماءها. لا يحتفظ Cloudron بنسخة من كلمة المرور، لذلك يعني فقدانها تعذر فك تشفير النسخ الاحتياطية على أي شخص، بمن فيهم أنت. خزّنها في مدير كلمات مرور مستضاف ذاتياً قبل النقر على زر الحفظ.
• Retention. تُكتب هذه القيمة على شكل أعداد، مثل 7 نسخ يومية و4 نسخ أسبوعية. يؤدي الاحتفاظ الطويل بالنسخ على تخزين الكائنات إلى رسوم شهرية مستمرة، لذلك اختر عدداً مستعداً لمواصلة دفع تكلفته.

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

حدود الخطة المجانية

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

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

عند حدوث عطل

ابدأ بالفحص المضمّن. يفحص DNS والشهادات ومساحة القرص والذاكرة وكل خدمة بالتتابع، ويحدد الاختبار الذي فشل:

sudo cloudron-support --troubleshoot

بعد ذلك، استخدم أدوات systemd المعتادة لإدارة النظام والخدمات. يعرض systemctl status box حالة خدمة Cloudron نفسها، ويعرض journalctl -u box -n 100 سجلاتها الأخيرة، بينما يفحص journalctl -u docker بيئة تشغيل الحاويات الأساسية. تُحفظ كل الأخطاء التي حدثت أثناء التثبيت في /var/log/cloudron-setup.log.

إذا تعذر تحميل لوحة التحكم، فغالباً يكون السبب DNS أو جدار حماية المزوّد، وليس Cloudron. شغّل dig +short my.example.com من حاسوبك المحمول، وتأكد من أن المنفذين 80 و443 مفتوحان في جدار حماية شبكة المزوّد. هذا الجدار منفصل عن قواعد الخادم نفسه. إذا كنت تبدأ من جديد، يرفض البرنامج النصي تشغيله مرة ثانية عبر Error: Cloudron is already installed. To reinstall, start afresh. ويكون إنشاء خادم جديد هو الحل الأنظف.

عندما لا يكون Cloudron مناسباً

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

FAQ

ما مقدار RAM الذي يحتاج إليه Cloudron على VPS؟

يرفض نص الإعداد العمل عند أقل من 941 MB، وتطلب الوثائق 2 GB، لكن هذا هو الحد الأدنى للمنصة من دون تطبيقات. يشغّل Cloudron Docker وnginx وخدمة box الخاصة به وحاويات قواعد البيانات وحزمة البريد منذ الإقلاع الأول. خصص 4 GB لتطبيقين و16 GB لنحو عشرة تطبيقات، وأضف ملف swap، لأن Cloudron يمنح التطبيقات swap غير محدود، والخادم الذي لا يحتوي عليه يحوّل ضغط الذاكرة إلى عمليات إعادة تشغيل.

هل يمكنني تثبيت Cloudron على Debian أو على خادم يشغّل Docker مسبقاً؟

لا يعمل أي من الخيارين. يتحقق النص من الإصدار ويتوقف مع Cloudron requires Ubuntu 20.04, 22.04, 24.04، لذلك لا يمكن استخدام Debian أو Rocky أو Alpine. كما يتوقف عندما يكون nginx أو docker أو node موجوداً مسبقاً، لأنه يثبّت إصدارات محددة من جميع هذه المكونات ويكتب إعداد nginx وقواعد iptables بنفسه. ابدأ من صورة Ubuntu جديدة على VPS يعمل عبر KVM.

لماذا تفشل النطاقات الفرعية لتطبيقاتي بينما تعمل لوحة التحكم؟

سجل DNS العام غير موجود. ينشئ الإعداد أو يتطلب سجل A لـ my.example.com، لذلك يُحل اسم لوحة التحكم، بينما يعيد wiki.example.com النتيجة NXDOMAIN ويبلغ المتصفح بأن الموقع غير موجود. أضف سجل A لـ *.example.com يشير إلى عنوان IP للخادم، ثم تحقّق باستخدام dig +short wiki.example.com قبل تثبيت التطبيق.

هل يجب أن أستخدم خادم البريد في Cloudron؟

لا. يمكنك تعطيل البريد الوارد وإرسال البريد عبر مرحّل خارجي مثل Postmark أو Mailgun أو Amazon SES. هذا هو الخيار الأكثر أماناً عندما يحظر مزود الخدمة المنفذ الصادر 25 أو لا يتمتع عنوان IP بسمعة بريدية. إذا تخطيت Cloudron Email بالكامل، فأغلق المنافذ 25 و465 و587 و993 و4190 في جدار حماية مزود الخدمة، وليس على الخادم.

ماذا يحدث عندما أصل إلى حد التطبيقين في الخطة المجانية؟

تحظر لوحة التحكم تثبيت التطبيق الثالث وتطلب مفتاح ترخيص. لا تتأثر التطبيقات التي تشغّلها مسبقاً؛ فهي تواصل التحديث، وتستمر في إنشاء النسخ الاحتياطية، وتحتفظ بشهاداتها. تؤدي إضافة ترخيص إلى رفع الحد من دون إعادة تثبيت أي شيء، لذلك تُعد الخطة المجانية وسيلة مناسبة لاختبار المنصة على نطاق حقيقي أولاً.