Як встановити Cloudron на VPS з Ubuntu

Встановлення Cloudron на VPS: коротка версія

Щоб встановити Cloudron на VPS, потрібен чистий сервер Ubuntu, щонайменше 2 GB RAM і домен, DNS-записи якого ви можете редагувати. Саме встановлення складається з трьох команд і одного перезавантаження. Майже всі проблеми виникають або до цього етапу (неправильний базовий образ, неправильний тип віртуалізації), або після нього (DNS, пошта, резервні копії).

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

Cloudron встановлює, оновлює та резервно копіює self-hosted застосунки, а також випускає для них сертифікати TLS (transport layer security). Кожен застосунок працює в Docker, перед усіма застосунками працює nginx, а кожен застосунок отримує власний піддомен вашого домену. Саме тому в цьому випадку спочатку потрібно налаштувати DNS.

Чому Cloudron вибагливий до базової ОС

Скрипт інсталяції перевіряє сервер, перш ніж щось встановлювати. Якщо перевірка не пройдена, потрібно замовляти новий сервер. Прочитайте ці вимоги, перш ніж вибирати образ.

• Лише Ubuntu і лише три випуски. У разі будь-якої іншої ОС скрипт завершує роботу з Cloudron requires Ubuntu 20.04, 22.04, 24.04. Debian, Rocky і Alpine не підтримуються. Для Ubuntu 24.04 потрібен Cloudron 8 або новіший, і скрипт перевіряє це самостійно.
• Лише 64-бітні процесори Intel або AMD: 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 (advanced vector extensions) скрипт виводить 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 (out of memory). Тому сервер, на якому постійно перезапускається один застосунок, зазвичай має проблему з лімітом, а не з помилкою в застосунку.

Ось конфігурації, які я б замовив. Це рекомендації для сервера, який вам не доведеться перебудовувати наступного місяця. Вони не є результатами вимірювань продуктивності.

[
  {
    "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 RAM і 240 GB дискового простору, оскільки базове споживання платформи не зменшується, а кожен застосунок додає Docker image, базу даних і власні дані. Диск заповнюється швидше, ніж очікують: images, дані застосунків і локальні резервні копії використовують один том, доки ви не перенесете резервні копії за межі сервера.

Cloudron надає кожному застосунку необмежений swap, тому встановлений вами ліміт пам’яті застосовується лише до RAM. На образі VPS без swap-файлу swapon --show взагалі нічого не виводить, а дефіцит пам’яті одразу призводить до перезапусків OOM, а не до повільної роботи застосунку. Додати 2 GB swap — недорогий спосіб зменшити ризик, але swap не замінює фізичну пам’ять. Різниця між тарифами VPS невелика порівняно з кількістю годин, які ви витратите на налаштування лімітів, тому перегляньте скільки насправді коштує VPS і виберіть наступний за розміром тариф.

DNS: wildcard-запис, завдяки якому працюють піддомени застосунків

Cloudron розміщує dashboard на my.example.com, а кожен застосунок — на власному піддомені, тому DNS є обов’язковою попередньою умовою, а не кроком, який можна виконати пізніше. До першого відкриття dashboard вкажіть у цих записах публічну IP-адресу сервера:

• my.example.com як A-запис. Це dashboard.
• *.example.com як A-запис. Саме цей запис забезпечує роботу піддоменів застосунків, тому wiki.example.com і git.example.com почнуть резолвитися одразу після встановлення відповідних застосунків.
• example.com як A-запис, лише якщо потрібно розмістити застосунок безпосередньо на кореневому домені.

Wildcard-запис має нижчий пріоритет, ніж явний запис, тому наявний www.example.com, який вказує в інше місце, продовжить працювати.

Під час налаштування виберіть, як Cloudron надалі працюватиме з DNS:

• API-провайдер. Cloudron зберігає токен для 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-запису нічого не повертає, згодом застосунки не працюватимуть, хоча dashboard відкриватиметься.

Якщо домен працює через 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> і прийміть попередження браузера. Сертифікат є самопідписаним, оскільки Cloudron ще не знає ваш домен і тому не може запросити сертифікат у центру сертифікації. У Chrome натисніть Advanced, потім Proceed to <ip> (unsafe). У Firefox натисніть Advanced, потім Accept the Risk and Continue.

На першому екрані потрібно вказати домен. Введіть example.com, після чого dashboard буде доступний за адресою my.example.com. Замість цього можна використати субдомен, наприклад cloudron.example.com, і тоді dashboard буде доступний за адресою my.cloudron.example.com. Виберіть DNS-бекенд, вставте API token, якщо він у вас є, і створіть обліковий запис адміністратора з email-адресою, яку ви регулярно перевіряєте: її буде використано для реєстрації в Let's Encrypt і всіх сповіщень платформи.

Після збереження Cloudron запитає сертифікати та перенесе dashboard на https://my.example.com. Після цього URL з IP-адресою перестане працювати, тому збережіть нову адресу в закладках.

Сертифікати: що поновлюється і коли це припиняється

Поновлення сертифіката відбувається автоматично за ACME Renewal Information (ARI) — розкладом, який публікує центр сертифікації. На практиці сертифікат поновлюється приблизно за місяць до завершення строку дії. Якщо поновлення не вдалося, повідомлення надходить на обліковий запис адміністратора, а після завершення строку дії сертифіката система переходить на вбудований self-signed сертифікат. Саме це означає попередження браузера на сайті, який ще вчора працював без нього.

У більшості випадків причина одна з двох. Для HTTP-валідації потрібен вхідний порт 80. Тому його закриття через міркування «усе й так працює через HTTPS» порушує поновлення для кожного застосунку, який використовує Wildcard або Manual DNS backend. Для DNS-валідації потрібен API token із правом запису. Якщо цей token замінити або обмежити його права, поновлення непомітно припиниться, доки не надійде попереджувальний email.

У поданні Domains є кнопка Renew All, яка негайно запускає спробу поновлення, а також провайдер Let's Encrypt Staging для тестування. Staging-сертифікати навмисно не є довіреними для браузерів. У цьому і полягає їхнє призначення: можна повторювати спроби скільки завгодно разів, не витрачаючи production rate limit.

Чи варто використовувати вбудований поштовий сервер?

Cloudron постачається з повним поштовим стеком: поштовими скриньками IMAP, submission, фільтрами sieve і підписуванням DKIM (domainkeys identified mail). Увімкнути його можна для кожного домену в розділі Email на інформаційній панелі. Найскладніше — забезпечити доставляння пошти, і Cloudron не відповідає за жодну з цих складностей.

• Більшість VPS-провайдерів блокують вихідний порт 25 для боротьби зі спамом. Деякі знімають блокування після звернення до служби підтримки. Перевірте порт із сервера за допомогою nc -zv aspmx.l.google.com 25 (якщо команда відсутня, встановіть netcat-openbsd). Відкриті порти відображає succeeded, а підключення до заблокованого порту зависає до завершення тайм-ауту.
• Запис PTR (зворотний DNS) налаштовує VPS-провайдер, а не хостинг DNS. Він має відповідати імені поштового хоста. Пошта з адреси із загальним PTR потрапляє до папок зі спамом.
• Записи SPF, DKIM і DMARC створюються автоматично в DNS-бекенді з API. У бекендах Wildcard або Manual їх потрібно додати вручну. Якщо запис DKIM відсутній, кожне підписане вами повідомлення неможливо перевірити.

Для більшості користувачів найкраще приймати пошту на Cloudron, а надсилати її через relay, наприклад SendGrid, Postmark, Mailgun або Amazon SES, налаштований у поданні Email. Relay має дозволяти надсилання від імені будь-якої адреси вашого домену. Інакше сповіщення застосунків від різних відправників відхилятимуться. Якщо пошта є основною причиною придбання сервера, запустіть виділений поштовий сервер, наприклад Mailcow на окремому сервері з власною репутацією IP-адреси.

Якщо ви взагалі не використовуєте Cloudron Email, заблокуйте порти 25, 465, 587, 993 і 4190 у firewall вашого провайдера. Робіть це на його боці, а не на сервері, оскільки Cloudron сам записує правила iptables і очікує, що керуватиме ними. Це протилежно звичайному VPS, де ви самостійно керуєте правилами ufw.

Налаштуйте сховище резервних копій до того, як воно знадобиться

За замовчуванням резервні копії зберігаються в локальній файловій системі в /var/backups, на тому самому диску, що й усі інші дані. У документації прямо зазначено: «Зберігати резервні копії на тому самому фізичному диску, що й сервер платформи, небезпечно». Відмова одного диска одночасно виведе з ладу застосунки та резервні копії.

Відкрийте Backups, потім Backup Sites і в перший день налаштуйте інше сховище. Зазвичай використовують S3-compatible object storage (Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces або бакет MinIO на другому сервері). Також підтримуються SSHFS, NFS, CIFS і звичайні файлові системи.

Є три налаштування, від яких залежить практична цінність резервної копії:

• Format. tgz створює один стиснений архів для кожного застосунку та під час кожного запуску повторно завантажує весь архів. rsync завантажує лише змінені файли. Для великого Nextcloud це значно дешевше, але створює набагато більше запитів до API сховища.
• Encryption. Необов’язкове AES-256-шифрування охоплює вміст файлів і їхні імена. Cloudron не зберігає копію пароля. Якщо його втратити, резервні копії не зможе розшифрувати ніхто, зокрема й ви. Перш ніж натискати кнопку збереження, збережіть пароль у self-hosted менеджері паролів.
• Retention. Значення задають кількістю копій, наприклад 7 daily і 4 weekly. Тривале зберігання в object storage щомісяця збільшує рахунок, тому виберіть кількість копій, за зберігання яких ви готові постійно платити.

Після цього перевірте відновлення. Встановіть невеликий застосунок, відновіть його з dashboard і переконайтеся, що він запускається разом із даними. Резервна копія, з якої ще жодного разу не виконували відновлення, є лише припущенням.

Що обмежує безкоштовний план

Станом на August 2026 безкоштовний план обмежений двома встановленими застосунками. Усе інше входить до плану: оновлення застосунків, резервні копії для кожного застосунку, firewall, mail server і single sign-on. Саме третій застосунок вимагає ліцензії. Платні плани скасовують обмеження на кількість застосунків, а дорожчий план додатково надає групи користувачів і ролі, directory server та кілька сайтів для резервного копіювання. Ціни змінюються, тому перевіряйте сторінку з цінами Cloudron, а не покладайтеся на число в tutorial.

Ліцензія поширюється на одну інсталяцію 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.

Якщо dashboard не завантажується, причиною зазвичай є DNS або firewall провайдера, а не Cloudron. Виконайте dig +short my.example.com на своєму ноутбуці та переконайтеся, що порти 80 і 443 відкриті в мережевому firewall провайдера. Це окремий засіб керування, не пов’язаний із власними правилами сервера. Якщо ви починаєте спочатку, скрипт відмовиться від повторного запуску з Error: Cloudron is already installed. To reinstall, start afresh, тому чисте перевстановлення сервера є правильним рішенням.

Коли Cloudron не відповідає вашим потребам

Cloudron підходить, якщо вам потрібні застосунки, а не інфраструктура. Він погано підходить, якщо ви хочете запускати власні контейнери на власних умовах, оскільки Cloudron керує nginx, Docker і firewall та перезаписує внесені вами зміни. Якщо ваш план — каталог із 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 уже встановлено, оскільки Cloudron встановлює зафіксовані версії всіх цих компонентів і сам записує конфігурацію nginx та правила iptables. Почніть із чистого образу Ubuntu на KVM VPS.

Чому піддомени моїх застосунків не працюють, а dashboard відкривається?

Відсутній wildcard DNS-запис. Під час встановлення створюється або має бути створений A-запис для my.example.com, тому dashboard визначається, тоді як wiki.example.com повертає NXDOMAIN, і браузер повідомляє, що сайт не знайдено. Додайте A-запис для *.example.com, який вказує на IP-адресу сервера, а потім перевірте його за допомогою dig +short wiki.example.com, перш ніж встановлювати застосунок.

Чи потрібно використовувати поштовий сервер Cloudron?

Ні. Можна вимкнути вхідну пошту та надсилати пошту через зовнішній relay, наприклад Postmark, Mailgun або Amazon SES. Це безпечніший варіант, якщо провайдер блокує вихідний порт 25 або IP-адреса не має поштової репутації. Якщо повністю відмовитися від Cloudron Email, закрийте порти 25, 465, 587, 993 і 4190 у firewall провайдера, а не на самому сервері.

Що станеться, коли я досягну ліміту у два застосунки на безкоштовному плані?

Dashboard заблокує встановлення третього застосунку та попросить ввести ліцензійний ключ. Уже запущені застосунки не буде змінено: вони продовжать оновлюватися, резервуватися та використовувати свої сертифікати. Додавання ліцензії знімає обмеження без повторного встановлення, тому безкоштовний план зручно використовувати для тестування платформи на реальному домені.