YunoHost или Cloudron: что выгоднее и когда

MAATRIX

Если вы хотите держать десяток сервисов на своём VPS — почту, календарь, облако, чат — и не тратить вечер на каждый Docker Compose, вопрос упирается в одно из двух имён: YunoHost или Cloudron. Оба обещают «поставить приложение в три клика», но за этим обещанием стоят разная философия, разные деньги и разный потолок возможностей. Разберём, чем они отличаются на практике и когда какой выбрать, чтобы не пожалеть об этом через полгода.

Что это вообще такое и в чём разница философий

YunoHost — некоммерческий проект с открытым кодом, который вырос из французского комьюнити self-hosting-энтузиастов. Это по сути Debian с готовым слоем автоматизации: единая система пользователей и доменов, каталог приложений, собираемых сообществом, и веб-админка поверх командной строки. Никакой подписки, никаких лимитов — сколько приложений влезет на сервер по ресурсам, столько и ставьте.

Cloudron — коммерческий продукт (с бесплатным тарифом). Внутри — Docker: каждое приложение живёт в своём контейнере с собственным томом и сетевым правилом, а панель Cloudron управляет их жизненным циклом: установка, обновление, бэкап, миграция между приложениями с сохранением базы. За это разработчики берут деньги, но взамен дают более предсказуемое поведение и техподдержку.

Разница философий отражается на всём остальном: YunoHost тяготеет к «максимум свободы, минимум ограничений», Cloudron — к «меньше сюрпризов, но плати». Если вы уже работали с панелями управления вроде Coolify, логика Cloudron покажется знакомой — это тоже PaaS-подход поверх Docker, только с закрытым магазином приложений вместо открытых compose-файлов.

Установка на чистый сервер

YunoHost ставится одной командой на чистый Debian или Ubuntu:

curl https://install.yunohost.org | bash

Скрипт сносит существующие веб-серверы и почтовые демоны на сервере (Apache, Postfix и т.п.) — YunoHost рассчитывает на монопольное владение машиной. После установки постройка идёт через веб-мастер на https://ваш-ip/ или через SSH-скрипт yunohost tools postinstall. Домен, часовой пояс, пароль администратора — минут за десять всё готово. Подробный пошаговый разбор с типичными граблями есть в гайде по установке YunoHost на VPS и отдельно под Ubuntu 24.04.

Cloudron ставится похожим образом, но требует Docker и минимум 2 ГБ RAM ещё до установки:

curl -L https://cloudron.io/cloudron-setup | bash

Setup поднимает сам движок Cloudron в контейнерах, а полноценная настройка (домен, wildcard DNS, DKIM-записи для почты) происходит уже через веб-визард. Здесь важный нюанс: Cloudron с самого начала завязан на wildcard-поддомен (*.example.com), потому что каждое приложение получает свой поддомен вида app.example.com. Если у вас нет возможности управлять DNS-зоной домена (например, домен на регистраторе без API), настройка усложняется — придётся вручную добавлять записи под каждое приложение.

Каталог приложений: что реально можно поставить

YunoHost выигрывает числом: в каталоге есть нишевые вещи вроде Baïkal, Radicale, множество форумных и wiki-движков, которого в Cloudron просто нет. Но качество пакетов неровное — часть поддерживается одним энтузиастом, и после крупного апдейта Debian такой пакет может месяцами ждать починки.

Cloudron уже полностью поставит и Nextcloud, и WordPress, и GitLab, и Discourse — тяжёлые вещи, которые в YunoHost тоже есть, но с Cloudron поведение стабильнее: если сравнить установку Nextcloud напрямую на VPS с тем же приложением из каталога Cloudron, разница именно в предсказуемости — Cloudron сам следит за совместимостью версии приложения с версией платформы и не даст обновиться в несовместимое состояние.

Требования к железу и на каком тарифе что тянет

YunoHost гораздо легче стартует. Голая система с админкой и парой лёгких приложений (например, почта + список чтения) комфортно работает на 1 ГБ RAM и 1 vCPU. Каждое дополнительное приложение — это ещё один процесс PHP-FPM или Node поверх общей ОС, без изоляции контейнеров, поэтому накладные расходы минимальны.

Cloudron с самого начала тяжелее: сам движок плюс Docker plus контейнер для каждого приложения означают заметный оверхед памяти. Разработчики официально рекомендуют от 2 ГБ RAM для старта и от 4 ГБ, если приложений больше 5-6. Здесь работает та же логика, что и с любым Docker-PaaS — почитайте, сколько RAM реально нужно Coolify, Cloudron ведёт себя похоже: тратит память на изоляцию, а не только на сами сервисы.

Практический ориентир (именно ориентир — зависит от набора приложений и нагрузки):

• YunoHost, 3-5 лёгких сервисов: 2 vCPU / 2 ГБ RAM / 40 ГБ NVMe.
• YunoHost, 8-10 сервисов с почтой: 4 vCPU / 4 ГБ RAM / 80 ГБ NVMe.
• Cloudron, 3-5 приложений: 2 vCPU / 4 ГБ RAM / 60 ГБ NVMe.
• Cloudron, 8-10 приложений: 4 vCPU / 8 ГБ RAM / 120 ГБ NVMe.

Обновления и бэкапы: кто и как автоматизирует

В YunoHost обновления идут через привычный apt-механизм — приложения обновляются командой yunohost app upgrade, ядро системы — обычным apt upgrade. Это прозрачно и знакомо любому, кто работал с Debian, но и ответственность на вас: если пакет приложения плохо написан, апгрейд может сломать конфиг, и откатываться придётся руками или из бэкапа.

yunohost app upgrade --all
yunohost backup create

Встроенная система бэкапов в YunoHost делает снепшот приложения (данные + конфиг + база) в архив, который можно хранить локально или выгружать на внешнее хранилище через плагин.

Cloudron обновляет приложения из панели одним кликом, причём перед обновлением автоматически создаёт бэкап — если апдейт пройдёт плохо, откат на предыдущую версию занимает пару минут через интерфейс, без ручного восстановления архива. Бэкапы Cloudron из коробки умеют улетать в S3-совместимое хранилище по расписанию — это удобнее, чем городить cron поверх YunoHost, но и это часть платной подписки на большинстве тарифов.

Домены, SSL и несколько приложений на одном сервере

YunoHost изначально проектировался под мультидоменность: можно повесить mail.example.com, cloud.example.com и wiki.example2.com на один сервер, у каждого приложения свой путь или поддомен, SSL получает и продлевает Let's Encrypt автоматически через yunohost domain cert-install. Никакого wildcard не требуется — под каждый домен просто добавляется A-запись.

Cloudron требует wildcard-сертификат и wildcard DNS для основного домена, потому что раздаёт приложениям автоматические поддомены. Это удобно, пока вы работаете в рамках одного домена — не нужно вручную настраивать SSL под каждое приложение, Cloudron сам всё выпустит через Let's Encrypt при первой установке. Но если хочется развести приложения по разным доменам верхнего уровня, придётся так же добавлять wildcard-запись для каждого — сложнее, чем в YunoHost, но не невозможно.

Деньги: во что обходится каждый вариант в реальности

YunoHost сам по себе бесплатен полностью — платите только за сервер. Это открытый проект без коммерческой модели, живёт на пожертвования.

Cloudron бесплатен до 2 установленных приложений — этого хватит попробовать платформу, но не для реального использования. Дальше — платная подписка, привязанная к количеству приложений (актуальные цифры и тарифы лучше сверить на официальном сайте Cloudron перед покупкой, они меняются). На горизонте года разница в бюджете ощутима: YunoHost с 8 приложениями стоит ровно то, что стоит сервер; Cloudron с тем же набором — сервер плюс ежемесячная подписка поверх.

При этом сравнивать стоит не только подписку, но и время администратора. Если вы цените, что Cloudron сам делает бэкап перед апдейтом и откатывает в один клик при сбое, экономия времени может перекрыть разницу в цене — особенно если сервисов много и падение одного из них стоит вам клиентов или репутации.

Частые вопросы