Cloudron, CasaOS чи Coolify для VPS: що обрати

Що ви створюєте

Ви обираєте не лише інструмент для встановлення. Три панелі обіцяють перетворити чистий VPS на хост для застосунків із керуванням через графічний інтерфейс: Cloudron, CasaOS і Coolify. У цьому посібнику кожну з них буде встановлено на тому самому чистому сервері Ubuntu 24.04, після чого ми встановимо перший застосунок і ретельно перевіримо те, чого зазвичай не показують на скриншотах: TLS, резервні копії, оновлення, споживання пам’яті та складність міграції. Наприкінці ви знатимете, який варіант вам підходить, або чесно визнаєте, що відповідь — «жоден із них, просто використовуйте Docker Compose».

Жодна з цих панелей не є магічним рішенням. Усі три працюють поверх того самого Docker Engine, яким можна керувати вручну. За гроші, оперативну пам’ять або залежність від платформи панель бере на себе чотири завдання: встановлення застосунків одним натисканням, автоматичне отримання TLS-сертифікатів, планування резервного копіювання та керування користувачами. Якщо ці чотири функції виправдовують додаткове навантаження, панель може бути корисною. Якщо ви запускаєте один або два сервіси й хочете точно знати, що працює на вашому сервері, спочатку прочитайте розділ «Пропустити всі три» і заощадьте собі час.

Спільні вимоги та важливі нюанси

Усі три варіанти передбачають KVM VPS, а не контейнерну віртуалізацію. Docker потребує повноцінного kernel, а Cloudron безпосередньо відхиляє OpenVZ і LXC. Перевірте це за допомогою systemd-detect-virt: kvm або qemu — це нормально, а openvz або lxc — ні. У плані KVM команда виводить kvm, а на bare metal — none; в обох випадках можна продовжувати.

В інших вимогах є відмінності. Саме вони насамперед визначають вибір.

• RAM. CasaOS нормально працює з 1GB; його розробляли для hardware Raspberry Pi, тому він залишається легким. Coolify потребує щонайменше 2GB і двох CPU cores, причому близько 600 MB займає сам Coolify. Cloudron потребує мінімум 2GB і помітно краще працює з 4GB, оскільки запускає mail server і database ще до встановлення першого застосунку.
• Домен і DNS під вашим контролем. Cloudron і Coolify потребують справжнього домену з робочим DNS. Для Cloudron бажано надати API-доступ до вашого DNS-провайдера, щоб він міг самостійно створювати записи та wildcard-сертифікати. CasaOS працює за прямою IP-адресою, але в такому разі TLS не буде.
• Порти. Усі три рішення потребують відкритих портів 80 і 443 для HTTP та HTTPS. Coolify додатково обслуговує dashboard на 8000, використовує 6001 для realtime channel і 6002 для terminal у браузері. На кожному з них залиште відкритим порт 22 для SSH.

До початку роботи налаштуйте DNS на цей сервер. Панель, яка не може визначити власне hostname, не зможе запитати сертифікат, і першу годину ви витратите на налагодження цього, а не самого програмного забезпечення. Створіть A-запис із IP-адресою сервера, а для Coolify додайте wildcard-запис (*.apps.example.com), щоб кожен розгорнутий застосунок отримував власний subdomain.

Cloudron: відшліфований appliance із чіткими правилами

Що це таке. Cloudron — комерційна платформа, яка перетворює весь сервер на керований appliance. Вона запускає власні 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, налаштує базу даних, підключить single sign-on і запланує резервне копіювання. Для цього не потрібно змінювати жоден конфігураційний файл. У цьому полягає основна перевага платформи, і вона справді це забезпечує.

TLS і резервні копії. Серед трьох платформ Cloudron має найсильнішу реалізацію цих функцій. Для кожного субдомену застосунку автоматично створюється сертифікат 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 і навіть firewall, який ви налаштували вручну. Якщо було завантажено неправильний образ, процес налаштування також відмовиться працювати з будь-якою системою, крім підтримуваних Ubuntu LTS (22.04 або 24.04) на x86-64. ARM, LXC і OpenVZ взагалі не підтримуються.

Друга типова помилка, wildcard-сертифікати потребують DNS API. Якщо під час налаштування вибрати параметр "Manual" для DNS замість передавання Cloudron API-токена, платформа не зможе створювати DNS-записи або wildcard-сертифікат автоматично. Для кожного нового застосунку доведеться вручну додавати DNS-запис до випуску сертифіката, а панель керування чекатиме на цей запис. Надайте Cloudron доступ через API до підтримуваного DNS-провайдера (Cloudflare, Route 53, DigitalOcean та інших), і весь процес виконуватиметься одним натисканням.

CasaOS: безкоштовна панель для домашньої лабораторії

Що це таке. CasaOS від IceWhale — це безкоштовна панель із відкритим кодом, яка працює поверх Docker і надає домашній екран, магазин застосунків і файловий менеджер. Вона розвинулася з екосистеми домашніх серверів, тому орієнтована на home-lab: швидке налаштування, зручний інтерфейс і мінімум зайвих процедур. CasaOS призначена для ентузіастів, яким потрібен зручніший інтерфейс для 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). Створіть локальний обліковий запис — і можна працювати.

Додавання першого застосунку. Відкрийте App Store, виберіть застосунок і натисніть Install. CasaOS у фоновому режимі створює проєкт Docker Compose та відкриває застосунок на порту хоста, наприклад http://<your-ip>:8080. У магазині є стандартний набір застосунків для домашнього сервера, тому медіасервер Jellyfin на VPS або self-hosted фототека Immich встановлюється за кілька натискань. Якщо ви ще не обрали фотосервер, спочатку варто прочитати про мінімальні вимоги до RAM і мобільні застосунки, які відрізняють PhotoPrism від Immich, оскільки на сервері CasaOS із 1GB RAM цей вибір визначає, чи запрацює застосунок взагалі. Також можна імпортувати будь-який docker-compose.yaml, який вам потрібен. У цьому і полягає головна перевага: застосунки є звичайними контейнерами, а не власним пропрієтарним форматом.

TLS і резервні копії — слабке місце. Саме тут видно обмеження безкоштовного рішення. За замовчуванням CasaOS обслуговує все через звичайний HTTP, зокрема власну панель. Вбудованої підтримки Let’s Encrypt і вбудованих запланованих резервних копій немає. Дані зберігаються у Docker volumes у /DATA, а резервне копіювання потрібно організувати самостійно (через cron для restic або tar).

Сценарій відмови: немає TLS, але система не повідомляє про проблему. Помилок не буде. Ви встановлюєте застосунок, відкриваєте http://<your-ip>:8080, і він працює через незашифроване з’єднання, яке браузер позначає як "Not Secure." Паролі та session cookies передаються мережею у відкритому вигляді. Гірше того, у 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 конфліктуватимуть через цей порт, доки ви спочатку не перенесете CasaOS на інший порт.

Вартість. Повністю безкоштовно назавжди, без обмеження кількості застосунків. Платою є операційне обслуговування: TLS, резервні копії та hardening потрібно налаштовувати самостійно.

Coolify: self-hosted PaaS

Що це таке. Coolify — це open-source self-hosted платформа як сервіс на вашому сервері, подібна до 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. Негайно створіть обліковий запис адміністратора, оскільки сторінка реєстрації залишається відкритою до створення першого облікового запису. Той, хто першим отримає до неї доступ, контролюватиме сервер. Потім укажіть домен свого інстансу та спрямовуйте на сервер wildcard DNS-запис (*.example.com або *.apps.example.com), щоб Coolify міг призначати кожному розгорнутому застосунку власний піддомен.

Додавання першого застосунку. Підключіть Git-джерело (GitHub, GitLab або звичайний URL репозиторію), виберіть гілку, укажіть домен і виконайте розгортання. Вбудований проксі Traefik у Coolify маршрутизує запити піддомену та запитує сертифікат. Для готового програмного забезпечення каталог Services дає змогу розгортати компоненти за кілька натискань: стек автоматизації робочих процесів n8n, який інакше довелося б налаштовувати вручну є одним із записів каталогу, як і Uptime Kuma для моніторингу сторінки стану.

TLS і резервні копії. Для кожного застосунку автоматично створюється сертифікат Let's Encrypt через вбудований Traefik, тому кожен розгорнутий піддомен отримує сертифікат. Резервне копіювання орієнтоване насамперед на бази даних: можна запланувати створення дампів Postgres і MySQL у S3-сумісне сховище. Повне резервне копіювання інстансу, включно з конфігурацією Coolify, яка зберігається в /data/coolify, потребує більше ручної роботи. Тому експортуйте її та зберігайте самостійно.

Вартість і ліцензування. Self-hosted редакція є повністю open-source і безкоштовною, без обмеження кількості застосунків. Додатково доступний Coolify Cloud (платний): він розміщує control plane замість вас, а застосунки й надалі працюють на ваших серверах. Це зручно, але не обов’язково.

Типова несправність: застосунок розгортається, але його домен не відкривається. Панель керування нормально працює на http://<ip>:8000, збірка завершується успішно, але власна URL-адреса застосунку повертає помилку підключення або 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

По-друге, wildcard DNS-запис відсутній, тому Traefik не отримує запити для цього імені хоста. Якщо натомість у Coolify для всього сервера відображається «Server is not reachable», це інша проблема: Coolify взагалі не може підключитися до Docker socket сервера. Зазвичай причиною є зупинений Docker daemon або пошкоджений SSH key. Перш ніж робити припущення, перегляньте справжню причину в журналах:

docker logs coolify-proxy --tail 100

Усуньте проблему на сторінці Proxy: натисніть Restart Proxy або скиньте конфігурацію проксі до стандартної та запустіть його знову. Потім зачекайте близько двох хвилин, поки він стабілізується. Обмежте доступ до порту 8000 лише зі своєї IP-адреси або тимчасово відкривайте його повторно, якщо проксі працює неправильно. Не залишайте цей порт відкритим для всього світу: він обслуговує панель керування через звичайний 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 і томи з /DATA на будь-який інший хост і продовжити роботу. Coolify перебуває посередині: для розгорнутих застосунків використовуються ваші Dockerfile і репозиторії, але їхня конфігурація зберігається в базі даних Coolify, тому під час перенесення на інший хост проєкти потрібно повторно створити на новій стороні. Cloudron створює найбільшу залежність від платформи: застосунки запаковані у формат Cloudron, і хоча ваші дані можна без проблем перенести за допомогою його якісних резервних копій, пакування не переноситься, тому на цільовій платформі застосунок потрібно розгорнути повторно. Дані переносні, а інфраструктура — ні.

Що вибрати

Коротко, а далі — запасний варіант. Обирайте Cloudron, якщо хочете найменше ручного адміністрування сервера з-поміж трьох варіантів, плануєте запускати кілька готових застосунків і готові щороку платити за керування TLS, резервні копії та оновлення. Обирайте CasaOS, якщо це домашня лабораторія у вашій мережі або за reverse proxy, вам потрібен зручний інтерфейс для Docker і ви не хочете нічого платити. Обирайте Coolify, якщо розгортаєте власний код із Git і хочете автоматичне розгортання після push з автоматичним TLS, але без вартості hosted PaaS. Якщо жоден із цих трьох варіантів вам не підходить, наступний розділ містить чесну відповідь.

Пропустіть усі три, якщо...

Об’єктивно оцініть свій масштаб. Якщо ви запускаєте лише один або два застосунки або хочете точно розуміти й контролювати, що працює на вашому сервері, пропустіть панелі. Для невеликого стабільного стеку додаткові витрати ресурсів і прив’язаність до конкретної платформи не виправдані. Варіант DIY — це reverse proxy перед власними файлами Compose: Traefik з автоматичним TLS перед кількома застосунками Docker Compose забезпечує HTTPS, еквівалентний налаштуванню в один клік, але без надмірного навантаження панелі, а резервне копіювання виконується через завдання cron із restic, логіку якого ви розумієте.

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 і один сертифікат. Розгортати цілу appliance-платформу лише для його запуску означало б отримати самі витрати без жодної користі. Якщо ви ще вирішуєте, що запускати, перш ніж визначити, як це робити, краще почати з посібника про те, які застосунки варто розміщувати самостійно у 2026 році.

FAQ

Чи потрібна мені взагалі панель для self-hosting?

Лише якщо ви цінуєте чотири функції, які панель автоматизує для кількох застосунків: встановлення в один клік, автоматичне налаштування TLS, резервне копіювання за розкладом і керування користувачами. Для одного-двох сервісів звичайний Docker Compose за Traefik виконує те саме завдання з TLS, але має значно менші накладні витрати й не створює прив’язки до постачальника. Панелі виправдані, коли ви запускаєте багато застосунків і ваш час коштує дорожче, ніж RAM, яку вони споживають.

Яка панель найкраще підходить новачкам?

Для домашньої лабораторії, де нічого не доступне з небезпечного інтернету, CasaOS є найпростішим варіантом для початку: одна команда та зручний UI без оплати. Але перед публікацією будь-якого сервісу потрібно розмістити попереду reverse proxy з TLS termination, оскільки CasaOS використовує звичайний 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 не переноситься — переносяться лише дані. У кожному випадку перевірте відновлення на тимчасовому сервері, перш ніж виводити старий сервер з експлуатації.