Coolify против Dokploy: что выгоднее и когда

MAATRIX

Обе панели обещают одно и то же: Heroku на своём VPS за одну команду, с гитом, сертификатами и базами рядом. Выбирают между ними по скриншотам, а настоящая разница глубже: Coolify запускает приложения обычными Docker-контейнерами, Dokploy переводит сервер в режим Docker Swarm — и это тянет за собой сеть, тома, обновления и способ отладки. Разберём, Coolify или Dokploy, с замерами памяти, текстами ошибок и честным списком того, где проседает каждая.

Что это за проекты и в какой они форме

Coolify — платформа четвёртой ветки на Laravel, развивается с 2021 года. Панель на порту 8000, состояние в /data/coolify, под капотом Postgres, Redis и Traefik v3. Каталог — порядка трёхсот шаблонов. Сообщество большое: по любой ошибке находится тред на GitHub или в Discord, и это не мелочь, когда деплой встал в два часа ночи.

Dokploy — проект помоложе, TypeScript/Next.js, растёт с 2024 года. Панель на порту 3000, состояние в /etc/dokploy, набор служб тот же, шаблонов около сотни. Честная деталь: на момент написания Dokploy выпускается с версиями вида 0.2x.x — до единицы проект формально не дошёл, и ломающие изменения между релизами случаются чаще, чем хочется в проде.

Оба под Apache 2.0, оба бесплатны при self-host без ограничений на число приложений, у обоих есть платное облако. Функционально они пересекаются процентов на восемьдесят: гит-деплой по вебхуку, автоматический Let's Encrypt, базы с бэкапом в S3, preview-деплои под пул-реквесты, веб-терминал. Сравнивать списки фич бессмысленно — расходятся они в двух местах: в модели запуска приложений и в зрелости.

Архитектура: обычный Docker против Docker Swarm

Это главный водораздел, всё остальное — следствие.

Coolify ничего не меняет в вашем Docker. Приложение — обычный контейнер, мультиконтейнерное — обычный проект docker compose в /data/coolify/applications/<uuid>/. Работают привычные docker ps, docker logs, docker exec.

Dokploy при установке переводит демон в режим кластера: инсталлятор сам выполняет docker swarm init. Проверка — docker info --format '{{.Swarm.LocalNodeState}}' вернёт active. Приложения становятся Swarm-сервисами:

docker service ls
ID             NAME           MODE         REPLICAS   IMAGE
q3f9v1h2k7lm   myapp-a1b2c3   replicated   1/1        myapp-a1b2c3:latest
8sk20dj4l1xa   dokploy        replicated   1/1        dokploy/dokploy:latest

Контейнер называется myapp-a1b2c3.1.z9fk..., управление идёт через docker service logs, docker service update, docker service ps. Привычный docker restart сработает не так, как вы ждёте: Swarm просто пересоздаст задачу.

Что это даёт на практике:

• Плюс: честный rolling update из коробки. При редеплое Swarm поднимает новую задачу, ждёт health check и только потом гасит старую — ноль простоя без единой настройки. Coolify так тоже умеет, но это его логика поверх меток Traefik, и включать её надо осознанно.
• Минус того же самого: в момент редеплоя памяти нужно вдвое больше. Приложение с пиком 700 МБ на время обновления требует 1,4 ГБ. На VPS с 4 ГБ, где параллельно идёт сборка, это прямая дорога в OOM. Лечится переводом сервиса в режим «сначала погасить»: docker service update --update-order stop-first <имя> — секунды простоя вместо убитого сервера.
• Минус: незнакомый слой отладки. Если команда читает docker compose, но не трогала Swarm, каждый инцидент дороже на одну технологию.
• Честно про сам Swarm. Mirantis его поддерживает, но крупной разработки там не ведётся много лет: технология стабильная, но замороженная. Dokploy использует тонкий срез — сервисы, overlay-сеть, rolling update, — так что риск умеренный.

Многосерверность тоже разная: Coolify добавляет машины по SSH (каждая живёт сама по себе, общей сети нет), Dokploy — как Swarm-воркеры через docker swarm join --token SWMTKN-1-... <ip-менеджера>:2377, с настоящим планированием задач и overlay-сетью.

Ресурсы: замер в простое, а не обещания из README

Стенд одинаковый: чистая Ubuntu 24.04, 2 vCPU / 4 ГБ / NVMe, ничего не задеплоено, только что установленная панель. Команда — docker stats --no-stream --format 'table {{.Name}}\t{{.MemUsage}}'.

Coolify                          Dokploy
coolify           412MiB         dokploy.1.z9fk2h1x   208MiB
coolify-realtime   48MiB         dokploy-postgres      74MiB
coolify-db         96MiB         dokploy-redis          9MiB
coolify-redis      12MiB         dokploy-traefik       36MiB
coolify-proxy      38MiB

Что в итоге остаётся приложениям:

Разница — примерно 500 МБ. На машине с 4 ГБ это 12% объёма, то есть ещё одно небольшое приложение; на 8 ГБ и выше — погрешность.

И сразу поправка: память съедает не панель, а сборки. Nixpacks, собирающий Next.js, пиково просит 2–3 ГБ независимо от того, кто его запустил. Swap на 4 ГБ нужен обеим (swapon --show должен что-то показывать), а экономия 500 МБ важна только на маленьких VPS. Расчёт — в материале сколько RAM нужно для Coolify, у Dokploy арифметика та же.

Функции: где они действительно расходятся

• Способы сборки. У Coolify — Nixpacks, свой Dockerfile, Docker Compose, статика. У Dokploy то же плюс Heroku/Paketo-buildpacks. Для прода берите свой Dockerfile: обновился Nixpacks — молча поменялась версия рантайма.
• Каталог шаблонов. Около трёхсот сервисов в один клик у Coolify против сотни у Dokploy. Разворачиваете зоопарк опенсорса (Vaultwarden, Umami, Uptime Kuma, Immich) — готовый шаблон вероятнее у Coolify.
• Мониторинг. Здесь выигрывает Dokploy: графики CPU, памяти и сети по каждому контейнеру есть из коробки. У Coolify телеметрия скромнее и включается отдельно — обычно рядом ставят Netdata или Grafana.
• Сообщество. Кратный перевес у Coolify. По Dokploy нередко единственный источник — Discord и исходники, а статьи устаревают между минорными релизами.
• Бэкап самой панели. У Coolify это пара: дамп Postgres плюс .env с APP_KEY, которым Laravel шифрует секреты; потеряли ключ — дамп мёртв. У Dokploy проще: каталог /etc/dokploy плюс дамп его Postgres.

Обе требуют свободные 80 и 443 и одинаково упираются в лимит Let's Encrypt: 50 сертификатов в неделю на домен при HTTP-01-проверке. Стенд, где приложения пересоздаются десятками, выбирает его за пару дней.

Грабли, о которых README умалчивает

Dokploy: swarm init на машине с несколькими адресами. Самая частая поломка установки. Если на сервере поднят WireGuard, приватная сеть или второй интерфейс, инсталлятор падает:

Error response from daemon: could not choose an IP address to advertise
since this system has multiple addresses on different interfaces
(10.8.0.2 on wg0 and 203.0.113.10 on eth0) - specify one with --advertise-addr

Решение — инициализировать кластер руками до запуска установочного скрипта, явно указав публичный адрес: docker swarm init --advertise-addr 203.0.113.10. Скрипт увидит активный Swarm и не станет его трогать.

Dokploy: переустановка на узле, который уже в кластере. Второй заход даёт:

Error response from daemon: This node is already part of a swarm.
Use "docker swarm leave" to leave this swarm and join another one.

Выйти можно через docker swarm leave --force, но осознайте цену: команда удаляет все сервисы узла, то есть все задеплоенные приложения. Данные в /etc/dokploy останутся, сами приложения придётся создавать заново.

Dokploy: конфликт подсетей. Swarm нарезает overlay-сети из пула 10.0.0.0/8. Если ваш VPN или приватная сеть между серверами живут в том же диапазоне, маршруты конфликтуют: контейнеры перестают видеть внешние хосты, а вы час ищете проблему в приложении. Чинить надо до первого деплоя, в /etc/docker/daemon.json:

{
  "default-address-pools": [
    { "base": "10.201.0.0/16", "size": 24 }
  ]
}

Затем systemctl restart docker и пересоздание ingress-сети:

docker network rm ingress
docker network create --driver overlay --ingress \
  --subnet 10.202.0.0/24 --gateway 10.202.0.1 ingress

Позже это возможно только с полной пересборкой сервисов, так что вопрос «какие подсети заняты» закрывайте в первый день.

Dokploy: порты кластера. Одному узлу хватает 22, 80, 443 и 3000. Со вторым добавляются 2377/tcp (управление кластером), 7946/tcp и 7946/udp (обнаружение узлов), 4789/udp (VXLAN overlay). В интернет их открывать нельзя — только между узлами:

ufw allow from 10.8.0.0/24 to any port 2377 proto tcp
ufw allow from 10.8.0.0/24 to any port 7946
ufw allow from 10.8.0.0/24 to any port 4789 proto udp

Dokploy: тома в кластере локальны. Bind-mount живёт на конкретном узле: отмасштабировали сервис до двух реплик на двух машинах — получили два независимых каталога данных и очень странные баги. Для состояния нужен NFS, S3 или внешняя база.

Coolify: три ловушки. Панель управляет даже собственным хостом через SSH под root, поэтому PermitRootLogin no в sshd_config ломает все деплои с Permission denied (publickey). Потеря APP_KEY делает дамп базы бесполезным. Миграции накатываются в одну сторону — отката на предыдущий тег нет. Подробности — в статье как установить и настроить Coolify на VPS.

Таблица и честный вывод: Coolify или Dokploy

Берите Coolify, если это прод, а не эксперимент; если серверов один или несколько, но независимых; если важно, чтобы по любой ошибке нашлось обсуждение; если отлаживать хочется привычными docker compose и docker logs. Пятьсот мегабайт разницы окупятся одним не потерянным вечером.

Берите Dokploy, если упираетесь в 2–4 ГБ и каждая сотня мегабайт на счету; если хотите rolling update без настроек и графики по контейнерам из коробки; если в планах кластер из двух-трёх узлов и Swarm вас не пугает.

Не берите ни ту, ни другую, если у вас одно приложение на одном сервере: docker compose up -d плюс Caddy с автосертификатом — меньше движущихся частей и ноль обновлений панели (панель против чистого сервера, Docker Compose для продакшена). И не ждите от них кубернетесного: автоскейлинга по метрикам, политик размещения, операторов для баз.

Про цену ошибки: переезд между ними — не импорт, а пересоздание. Общего формата экспорта нет, состояние каждой панели лежит в её собственном Postgres. Переносится то, что и так в репозитории: Dockerfile, compose.yaml, переменные окружения, плюс дампы баз и DNS. Для пяти приложений — вечер работы.

Какой сервер взять в MAATRIX под Coolify или Dokploy

Минимум — 2 vCPU, 4 ГБ RAM, 60 ГБ NVMe плюс swap на 4 ГБ. Приложениям остаётся примерно 2,6 ГБ под Coolify и 3,1 ГБ под Dokploy: одно-два небольших приложения с базой, если сборки идут по одной. Двух гигабайт, которые иногда пишут в требованиях, хватит ровно на то, чтобы панель открылась, — первая же сборка фронтенда закончится exit code: 137.

Комфортный вариант — 4 vCPU, 8 ГБ RAM, 100–160 ГБ NVMe. Панель плюс 4–6 приложений с базами, сборка не мешает проду, места хватает на образы, кэш и дампы. Для Dokploy этот объём закрывает двойной расход памяти во время rolling update: на 4 ГБ он кусается, на 8 ГБ незаметен. Диск берите NVMe с запасом — /var/lib/docker растёт быстрее всего, за месяц активных деплоев там набегает 15–25 ГБ мусора (почему Docker занимает всё место).

Если сборок много — 8 vCPU, 16 ГБ. Сборка упирается в процессор: тот же Next.js на двух ядрах собирается около пяти минут, на восьми — полторы. Дешевле разнести control plane и прод: маленькая машина под панель, отдельные серверы под приложения — тогда обновление или падение панели не касается боевого трафика. Для кластера на Dokploy узлам нужна приватная связность для 2377, 7946 и 4789; приватной сети нет — поднимите WireGuard и инициализируйте Swarm с --advertise-addr адреса из туннеля.

Локация. Для обеих панелей по умолчанию советуем Лондон, причина инженерная: сервер непрерывно тянет образы с Docker Hub и ghcr.io, пакеты с npm и PyPI, код с GitHub. С российских адресов часть реестров отвечает отказом или работает через раз, и чинить вы будете не приложение, а доступ к зеркалам. Британская площадка ходит везде без ухищрений, пинг из Москвы — 45–60 мс, для веб-панели неотличимо от локальной. Франция равноценна при аудитории в континентальной Европе и GDPR-периметре. США — когда приложениям нужен американский IP: зарубежные AI-API, платёжные сервисы, чистые адреса. Россия — когда персданные обязаны храниться в РФ по 152-ФЗ; тогда сразу закладывайте зеркала реестров.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна, даже когда сервер в Лондоне. Не уверены в конфигурации — напишите, сколько приложений планируете и на чём они написаны, поможем подобрать без запаса «на всякий случай». Смежное: Portainer или Docker CLI, Docker Swarm на VPS.

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