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

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

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

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

Спільні вимоги та важливі обмеження

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

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

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

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

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 its 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 або 26.04) на x86-64; ARM, LXC і OpenVZ не підтримуються взагалі. Починаючи з Cloudron 10 (September 2026), Ubuntu 26.04 є типовою версією для нових інсталяцій. Тому саме її слід вибрати, якщо ви починаєте з чистого сервера сьогодні.

Другий сценарій помилки: wildcard-сертифікатам потрібен DNS API. Якщо під час налаштування вибрати варіант DNS "Manual" замість передавання 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, але відповідний wildcard DNS-запис відсутній. Або застосунок використовує власний домен без окремого 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, оскільки панель використовує звичайний HTTP. Якщо вам потрібні керовані TLS і резервні копії та ви готові за це платити, Cloudron забезпечує найбільше супроводу в межах безкоштовного ліміту на два застосунки.

Чи безкоштовний Cloudron?

Частково. Безкоштовний рівень дає змогу використовувати два застосунки, чого достатньо для тестування або дуже невеликого розгортання. Понад цей ліміт Cloudron працює за платною підпискою з помісячною або річною оплатою; платні рівні підтримують необмежену кількість застосунків. Це комерційний продукт з обмеженим безкоштовним планом, а не вільне програмне забезпечення, тому врахуйте його вартість, якщо ваш стек зростатиме.

Чи можна запускати ці панелі поруч із наявними застосунками?

Cloudron — ні. Він потребує чистої системи Ubuntu і перериває встановлення, якщо nginx, Docker або Node вже встановлені, оскільки керує всією машиною. CasaOS і Coolify сумісніші з таким сценарієм, оскільки встановлюють власний стек Docker і теоретично можуть спільно використовувати систему. Проте CasaOS потрібен порт 80 для dashboard, а proxy Coolify використовує порти 80 і 443, тому кожна з цих панелей конфліктує з наявним web server або proxy, який уже займає ці порти. На системі, де вже розміщені сервіси, панель зазвичай є неправильним інструментом; натомість використовуйте Traefik і Compose.

Як пізніше відмовитися від панелі?

Сплануйте міграцію до того, як вона стане потрібною. Для CasaOS скопіюйте docker-compose.yaml застосунку та його томи /DATA на новий host і запустіть їх знову. Для Coolify експортуйте конфігурацію кожного проєкту та вкажіть ті самі репозиторії на цільовій системі. Для Cloudron відновіть дані з його резервних копій у щойно встановлених застосунках на новій платформі, оскільки пакування Cloudron не переноситься — переносяться лише дані. У кожному випадку перевірте відновлення на тимчасовій системі, перш ніж виводити стару з експлуатації.