نصب Cloudron روی VPS اوبونتو، از صفر تا اجرا

نصب Cloudron روی یک VPS: نسخه کوتاه

برای نصب Cloudron روی یک VPS، به یک سرور Ubuntu تازه، حداقل 2 GB رم و دامنه‌ای که بتوانید رکوردهای DNS آن را ویرایش کنید، نیاز دارید. فرآیند نصب شامل سه دستور و یک بار راه‌اندازی مجدد (reboot) است. تقریباً تمام مشکلاتی که رخ می‌دهد، پیش از این مرحله (به دلیل ایمیج پایه اشتباه یا نوع مجازی‌سازی نامناسب) یا پس از آن (به دلیل DNS، ایمیل یا بک‌آپ‌ها) ایجاد می‌شوند.

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

نرم‌افزار Cloudron وظیفه نصب، به‌روزرسانی، تهیه نسخه پشتیبان و صدور گواهی‌های TLS (امنیت لایه انتقال) برای برنامه‌های self-hosted را بر عهده دارد. هر برنامه در یک Docker اجرا می‌شود، nginx در مقابل همه آن‌ها قرار می‌گیرد و هر برنامه زیردامنه (subdomain) اختصاصی خود را از دامنه شما دریافت می‌کند. همین نکته آخر دلیل اصلی اولویت داشتن تنظیمات DNS در این راهنما است.

چرا Cloudron نسبت به سیستم‌عامل پایه سخت‌گیر است

اسکریپت راه‌اندازی پیش از هرگونه نصب، سرور را بررسی می‌کند و شکست در هر یک از این بررسی‌ها به معنای نیاز به تهیه یک سرور جدید است. پیش از انتخاب Image، این موارد را مطالعه کنید.

• فقط Ubuntu و تنها سه نسخه خاص. هر سیستم‌عامل دیگری باعث خروج با کد Cloudron requires Ubuntu 22.04, 24.04, 26.04 می‌شود. نسخه Ubuntu 20.04 رد می‌شود و مستندات نصب اکنون یک سرور تازه Ubuntu 26.04 را درخواست می‌کنند. Debian، Rocky و Alpine پشتیبانی نمی‌شوند. نسخه Ubuntu 24.04 به Cloudron 8 یا جدیدتر نیاز دارد و اسکریپت این مورد را برای شما بررسی می‌کند.
• فقط معماری 64-bit اینتل یا AMD: Error: Cloudron only supports amd64/x86_64. یک VPS با معماری ARM نمی‌تواند آن را اجرا کند.
• فقط مجازی‌سازی کامل سخت‌افزاری (Full hardware virtualization). روی یک VPS مبتنی بر کانتینر، اسکریپت با کد Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization متوقف می‌شود، زیرا کانتینر را با استفاده از systemd-detect-virt --container شناسایی می‌کند. KVM مناسب است، اما OpenVZ و LXC خیر.
• فایل‌سیستم ریشه (root filesystem) باید ext4 یا xfs باشد. در هر مورد دیگری با Error: Cloudron requires '/' to be ext4 or xfs مواجه می‌شوید؛ این همان دلیلی است که Imageهای btrfs و zfs با شکست مواجه می‌شوند.
• حداقل 941 MB رم که با free -m اندازه‌گیری می‌شود و 18 GB فضا روی / که به عنوان اندازه فایل‌سیستم ریشه سنجیده می‌شود. پیام خطا 20GB را درخواست می‌کند، اما خودِ بررسی، فایل‌سیستم ریشه 19 GB را تأیید می‌کند.
• یک سرور کاملاً تازه. اگر nginx، docker یا node از قبل نصب شده باشند، اسکریپت با کد Error: Some packages like nginx/docker/nodejs are already installed. از ادامه کار خودداری می‌کند.

آخرین مورد بررسی، همان چیزی است که کاربران بر سر آن بحث می‌کنند، بنابراین دلیل آن در اینجا آمده است. Cloudron نسخه‌های مشخصی از Docker، nginx، Node.js و MySQL را نصب می‌کند، پیکربندی nginx را برای هر برنامه‌ای که میزبانی می‌کند می‌نویسد و قوانین فایروال iptables را شخصاً مدیریت می‌کند. Dockerای که دیروز نصب کرده‌اید نسخه اشتباهی خواهد بود، بنابراین اسکریپت بدون تغییر در سیستم خارج می‌شود و به شما می‌گوید با یک نصب تازه Ubuntu شروع کنید. Cloudron مالک کل ماشین است، پس یک VPS اختصاصی به آن اختصاص دهید.

یک بررسی دیگر وجود دارد که نادیده گرفتن آن آسان است. روی یک CPU قدیمی بدون قابلیت AVX (افزونه‌های برداری پیشرفته)، اسکریپت عبارت CPU has no AVX support. MongoDB will be disabled را چاپ می‌کند و هر برنامه‌ای که به MongoDB نیاز داشته باشد غیرقابل نصب می‌شود. پیش از نهایی کردن انتخاب، CPU را با دستور grep -m1 -o avx /proc/cpuinfo بررسی کنید؛ این دستور در یک میزبان توانمند avx را چاپ می‌کند و در یک میزبان قدیمی چیزی نمایش نمی‌دهد.

Cloudron به چه مقدار RAM نیاز دارد؟

اسکریپت نصب در صورت کمتر بودن حافظه از 941 MB با خطای Error: Cloudron requires atleast 1GB physical memory متوقف می‌شود و مستندات رسمی نیز حداقل 2 GB رم و 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 رم و 60 GB دیسک به‌راحتی اجرا می‌شوند. برای حدود ده برنامه، به 16 GB رم و 240 GB دیسک نیاز دارید، زیرا مصرف پایهٔ پلتفرم کاهش نمی‌یابد و هر برنامه یک ایمیج Docker، یک دیتابیس و داده‌های اختصاصی خود را اضافه می‌کند. فضای دیسک سریع‌تر از آنچه تصور می‌کنید پر می‌شود: ایمیج‌ها، داده‌های برنامه و بک‌آپ‌های محلی همگی از یک Volume مشترک استفاده می‌کنند تا زمانی که بک‌آپ‌ها را به خارج از سرور منتقل کنید.

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 به محض نصب آن برنامه‌ها، resolve می‌شوند.
• example.com به عنوان یک رکورد A، تنها اگر می‌خواهید برنامه‌ای روی دامنه اصلی (bare domain) داشته باشید.

اولویت یک رکورد wildcard از یک رکورد صریح (explicit) کمتر است، بنابراین یک www.example.com موجود که به جای دیگری اشاره می‌کند، همچنان به کار خود ادامه می‌دهد.

در طول راه‌اندازی، انتخاب می‌کنید که Cloudron از آن پس چگونه DNS را مدیریت کند:

• ارائه‌دهنده API: Cloudron یک توکن برای Cloudflare، DigitalOcean، Route53، Hetzner، Porkbun، Linode، deSEC، Gandi، Namecheap و حدود ده مورد دیگر (در مجموع 20 ارائه‌دهنده API) ذخیره می‌کند و سپس تمام رکوردها، از جمله رکوردهای ایمیل را خودش می‌نویسد.
• Wildcard: شما رکورد * را به‌صورت دستی اضافه می‌کنید و Cloudron هیچ رکوردی نمی‌نویسد.
• دستی: Cloudron هر رکورد را به شما نشان می‌دهد و پیش از نصب هر برنامه، منتظر می‌ماند تا شما آن را اضافه کنید.

یک رکورد DNS از نوع wildcard به معنای گواهی wildcard نیست. ارائه‌دهنده پیش‌فرض گواهی، Let's Encrypt Prod - Wildcard است که مالکیت را از طریق DNS اثبات می‌کند، بنابراین فقط با یک ارائه‌دهنده API کار می‌کند. در حالت‌های Wildcard یا دستی، شما به استفاده از یک گواهی برای هر برنامه که از طریق 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] را می‌پرسد. پاسخ مثبت (yes) بدهید. اگر نیاز دارید راه‌اندازی مجدد را زمان‌بندی کنید، فلگ --skip-reboot در دسترس است، اما توجه داشته باشید که Cloudron تا زمانی که سرور دوباره بالا نیاید، قابل استفاده نخواهد بود.

راه‌اندازی اولیه: دامنه، بک‌اند DNS و حساب کاربری مدیر

فایل https://<server-ip> را باز کنید و هشدار مرورگر را بپذیرید. گواهی ارائه‌شده خودامضا (self-signed) است، زیرا Cloudron هنوز دامنه شما را نمی‌شناسد و در نتیجه نمی‌تواند از مرجع صدور گواهی (CA) درخواستی داشته باشد. در 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 منتقل می‌کند. از این لحظه به بعد، آدرس IP دیگر کار نخواهد کرد، بنابراین آدرس جدید را در بوک‌مارک‌های خود ذخیره کنید.

گواهی‌ها: چه چیزی تمدید می‌شود و چه زمانی متوقف می‌گردد

تمدید گواهی به‌صورت خودکار و بر اساس ACME Renewal Information (ARI) انجام می‌شود؛ این همان زمان‌بندی است که مرجع صدور گواهی (CA) منتشر می‌کند و در عمل، حدود یک ماه پیش از انقضا صورت می‌گیرد. در صورت شکست در تمدید، ایمیلی به حساب مدیر ارسال می‌شود و گواهی منقضی‌شده به گواهی خودامضا (self-signed) داخلی بازمی‌گردد. این بازگشت به حالت قبل، همان دلیلی است که باعث نمایش هشدار مرورگر در سایتی می‌شود که تا دیروز به‌درستی کار می‌کرد.

دو دلیل عمده مسئول اکثر این مشکلات هستند. اعتبارسنجی HTTP به پورت ورودی 80 نیاز دارد؛ بنابراین بستن پورت 80 با این تصور که «همه چیز به‌هرحال HTTPS است»، تمدید را برای تمام برنامه‌هایی که از Wildcard یا Manual DNS backend استفاده می‌کنند، مختل می‌کند. اعتبارسنجی DNS به یک API token نیاز دارد که همچنان دسترسی نوشتن (write access) داشته باشد؛ بنابراین تغییر یا محدود کردن آن توکن، باعث می‌شود تمدید بدون هیچ هشداری متوقف شود تا زمانی که ایمیل اطلاع‌رسانی برسد.

در نمای Domains، یک دکمه Renew All برای اجرای فوری تلاش تمدید وجود دارد و همچنین یک ارائه‌دهنده Let's Encrypt Staging برای تست در نظر گرفته شده است. گواهی‌های Staging عمداً توسط مرورگرها غیرقابل‌اعتماد شناخته می‌شوند و هدف همین است: شما می‌توانید بدون مصرف سهمیه (rate limit) محیط عملیاتی، هر چند بار که مایلید تلاش مجدد انجام دهید.

آیا باید از میل‌سرور داخلی استفاده کنید؟

Cloudron یک پشته کامل ایمیل شامل صندوق‌های پستی IMAP، قابلیت submission، فیلترهای sieve و امضای DKIM (مخفف DomainKeys Identified Mail) ارائه می‌دهد. شما می‌توانید این قابلیت را برای هر دامنه در بخش Email در داشبورد فعال کنید. بخش دشوار کار، تحویل ایمیل‌ها است و هیچ‌کدام از این دشواری‌ها مربوط به Cloudron نیست.

• پورت خروجی 25 توسط اکثر ارائه‌دهندگان VPS برای کنترل اسپم مسدود شده است. برخی از آن‌ها پس از ارسال تیکت پشتیبانی، این پورت را باز می‌کنند. با استفاده از nc -zv aspmx.l.google.com 25 از روی سرور تست کنید (اگر دستور موجود نیست، netcat-openbsd را نصب کنید). گزارش پورت‌های باز در succeeded نمایش داده می‌شود و پورت مسدود تا زمان اتمام مهلت (timeout) معلق می‌ماند.
• رکورد PTR (یا همان reverse DNS) توسط ارائه‌دهنده VPS شما تنظیم می‌شود، نه توسط میزبان DNS شما، و باید با نام میزبان (hostname) ایمیل مطابقت داشته باشد. ایمیل‌هایی که از آدرسی با PTR عمومی ارسال می‌شوند، در پوشه اسپم قرار می‌گیرند.
• رکوردهای SPF، DKIM و DMARC برای شما در بک‌اندهای DNS مبتنی بر API نوشته می‌شوند. در بک‌اندهای Wildcard یا Manual باید آن‌ها را به‌صورت دستی اضافه کنید؛ نبود رکورد DKIM به این معنی است که هر پیامی که امضا می‌کنید، غیرقابل‌تأیید خواهد بود.

تنظیمی که برای اکثر افراد کارآمد است، دریافت ایمیل روی Cloudron و ارسال آن از طریق یک رله (relay) مانند SendGrid، Postmark، Mailgun یا Amazon SES است که در نمای Email پیکربندی می‌شود. رله باید اجازه ارسال ایمیل با هر آدرسی از دامنه شما را بدهد، در غیر این صورت اعلان‌های برنامه‌ها از فرستنده‌های مختلف رد می‌شوند. اگر ایمیل دلیل اصلی خرید سرور توسط شماست، یک میل‌سرور اختصاصی مانند Mailcow را روی یک ماشین مجزا با اعتبار IP مخصوص به خود اجرا کنید.

اگر اصلاً از قابلیت ایمیل Cloudron استفاده نمی‌کنید، پورت‌های 25، 465، 587، 993 و 4190 را در فایروال ارائه‌دهنده خود مسدود کنید. این کار را در آنجا انجام دهید و نه روی سرور، زیرا Cloudron قوانین iptables را خودش می‌نویسد و انتظار دارد کنترل آن‌ها را در اختیار داشته باشد. این موضوع برعکس یک VPS معمولی است که در آن شما قوانین ufw را شخصاً مدیریت می‌کنید.

پیکربندی مقصد پشتیبان‌گیری پیش از نیاز به آن

پشتیبان‌گیری‌ها به‌صورت پیش‌فرض در فایل‌سیستم محلی در مسیر /var/backups ذخیره می‌شوند که روی همان دیسکی قرار دارد که سایر داده‌ها در آن هستند. مستندات در این باره صریح است: «نگهداری پشتیبان‌ها روی همان دیسک فیزیکی سرور پلتفرم، خطرناک است.» خرابی یک دیسک، هم برنامه‌ها و هم پشتیبان‌ها را با هم از بین می‌برد.

بخش Backups و سپس Backup Sites را باز کنید و از همان روز اول، مقصدی دیگر برای آن تعیین کنید. فضای ذخیره‌سازی شیء (Object Storage) سازگار با S3 معمول‌ترین پاسخ است (مانند Backblaze B2، Wasabi، Cloudflare R2، DigitalOcean Spaces یا یک MinIO bucket روی سروری دیگر)؛ همچنین SSHFS، NFS، CIFS و مقصدهای فایل‌سیستمی ساده نیز پشتیبانی می‌شوند.

سه تنظیم تعیین می‌کنند که آیا آن پشتیبان ارزش نگهداری دارد یا خیر:

• فرمت (Format). گزینه tgz برای هر برنامه یک آرشیو فشرده می‌سازد و در هر اجرا کل آن را دوباره آپلود می‌کند. گزینه rsync فقط فایل‌های تغییریافته را آپلود می‌کند که برای یک Nextcloud بزرگ بسیار به‌صرفه‌تر است، اما در عوض تعداد درخواست‌های بیشتری به API فضای ذخیره‌سازی ارسال می‌کند.
• رمزنگاری (Encryption). یک قابلیت اختیاری AES-256 که هم محتوای فایل‌ها و هم نام آن‌ها را پوشش می‌دهد. Cloudron نسخه‌ای از رمز عبور را نزد خود نگه نمی‌دارد، بنابراین گم کردن آن به این معنی است که پشتیبان‌ها توسط هیچ‌کس، از جمله خود شما، قابل رمزگشایی نخواهند بود. پیش از کلیک روی دکمه ذخیره، آن را در یک مدیریت‌کننده رمز عبور خودمیزبان ذخیره کنید.
• نگهداری (Retention). به‌صورت تعداد بیان می‌شود، مانند 7 روزانه و 4 هفتگی. نگهداری طولانی‌مدت روی فضای ذخیره‌سازی ابری، هر ماه برای شما هزینه دارد، بنابراین عددی را انتخاب کنید که تمایل به پرداخت هزینه آن را دارید.

سپس یک بازیابی (Restore) را تست کنید. یک برنامه کوچک نصب کنید، آن را از طریق داشبورد بازیابی کنید و بازگشت آن به همراه داده‌هایش را مشاهده کنید. پشتیبانی که هیچ‌کس تا به حال بازیابی نکرده است، صرفاً یک حدس و گمان است.

محدودیت‌های طرح رایگان

از اکتبر 2026، طرح رایگان به نصب حداکثر دو برنامه محدود شده است. سایر قابلیت‌ها شامل به‌روزرسانی برنامه‌ها، پشتیبان‌گیری برای هر برنامه، فایروال، سرور ایمیل و احراز هویت یکپارچه (SSO) در این طرح گنجانده شده‌اند. برای نصب برنامه سوم، نیاز به تهیه لایسنس خواهید داشت. طرح‌های پولی محدودیت تعداد برنامه را حذف می‌کنند و در طرح‌های بالاتر، امکاناتی نظیر گروه‌ها و نقش‌های کاربری، دایرکتوری سرور و پشتیبان‌گیری در چندین مقصد مختلف اضافه می‌شود. از آنجا که قیمت‌ها تغییر می‌کنند، به‌جای تکیه بر اعداد ذکر شده در آموزش‌ها، صفحه قیمت‌گذاری Cloudron را بررسی کنید.

هر لایسنس برای یک نصب Cloudron معتبر است؛ بنابراین هزینه دو سرور کوچک، دو برابر هزینه یک سرور بزرگ‌تر خواهد بود. این مدل قیمت‌گذاری اکثر کاربران را به سمت استفاده از یک VPS بزرگ‌تر سوق می‌دهد که با توصیه معمول مبنی بر توزیع سرویس‌ها روی ماشین‌های مختلف در تضاد است. هنگام انتخاب ابعاد سرور این نکته را در نظر بگیرید، زیرا تفکیک سرویس‌ها در آینده به معنای پرداخت هزینه مضاعف خواهد بود.

هنگام بروز مشکل

با بررسی داخلی شروع کنید. این ابزار DNS، گواهی‌ها، دیسک، حافظه و تک‌تک سرویس‌ها را به‌ترتیب بررسی می‌کند و به شما می‌گوید کدام تست با شکست مواجه شده است:

sudo cloudron-support --troubleshoot

پس از آن، از ابزارهای استاندارد systemd (مدیریت سیستم و سرویس) استفاده کنید. systemctl status box وضعیت خود سرویس Cloudron را گزارش می‌دهد، journalctl -u box -n 100 لاگ‌های اخیر آن را نمایش می‌دهد و journalctl -u docker محیط اجرای container زیرین را پوشش می‌دهد. هر موردی که در حین نصب با خطا مواجه شده باشد در /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 زمانی مناسب است که شما به دنبال برنامه‌ها هستید، نه زیرساخت. اگر قصد دارید کانتینرهای خود را به روش شخصی اجرا کنید، Cloudron انتخاب بدی است؛ زیرا این پلتفرم کنترل nginx، Docker و فایروال را در دست می‌گیرد و تغییرات دستی شما را بازنویسی می‌کند. اگر برنامه شما شامل مجموعه‌ای از فایل‌های compose است، استفاده از Traefik در مقابل Docker Compose stacks شخصی همان قابلیت TLS خودکار و مسیریابی زیردامنه را بدون نیاز به یک پلتفرم واسط در اختیار شما قرار می‌دهد. اگر هنوز تصمیم نگرفته‌اید، مقایسه Cloudron، CasaOS و Coolify این گزینه‌ها را در کنار هم بررسی می‌کند و لیست جامع سرویس‌های قابل میزبانی شخصی نقطه شروع بهتری نسبت به یک راهنمای نصب است.

FAQ

Cloudron روی یک VPS به چه مقدار RAM نیاز دارد؟

اسکریپت نصب در صورت کمتر بودن حافظه از 941 MB اجرا نمی‌شود و مستندات 2 GB را پیشنهاد می‌دهند، اما این حداقل مقدار برای پلتفرمی است که هیچ برنامه‌ای روی آن نصب نشده باشد. Cloudron از همان لحظه بوت، Docker، nginx، سرویس اختصاصی box، کانتینرهای دیتابیس و پشته ایمیل را اجرا می‌کند. برای دو برنامه 4 GB و برای حدود ده برنامه 16 GB رم در نظر بگیرید. حتماً یک swap file اضافه کنید؛ زیرا Cloudron به برنامه‌ها دسترسی نامحدود به swap می‌دهد و سروری که فاقد آن باشد، در صورت فشار حافظه، برنامه‌ها را ری‌استارت می‌کند.

آیا می‌توانم Cloudron را روی Debian یا سروری که از قبل Docker دارد نصب کنم؟

هیچ‌کدام از این موارد کار نمی‌کند. اسکریپت نصب، نسخه سیستم‌عامل را بررسی کرده و در صورت عدم تطابق با Cloudron requires Ubuntu 22.04, 24.04, 26.04 متوقف می‌شود؛ بنابراین Debian، Rocky و Alpine پشتیبانی نمی‌شوند. همچنین اگر nginx، docker یا node از قبل نصب شده باشند، نصب متوقف می‌شود؛ زیرا Cloudron نسخه‌های خاصی از این ابزارها را نصب کرده و پیکربندی nginx و قوانین iptables را مستقیماً مدیریت می‌کند. کار را با یک ایمیج تازه Ubuntu روی یک KVM VPS شروع کنید.

چرا زیردامنه‌های برنامه‌های من کار نمی‌کنند در حالی که داشبورد در دسترس است؟

رکورد DNS wildcard وجود ندارد. فرآیند نصب به یک رکورد A برای my.example.com نیاز دارد یا آن را ایجاد می‌کند، بنابراین داشبورد resolve می‌شود، اما wiki.example.com خطای NXDOMAIN برمی‌گرداند و مرورگر گزارش می‌دهد که سایت پیدا نشد. یک رکورد A برای *.example.com اضافه کنید که به IP سرور اشاره کند و پیش از نصب برنامه، آن را با dig +short wiki.example.com تأیید کنید.

آیا مجبور به استفاده از سرور ایمیل Cloudron هستم؟

خیر. می‌توانید دریافت ایمیل را غیرفعال کنید و ارسال را از طریق یک relay خارجی مانند Postmark، Mailgun یا Amazon SES انجام دهید. این انتخاب امن‌تری است، به‌ویژه زمانی که ارائه‌دهنده شما پورت 25 خروجی را مسدود کرده یا IP شما اعتبار ایمیلی ندارد. اگر به‌طور کامل از قابلیت ایمیل Cloudron صرف‌نظر می‌کنید، پورت‌های 25، 465، 587، 993 و 4190 را در فایروال ارائه‌دهنده (و نه در خود سرور) ببندید.

وقتی در طرح رایگان به محدودیت دو برنامه می‌رسم چه اتفاقی می‌افتد؟

داشبورد از نصب سوم جلوگیری کرده و درخواست لایسنس می‌کند. برنامه‌هایی که از قبل اجرا کرده‌اید دست‌نخورده باقی می‌مانند: آن‌ها همچنان به‌روزرسانی می‌شوند، از آن‌ها بک‌آپ گرفته می‌شود و گواهی‌هایشان معتبر می‌ماند. افزودن لایسنس بدون نیاز به نصب مجدد، محدودیت را برمی‌دارد؛ بنابراین طرح رایگان روشی مناسب برای تست پلتفرم روی یک دامنه واقعی است.