Cloudron в Docker Compose: готовый файл

MAATRIX

Ставить себе десяток self-hosted приложений вручную — это десяток разных способов их обновлять, бэкапить и чинить, когда что-то ломается в 2 часа ночи. Cloudron решает эту проблему панелью, которая сама устанавливает, обновляет и бэкапит приложения из своего каталога, но обычно её разворачивают через собственный установочный скрипт, а не через docker-compose. Если вы хотите держать конфигурацию в git и поднимать Cloudron предсказуемо, вместе с остальным стеком — вот рабочий compose-файл и что нужно знать до запуска.

Почему Cloudron не всегда дружит с Docker Compose

Сразу честно: Cloudron — не типичное «одно приложение в одном контейнере». Внутри это оркестратор, который сам управляет Docker на хосте: скачивает образы приложений из своего каталога, поднимает для них контейнеры, настраивает reverse proxy и DNS. Официальный путь установки — bash-скрипт cloudron-setup, который ставит Cloudron прямо на хост (не в контейнер) и берёт под контроль системный Docker.

Запуск самого Cloudron *внутри* Docker Compose — не то, что поддерживает и тестирует команда разработчиков. Но у части администраторов есть законный сценарий: развернуть Cloudron как управляемый контейнер на сервере, где Docker уже используется для других задач, и получить воспроизводимую конфигурацию. Ниже — рабочий вариант такого файла на основе официального образа cloudron/base с прокинутым Docker-сокетом, плюс честный список ограничений.

Если воспроизводимость через compose для вас не принципиальна и просто нужен рабочий Cloudron как можно быстрее — официальный скрипт-установщик на чистую систему надёжнее и ближе к тому, что тестируют разработчики.

Требования к серверу

Cloudron — тяжёлая штука, рассчитанная на несколько одновременно работающих приложений (почта, файлы, CRM, чаты), поэтому экономить на ресурсах не стоит.

Официально Cloudron поддерживает Ubuntu и Debian на голом железе или VPS с полноценным ядром (не LXC-контейнеры без доступа к системным вызовам вроде mount и cgroup) — это важно, если вы берёте бюджетный VPS: уточните у провайдера, что виртуализация KVM, а не OpenVZ/LXC. Если у вас ещё нет Docker на сервере — сначала поставьте его по нашему гайду Ubuntu 24.04: установка Docker с нуля, а дальше уже разбирайтесь с Cloudron.

Готовый docker-compose.yml

Ниже — конфигурация, которая поднимает Cloudron с пробросом Docker-сокета хоста (панели нужен доступ к Docker, чтобы управлять контейнерами приложений) и отдельными томами под данные, конфиги и box-файлы.

# docker-compose.yml
version: "3.9"

services:
  cloudron:
    image: cloudron/base:5.0.0
    container_name: cloudron
    restart: unless-stopped
    hostname: my.example.com
    environment:
      - CLOUDRON_FQDN=my.example.com
    ports:
      - "80:80"
      - "443:443"
      - "587:587"
      - "993:993"
      - "4190:4190"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - cloudron_data:/home/yellowtent
      - cloudron_appdata:/app/data
    networks:
      - cloudron_net

networks:
  cloudron_net:
    driver: bridge

volumes:
  cloudron_data:
  cloudron_appdata:

Перед запуском замените my.example.com на реальный домен (или поддомен), который уже указывает A-записью на IP сервера — Cloudron жёстко завязан на свой FQDN при первичной настройке и переезд на другой домен потом болезненный.

docker compose up -d
docker compose logs -f cloudron

Первый запуск занимает несколько минут — панель разворачивает внутреннюю инфраструктуру (базу, очередь, reverse proxy). После этого открывайте https://my.example.com в браузере — там начнётся визард первичной настройки: e-mail администратора, часовой пояс, включение автообновлений.

Тонкие места: Docker-сокет, том с данными, порты

Проброс /var/run/docker.sock. Cloudron управляет контейнерами приложений через Docker API хоста — без прокинутого сокета панель просто не сможет ставить приложения из каталога. Это же означает, что контейнер Cloudron получает фактический root-доступ к хосту: относитесь к нему как к системному сервису, а не к рядовому приложению в изолированной песочнице.

Один большой том вместо десятка мелких. cloudron_data хранит всё: конфиги, состояние платформы, метаданные установленных приложений. Не разбивайте его на части и не переносите содержимое руками между хостами без встроенного механизма миграции — структура каталогов внутри специфична для версии Cloudron.

Порты 587/993/4190. Если вы планируете использовать встроенную почту Cloudron (а не внешний SMTP), эти порты обязательны. У многих облачных провайдеров исходящий 25/587 порт заблокирован по умолчанию для новых аккаунтов — уточните это до установки, иначе почтовые уведомления и восстановление паролей просто не будут уходить.

Конфликт с уже занятыми 80/443. Если на сервере уже крутится другой reverse proxy (Traefik, nginx-proxy-manager) — Cloudron с ним не уживётся: он рассчитывает управлять этими портами единолично. Разворачивайте Cloudron на отдельном сервере или на сервере, где 80/443 ещё свободны. Про выбор между этими прокси для других задач можно почитать в статье Traefik или Nginx Proxy Manager: что выбрать для сервера.

Обновления и автоматические бэкапы

Ключевая ценность Cloudron — не сам факт запуска панели, а то, что она дальше сама следит за приложениями.

• Обновления приложений тянутся из каталога Cloudron автоматически (можно включить автообновление или подтверждать каждое вручную) — вам не нужно вручную мониторить релизы двадцати разных проектов.
• Обновления самой платформы тоже накатываются через встроенный механизм — раз в несколько недель выходит новая версия ядра Cloudron.
• Бэкапы настраиваются в разделе Backups: можно указать S3-совместимое хранилище (в том числе self-hosted MinIO) или локальную директорию, задать расписание и глубину хранения. Бэкапится и платформа, и данные всех установленных приложений одним снапшотом.

Важный нюанс именно для варианта в Docker Compose: убедитесь, что бэкап-таргет (S3-бакет или примонтированная директория) не находится внутри тех же именованных томов cloudron_data/cloudron_appdata — иначе при потере тома вы теряете и бэкапы вместе с данными. Для внешнего хранилища бэкапов проще всего поднять отдельный MinIO-сервер или взять S3 у стороннего провайдера.

Что дальше после установки

После визарда у вас в панели доступен каталог из полусотни с лишним готовых приложений — от Nextcloud и почтового сервера до GitLab и WordPress; каждое ставится в пару кликов, получает свой поддомен и SSL-сертификат от Let's Encrypt автоматически. Если вам не нужна именно оркестрирующая панель, а хочется поднять конкретное приложение самостоятельным compose-файлом с контролем над каждой деталью — посмотрите на прямые аналоги в нашем разделе про self-hosted стек, например статью про Coolify на Ubuntu 24.04: пошаговая установка — Coolify решает похожую задачу (управление приложениями и деплоями), но с другой архитектурой и без встроенной почты.

Ресурсы стоит мониторить отдельно: Cloudron под нагрузкой в несколько приложений легко съедает выделенные 4 ГБ RAM, особенно если среди них база данных или почтовый сервер с антиспам-фильтрами. Если после установки нескольких приложений сервер начинает подтормаживать — это сигнал не оптимизировать конфиги, а расширять ресурсы: добавить RAM или вертикально апгрейднуть VPS.

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