Coolify: свой PaaS на домашнем сервере

Домашний сервер редко остаётся полигоном для одного контейнера. Сначала появляется облачное хранилище, потом база для заметок, затем пара внутренних сервисов, и вот уже на хосте лежат десяток compose-файлов, самодельные скрипты обновления и сертификаты, которые продлеваются вручную. Coolify закрывает эту прослойку: панель собирает приложения из Git, выдаёт им домены и TLS, поднимает базы и хранит переменные окружения. Разберём установку и повседневную работу, а также места, где панель ломается предсказуемо.

Что даёт Coolify

Coolify — открытый self-hosted PaaS. Он работает поверх Docker и умеет три вещи: собирать образ из репозитория, запускать его рядом с базой и публиковать наружу по домену с сертификатом. Сборка идёт через Nixpacks (автоопределение языка), Dockerfile или готовый docker-compose. Базы Postgres, MySQL, MariaDB, Redis, MongoDB и ClickHouse ставятся в один клик и получают внутренние учётные данные.

Границы стоит понимать сразу. Это не Kubernetes: оркестрации между десятками машин, автоскейлинга и сложных политик здесь нет. Панель не чинит приложение: упавший контейнер придётся разбирать по логам. Зато для одного-двух серверов и небольшой команды Coolify снимает рутину, которая обычно держится на bash-скриптах.

Подготовка сервера

Минимум — два ядра и два гигабайта памяти, но с базами и сборкой образов комфортнее начинать с четырёх. Подойдёт Debian 12/13 или Ubuntu 22.04/24.04 с чистым Docker. Ставьте панель на отдельный хост: она управляет Docker, и соседство с чужими контейнерами усложняет разбор конфликтов.

Сначала базовая гигиена: обновления, отдельный пользователь, ключи вместо пароля и межсетевой экран.

sudo apt update && sudo apt full-upgrade -y
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo ufw allow 22/tcp && sudo ufw allow 80,443/tcp
sudo ufw enable

Домен панели и приложений должен указывать A-записью на внешний адрес. Если адрес динамический, понадобится DDNS-имя и короткий TTL. Для Let’s Encrypt нужен доступ по порту 80: проверка домена идёт через HTTP, и закрытый порт превращается в повторяющиеся ошибки выпуска сертификата.

Установка

Официальный установщик поднимает Docker, если его нет, создаёт тома и запускает контейнеры панели. Скрипт стоит скачать и прочитать: он выполняется от root и меняет систему.

curl -fsSL https://cdn.coollabs.io/coolify/install.sh -o install.sh
less install.sh
sudo bash install.sh
docker ps --format 'table {{.Names}}\t{{.Status}}'

После установки панель доступна по адресу http://IP:8000. Первый вход создаёт администратора. Сразу после входа задайте домен в настройках экземпляра и включите HTTPS — панель сама запросит сертификат.

Порт 8000 после этого лучше закрыть снаружи: он остаётся техническим входом и не должен светиться в интернете.

sudo ufw delete allow 8000/tcp
sudo ss -tulpn | grep -E ':(80|443|8000|6001|6002)'
docker ps --format 'table {{.Names}}\t{{.Status}}'

Порты 6001 и 6002 нужны терминалу и realtime-соединениям. Если панель стоит за другим прокси, их придётся прокидывать отдельно, иначе терминал в браузере не откроется.

Первый деплой из Git

Дальше создаётся проект и окружение, например production. Источник — публичный репозиторий, GitHub App или приватный ключ. Для большинства проектов хватает Nixpacks: он находит package.json, requirements.txt или go.mod и собирает образ без Dockerfile. Если сборка нестандартная, укажите свой Dockerfile или compose-файл.

В настройках приложения задаются домен, внутренний порт, переменные окружения и healthcheck. Порт важен: панель публикует контейнер через прокси и должна знать, куда отправлять трафик. Ошибка «502 Bad Gateway» почти всегда означает расхождение между портом в приложении и портом в настройках.

git add . && git commit -m "deploy: env and healthcheck"
git push origin main
docker logs -f --tail 100 $(docker ps -qf name=app)
docker inspect --format '{{.State.Health.Status}}' $(docker ps -qf name=app)

Автодеплой работает по вебхуку: push в ветку запускает сборку. Полезно включить уведомления в Telegram или почту — иначе упавшая сборка обнаружится через сутки, когда пользователи напишут о недоступности.

Базы данных и тома

Базу удобнее создавать в том же окружении: панель выдаст внутренний хост, порт, логин и пароль и подставит их в переменные приложения. Наружу порт базы открывать не нужно — доступ идёт по внутренней сети Docker.

Отдельная тема — бэкапы. У Coolify есть расписание и выгрузка в S3-совместимое хранилище, но проверять восстановление всё равно обязан человек. Раз в месяц разворачивайте дамп на тестовой базе: непроверенная копия — это не бэкап, а надежда.

docker exec -t coolify-db pg_dump -U coolify coolify > coolify-$(date +%F).sql
docker exec -t coolify-db psql -U coolify -c '\l'
du -sh /var/lib/docker/volumes/* | sort -h | tail -10

Типичные сбои и диагностика

Сборка падает по памяти. Nixpacks с npm или pip на двух гигабайтах легко уходит в OOM. Решение — добавить swap, ограничить параллельные сборки или собирать образ в CI, а в Coolify указывать готовый registry-образ.

Контейнер работает, но сайт отдаёт 502. Проверьте healthcheck, порт и логи приложения. Часто сервис слушает 127.0.0.1 внутри контейнера вместо 0.0.0.0, и прокси до него не доходит.

Сертификат не выпускается. Причины по порядку вероятности: неверная A-запись, лишняя AAAA-запись на несуществующий IPv6, закрытый порт 80, исчерпан лимит Let’s Encrypt на повторные запросы.

dig +short app.example.com A
dig +short app.example.com AAAA
curl -I http://app.example.com/.well-known/acme-challenge/test
journalctl -u docker --since "1 hour ago" | tail -50

Старые образы и логи съедают десятки гигабайт: настройте ротацию логов Docker и следите за docker system df.

docker system df
docker image prune -a --filter "until=168h"
df -h /var/lib/docker

Обновления

Панель обновляется из интерфейса, но перед крупным обновлением сделайте снимок виртуальной машины или бэкап тома с базой Coolify. После обновления проверьте базовые сценарии:

• вход в панель и выпуск сертификата;
• деплой тестового приложения из Git;
• восстановление дампа базы на тестовом стенде;
• свободное место на диске и ротацию логов Docker после сборки.

Откат без бэкапа превращается в ручную сборку заново.

Итог

Coolify занимает нишу между ручным compose и Kubernetes и хорошо работает на одном сервере с десятком сервисов. Начните с отдельного хоста, домена и закрытых технических портов, включите бэкапы баз и уведомления о сборках. Тогда панель экономит время, а не создаёт новую точку отказа, о которой вы узнаете в самый неудобный момент.