Если вы уже ушли от управляемой PaaS, ваш VPS подготовлен, SSH-ключ добавлен, а курсор терминала мигает на строке установки. Остаётся единственный вопрос: запускать ли вам curl ... | bash для Coolify или для Dokploy?
Оба инструмента устанавливаются одной командой. Оба дают вам развёртывания по Git-push, автоматический SSL, веб-интерфейс и обратный прокси поверх Docker. Интересные различия — те, что проявляются в продакшене: как каждый обрабатывает стандартный docker-compose.yml, что происходит во время развёртывания и как каждый проект отреагировал на новости, изменившие это сравнение в 2026 году. Две новости несут здесь основную тяжесть: раскрытие CVE в Coolify в январе 2026 и реструктуризация лицензии Dokploy того же месяца.
Эта статья сопоставляет каждый инструмент с конкретным сценарием использования, а не венчает победителя. К концу вы, надеемся, поймёте, какой из них подходит вашему рабочему процессу.
Коротко о главном
- Coolify старше и с более крупной экосистемой (~55k звёзд на GitHub, 300+ шаблонов сервисов в один клик), тяжелее в простое, целиком на Apache 2.0, без платного уровня на self-hosted-стороне.
- Dokploy моложе (~34k звёзд), легче в простое, ядро на Apache 2.0 плюс отдельная Source Available License, ограничивающая будущие платные функции (SSO, RBAC, журналы аудита, white-labeling).
- Coolify сегодня не может делать zero-downtime развёртывания через Docker Compose; только через Dockerfile, Nixpacks или развёртывания одного образа. Dokploy поставляет Docker Swarm как полноценный режим; Swarm в Coolify помечен как экспериментальный.
- CVE Coolify января 2026 исправлены в v4.0.0 (April 27, 2026). Обновите Coolify и не выставляйте панель управления в публичный доступ.
Когда ни один из инструментов не подходит
И Coolify, и Dokploy не подходят по форме для некоторых конфигураций. Три альтернативы, о которых стоит знать, вкратце:
- Kamal (от 37signals): для команд с одним-двумя приложениями, которым не нужен интерфейс; просто
kamal deployс вашего ноутбука. Намного проще Coolify или Dokploy и правильный выбор, когда панель управления вам не нужна. - Dokku: классическая модель Git-push, один сервер. Старше, меньше по охвату, очень стабильна. Тот самый оригинальный «Heroku на одном VPS».
- GitHub Actions + Docker Compose на голом VPS: минимально возможный стек. Никакого интерфейса оркестрации, но и накладных расходов на оркестрацию тоже нет. Хорош для одного приложения, где процесс развёртывания
docker compose pull && docker compose up -dзапускается из CI.
Если ваша форма — это одно приложение на одном сервере, то и Coolify, и Dokploy, скорее всего, избыточны; попробуйте сначала что-то из перечисленного выше. Если у вас несколько приложений, несколько баз данных или команда с нетехническими участниками, которым нужен интерфейс для управления, то выбор между Coolify и Dokploy — правильный. Для более широкого обзора вариантов в этой категории смотрите наш разбор self-hosted облачным платформам с веб-интерфейсом.
Coolify и Dokploy вкратце
Coolify v4.0.0 stable вышел April 27, 2026 после долгого цикла бета-тестирования. Dokploy находится на v0.29.4 по состоянию на May 11, 2026. Оба — open-source self-hosted PaaS-проекты в пространстве альтернатив Heroku/Render/Vercel, оба оборачивают Docker интерфейсом, обратным прокси с HTTPS-по-умолчанию (Traefik) и развёртываниями на основе Git.
| Характеристика | Coolify | Dokploy |
|---|---|---|
| Последний стабильный релиз | v4.0.0 (April 27, 2026) | v0.29.4 (May 11, 2026) |
| Лицензия | Apache 2.0 | Ядро Apache 2.0 + Source Available для платных функций |
| Технологический стек | PHP / Laravel | TypeScript / Node.js |
| Звёзды на GitHub | ~55,000 | ~34,000 |
| Минимальный RAM (официально) | 2 GB | 2 GB |
| Минимальный CPU (официально) | 2 ядра | не указано |
| RAM в простое (по данным сообщества) | 500 MB – 1.2 GB | 300 – 400 MB |
| Zero-downtime для Docker Compose | Не поддерживается (только Dockerfile/Nixpacks) | Стандартная обработка Compose |
| Кластеризация на несколько серверов | Docker Swarm (экспериментальный) | Docker Swarm (нативный) |
| Поддержка ARM64 | Да (включая Raspberry Pi OS) | Не заявлено в документации |
| Системы сборки | Nixpacks, Dockerfile, Docker-образ | Nixpacks, Dockerfile, Docker-образ, Heroku Buildpacks, Paketo, Railpack |
| Обратный прокси | Traefik | Traefik |
| Охват self-hosted мониторинга | Встроенные метрики + просмотр логов | Базовые метрики ресурсов + ИИ-анализ ошибок логов/сборки (v0.29.0+) |
Наше мнение: выбирайте Dokploy, если хотите меньше накладных расходов в простое, нативную поддержку нескольких серверов и стандартную обработку Docker Compose без специфичных для платформы подгонок. Выбирайте Coolify, если хотите более крупную библиотеку приложений в один клик, поддержку ARM64/Raspberry Pi или чистый Apache 2.0 без платного уровня, ждущего своего часа.
Потребление ресурсов и подбор размера VPS
Self-hosted PaaS может сэкономить вам стоимость Heroku. Если слой оркестрации съедает 1,5 GB из ваших 2 GB на VPS в простое, развёртывать уже некуда. Так что первый практический вопрос на небольшом сервере: во сколько вам обходится каждый инструмент ещё до того, как вы развернули хоть одно приложение?
Потребление RAM в простое у Coolify зависит от того, какой мониторинг включён, с базовым уровнем нагрузки на CPU в 5–7%, который подскакивает при запуске сбора метрик. Собственная документация Coolify использует репрезентативную продакшен-нагрузку: 8 GB RAM, 4 ядра и 150 GB хранилища, на которых работают 3 приложения Node.js, 4 статических сайта и несколько баз данных. Это разумный ориентир для подбора размера, если ваш стек выглядит похоже.
Dokploy, напротив, работает гораздо легче — заметно ниже 2% CPU, когда ничего не разворачивается.
A разбор продакшена от LogRocket с одновременным запуском обоих инструментов пришёл к тому же выводу по направлению: docker stop && docker start на приложении в Dokploy не запускает полную пересборку, тогда как та же операция в Coolify запускает. Уже одно это смещает постоянные затраты в пользу Dokploy, особенно на небольших тарифах VPS, где штормы пересборок съедают ваш бюджет CPU.
Для подбора размера вот конфигурация VPS, которую я бы порекомендовал:
- Coolify, лёгкая нагрузка: 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
- Coolify, эталонная продакшен-нагрузка: 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
- Dokploy, лёгкая нагрузка: 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
- Dokploy, запас под продакшен: 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.
Совет профи: RAM Coolify в простое масштабируется с конфигурацией мониторинга. Если у вас мало памяти, уменьшите интервал сбора метрик (или вовсе отключите встроенный мониторинг, если у вас уже работает Prometheus/Grafana в другом месте), прежде чем заказывать сервер побольше.
Реальность развёртывания: Docker Compose, Dockerfile и zero-downtime
Большинство команд приходят к одному из этих инструментов с уже имеющимся docker-compose.yml и ожиданием: вставить файл, нажать «развернуть», увидеть, как приложение поднимается. Как каждая платформа обрабатывает стандартный Compose и что происходит с запросами в полёте во время следующего развёртывания — вот где проявляется практическое различие.
Coolify поддерживает Docker Compose, Dockerfile, Nixpacks (автоопределение по файлам проекта) и прямые развёртывания Docker-образов. Однако есть нюанс, о котором стоит сказать прямо: zero-downtime развёртывания (скользящие обновления, blue/green) работают в Coolify только через Dockerfile, Nixpacks или развёртывания одного образа. Через Docker Compose они не работают. Сопровождающий Coolify подтвердил в обсуждении на GitHub что «для развёртываний на основе compose все контейнеры останавливаются перед запуском новых, скользящего обновления для развёртываний на основе compose сейчас нет». Поддержка скользящих обновлений для Compose стоит в дорожной карте на v5; v4 её не получит. Обходной путь, который предлагает сопровождающий, — разбить Compose-стек на отдельные сервисы Coolify, что является нетривиальной миграцией, если ваш Compose-файл выражает реальные межсервисные связи.
Последствие для пользователя проявляется в ветке на Hacker News о Coolify, где один из операторов выразился прямо: «любой ожидающий запрос при обновлении приложения просто убивается». Сегодня для Compose-развёртываний это точно.
Слой Compose в Coolify также добавляет то, что проект называет «магическими переменными». Это значит автоматическое внедрение вспомогательных образов, переписывание сетей и переопределение окружения. Замысел — повысить эффективность; побочный эффект в том, что docker-compose.yml который чисто работает на вашем ноутбуке, иногда требует корректировки, чтобы чисто работать в Coolify. Та же ветка на Hacker News всплывает показательный случай: «Добавил 8 переменных внутри docker-compose, распознаются только 7». Если ваш Compose-стек небольшой и стандартный, вы можете на это не нарваться. Если он большой или нестандартный — нарвётесь.
У Dokploy позиция другая. практический разбор от LogRocket обнаружил, что Dokploy «может развернуть существующий docker-compose.yml с минимальными изменениями или вовсе без них» и держится близко к нативной модели маршрутизации Docker на основе меток. Тот же разбор отмечает, что остановка/запуск контейнера в Dokploy не запускает полную пересборку, тогда как то же действие в Coolify — запускает. Это сигнал о направлении в поведении во время выполнения, а не формальная «гарантия zero-downtime» из документации Dokploy, но он согласуется с тем, что сообщают self-hosters на небольших инстансах VPS.
Dokploy также поддерживает Heroku Buildpacks, Paketo Buildpacks и Railpack в дополнение к Nixpacks и Dockerfile. Для команд, пришедших из Heroku с heroku.yml или рабочими процессами на основе buildpacks, это путь наименьшего сопротивления.
Ключевой вывод раздела: если ваши существующие сервисы — это настоящий стек Docker Compose, Coolify потребует от вас либо перестроить стратегию развёртывания, либо смириться с короткими простоями на каждый push. Dokploy — нет.
Безопасность: раскрытие CVE Coolify в январе 2026
Я читаю эту историю в более широком смысле так: Coolify безопасно запускать сегодня, если вы держите его обновлённым и не выставляете панель управления в публичный интернет. Раскрытие не дисквалифицирует проект. Ответственное раскрытие было соблюдено, и патчи вышли. Что оно действительно показывает — так это что поверхность атаки, доступная аутентифицированному пользователю с низкими привилегиями, была шире, чем следовало. Это урок проектирования для проекта и операционный урок для оператора: ужесточите модель доступа сейчас.
Совет профи: даже после установки патчей относитесь к панели управления Coolify как к SSH. Привяжите её к приватной сети, спрячьте за VPN или поставьте перед ней TailscaleНе выставляйте порт 8000 в публичный интернет только потому, что установочный скрипт делает это лёгким.
Dokploy тоже не застрахован от подобных проблем. примечания к релизу v0.29.3 признают уязвимость безопасности, выявленную в Dokploy, и поставляют скрипт-патч безопасности, который вы должны запустить вместе с обновлением. Меньше поверхность, короче история проекта, но применима та же операционная дисциплина: обновляйтесь в день выхода патчей, не оставляйте панель управления в публичном интернете.
Ключевой вывод раздела: история с CVE — это жёлтый флаг для операционной практики Coolify, а не красный флаг против проекта, но она поднимает планку дисциплины обновлений и того, как вы выставляете панель управления.
Лицензирование: что бесплатно, а что нет
Лицензия Dokploy была реструктурирована January 21, 2026. Вот что изменилось и что это значит для self-hosters.
Dokploy теперь стандартный Apache 2.0 для ядра, заменяя прежний нестандартный адаптированный Apache 2.0, который путал пользователей насчёт того, что является open source, а что нет. Отдельная Dokploy Source Available License теперь регулирует код в proprietary/ директориях: исходники видны, оплата за использование в продакшене. Функции, которые, по словам Dokploy, будут жить за этой лицензией:
- Единый вход (SSO/SAML) и расширенный контроль доступа
- Кастомный брендинг и white-labeling
- Высокая доступность, автомасштабирование и аварийное восстановление
- Расширенный мониторинг, интеграции и функции соответствия требованиям
Проект явно обязался никогда не переводить существующую open-source функцию в платный уровень; будущая платная функциональность нацелена на организации, которым нужна корпоративная «склейка». 2FA уже сегодня находится за уровнем Startup на странице цен Dokploy.
Ситуация с Coolify проста. Проект — это Apache 2.0 на GitHub; каждая функция в self-hosted-версии бесплатна. Есть предложение Coolify Cloud для команд, которые хотят, чтобы хостингом занимался сопровождающий, но self-hosted-версия — это полноценный продукт без ограничений функций и без пути обновления к платному уровню, которого у вас сегодня нет.
Моё прочтение: для соло-разработчиков и небольших команд, размещающих self-hosted на собственном VPS, Dokploy функционально бесплатен и таким останется. Для организации, которой в итоге понадобятся SSO, гранулярный RBAC, журналы аудита или white-labeling, Dokploy в итоге подтолкнёт вас к платному уровню. Coolify — нет, потому что у Coolify такого уровня в дорожной карте нет.
Уточнение по нескольким источникам, которое стоит сделать: self-hosted-сборка Dokploy всё же включает базовые метрики ресурсов (CPU, память, хранилище, сеть), а v0.29.0 добавила ИИ-анализ ошибок логов и сборки. Система мониторинга Dokploy работает только в облаке для более продвинутых функций мониторинга. Тем не менее мониторинг по-прежнему работает локально на self-hosted-установке для базовых метрик ресурсов до контейнера.
Несколько серверов и кластеризация: реальность против маркетинга
Рано или поздно одного VPS становится мало, и оба проекта заметно продвигают поддержку нескольких серверов на своих лендингах. Реальность на местах не такая.
У Coolify официальная документация по масштабируемости прямо об этом говорит: поддержка Docker Swarm помечена как экспериментальная. Стандартный паттерн на несколько серверов использует валидированные удалённые серверы, подключённые по SSH, с общим Docker Registry между ними и инстансами Traefik, работающими на каждом сервере. Режим Swarm требует минимум трёх серверов одной архитектуры (все ARM или все AMD64). Kubernetes? «Только запланирован, но пока не в дорожной карте, так что ETA нет». Если вы прочитаете собственную страницу Coolify об этом, краткая версия такая: несколько серверов работают, Swarm — это бета, а Kubernetes — это видение.
Dokploy поставляет Docker Swarm как полноценный режим без экспериментального флага. Traefik обрабатывает маршрутизацию как в одно-серверных, так и в Swarm-конфигурациях. Релиз v0.29.0 добавил поддержку нескольких серверов без root, что закрывает реальный пробел (больше никакого SSH только под root для добавления удалённых узлов).
Если кластеризация на несколько узлов понадобится вам в ближайшие полгода, а не «когда-нибудь на слайде», Dokploy сегодня — выбор с меньшим риском.
Ключевой вывод раздела: если кластеризация в вашей ближайшей дорожной карте, разница в Swarm склоняет рекомендацию в сторону Dokploy независимо от других осей.
Системы сборки и поддержка языков
Команды, пришедшие из Heroku, больше всего озаботятся тем, какие экосистемы buildpacks поддерживает каждый инструмент, потому что это решает, сколько переписывания понадобится вашему проекту перед первым развёртыванием.
Путь сборки Coolify — это Nixpacks (по умолчанию, автоопределение по файлам проекта), Dockerfile или заранее собранный Docker-образ. Nixpacks хорош для распространённых случаев (Node, Python, PHP, Go, Rust), но у автоопределения есть шероховатости. Стоит проверить для вашего стека: проблема Nixpacks января 2026 года, затрагивающая проекты Laravel с обоими composer.json и package.json порождала дублирующиеся блоки location в Nginx, что ломало целый класс развёртываний, пока это не исправили в апстриме.
Dokploy поддерживает Nixpacks, Dockerfile и Docker-образ, а сверху добавляет Heroku Buildpacks, Paketo Buildpacks и Railpack. Если ваш проект уже чисто собирается с heroku.yml или buildpack, Dokploy позволяет сохранить этот рабочий процесс. Coolify попросит вас конвертировать.
На первый взгляд оба инструмента выглядят одинаково: развёртывания по Git-push из GitHub, GitLab, Bitbucket, автоматический SSL от Let's Encrypt, веб-интерфейс для переменных окружения и управления базами данных. Широта систем сборки — одно из немногих мест, где Dokploy явно идёт дальше.
Каталоги приложений в один клик
Для нетехнических операторов, которые хотят развернуть известные open-source сервисы (n8n, Plausible, Supabase, Ghost, Listmonk — привычный self-hosted-набор), размер библиотеки шаблонов в один клик — реальный отличительный фактор. Для некоторых пользователей это важнее других областей вроде производительности или лёгкости.
Coolify предлагает 300+ сервисов в один клик примерно в 40 категориях: ИИ, аналитика, автоматизация, базы данных, безопасность, хранилище и прочее. Это библиотека крупнее с большим отрывом и практичный ответ для не-разработчиков, которые хотят развернуть сервис без написания Compose-файла.
Библиотека шаблонов Dokploy меньше. Текущая документация Dokploy не публикует чёткого числа, так что я не буду называть вам цифру.
Практический ответ: если ваш рабочий процесс — «развернуть n8n, Supabase и Plausible по два клика каждый», Coolify чисто выигрывает по этой оси. Если вы пишете собственные приложения и просто хотите их развернуть, размер каталога не важен, а важны другие оси.
Как выбрать: рекомендации по сценариям использования
Единого победителя здесь нет. Есть соответствия между инструментом и формой развёртывания:
- Нетехническая команда, которой нужна библиотека сервисов: Coolify. Каталог из 300+ шаблонов — это значимое преимущество.
- Docker-нативный разработчик, которому нужна лёгкость и стандартная обработка Compose: Dokploy.
- Оборудование ARM64 (Raspberry Pi, VPS на ARM): Coolify. Dokploy не заявляет поддержку ARM64 в текущей документации; если вы на ARM, по умолчанию выбирайте Coolify, пока не убедитесь в обратном.
- Кластеризация на несколько узлов, которую вы задействуете в этом квартале: Dokploy. Нативный Swarm против экспериментального Swarm — решающий фактор.
- Чистый Apache 2.0, без возможного будущего платного уровня: Coolify.
- Миграция с Heroku и желание сохранить Heroku Buildpacks: Dokploy.
- Беспокойство по поводу CVE января 2026: обновлённый Coolify (v4.0.0+) — это нормально. Реальный вопрос — ваша модель доступа. Если вы не можете привязать панель управления к приватной сети или VPN, Dokploy — менее нервный выбор: меньше поверхность и более короткая история раскрытий высокой степени серьёзности.
Заметка о развёртывании любого из инструментов
После выбора сама установка — это одна команда в любом из проектов, но есть полезный быстрый путь. И Coolify, и Dokploy доступны как развёртывания в один клик в наш маркетплейс, с предустановленными Ubuntu 24.04 и Docker и уже доступной панелью управления. Если хотите пропустить ручную настройку, листинги на маркетплейсе для Coolify и Dokploy — самый быстрый путь. Если вы предпочитаете начать с чистой ОС и запустить официальный установщик самостоятельно, оба проекта публикуют однострочный скрипт; выбирайте тот, что подходит вашему процессу подготовки.
Часто задаваемые вопросы
Остаётся ли Dokploy open source после смены лицензии в 2026 году?
Да, для основной платформы. С January 21, 2026 ядро Dokploy — это стандартный Apache 2.0. Отдельная Dokploy Source Available License теперь регулирует код в proprietary/ директориях, в данный момент ограниченный будущими корпоративными функциями (SSO/SAML, гранулярный RBAC, журналы аудита, white-labeling). Для соло- и небольших командных self-hosted-сценариев Dokploy функционально является open source.
Остаются ли уязвимости безопасности Coolify января 2026 поводом для беспокойства?
11 раскрытых CVE исправлены в Coolify v4.0.0 (выпущен April 27, 2026). Если вы работаете на v4.0.0 или новее, раскрытые уязвимости закрыты. Остаётся вопрос доступа: держите Coolify обновлённым и не выставляйте панель управления в публичный интернет. Привяжите её к приватной сети или спрячьте за VPN.
