Что Dokku и Coolify делают правильно
Сначала — признание заслуг, потому что они есть. Dokku дистиллировал ключевой цикл Heroku — git push, сборка на глазах, приложение работает — в односерверный инструмент, надёжный уже десятилетие. Coolify обернул ту же идею в по-настоящему приятный интерфейс с базами данных в один клик и растущей библиотекой шаблонов. Оба поддерживают TLS, оба понимают Dockerfile, и оба работают на железе, которое вы полностью контролируете, — а это важно, когда данные должны оставаться на месте или когда VPS с фиксированной ценой — это весь бюджет.
Если вы сегодня довольны одним из них, ничто ниже не доказывает, что вы ошиблись. Вопрос этого руководства уже и проявляется только со временем: кто эксплуатирует платформу под вашей платформой — и по-прежнему ли это лучшее применение ваших часов?
Строка, которой нет в README: вы — команда платформы
Self-hosted PaaS — это программа, которую вы запускаете на сервере, который вы обслуживаете. Два слоя, оба ваши. Серверу нужны патчи безопасности ОС, харденинг SSH и диск, который тихо заполняется Docker-образами и кешами сборки, пока утренние деплои не начнут падать с «no space left on device» — классический инцидент Dokku, и момент он всегда выбирает сам. Самому PaaS нужны обновления, к которым вы читаете changelog, потому что он стоит между вашим кодом и продакшеном, и ломающее изменение там И ЕСТЬ изменение продакшена.
Дальше вопросы острее. Бэкапы: базы данных, которые ваш PaaS создал в один клик, — кто делает их дампы, куда дампы попадают и когда кто-нибудь в последний раз проверял восстановление? Высокая доступность: один сервер означает, что перезагрузка хоста кладёт все приложения разом. Ничего экзотического в этой работе нет. Это полставки платформенного инженера, которые незаметно пришли вместе со скриптом установки и оплачиваются вашими вечерами.
Тот же цикл, но эксплуатируемый за вас
Рабочий процесс, который вам на самом деле нравится, — это push-to-deploy, и не его вам пришлось бы отдавать. На cdn.com.tr GitHub Deploy подключает репозиторий и превращает push в деплой: платформа забирает ветку, собирает ваш Dockerfile в изолированном сборщике (аккаунт в реестре не нужен), выполняет описанные вами шаги и выкатывает релиз за healthcheck — трафик переходит на новый контейнер, только когда тот сообщает о готовности, поэтому сломанная сборка никогда не кладёт сайт. Edge-кеш спереди автоматически очищается при деплое.
Меняется то, кому звонят. Патчи хоста, обновления сборщика, диск и доступность самой платформы перестают быть вашей стороной стола. Управляемые Postgres и Redis заменяют контейнеры «в один клик» базами данных, которые эксплуатируются и бэкапятся как сервис, а S3-совместимое объектное хранилище заменяет паттерн «том на этом сервере» для загрузок. Честная плата, как и всегда: нет root на хосте, нет установок на уровне ОС, публичный трафик — только HTTP(S). Ваш Dockerfile — это контракт, и он же держит дверь открытой на выход.
Как это выглядит со стороны панели
Пользователям Coolify форма покажется особенно знакомой: приложения с доменами, переменные окружения и секреты, логи, читаемые без SSH, и базы данных, привязанные к приложениям, — минус страницы настроек сервера, потому что вашего сервера под этим нет. Контейнерные приложения несут healthcheck, число реплик и постоянное хранилище как полноценные настройки, и всё, что есть на экране, доступно и в скриптах через тот же CLI — так что интерфейс это лишь окно в платформу, а не единственная дверь в неё.
Всё, что есть в панели, доступно и через CLI
# see your apps and read logs without SSH
cdnctl container apps list --account <uuid>
cdnctl container apps logs --account <uuid> --app <app_uuid> --tail 100
# scale, restart, roll back — the operations you actually reach for
cdnctl container apps scale --account <uuid> --app <app_uuid> --replicas 2
cdnctl container apps restart --account <uuid> --app <app_uuid>
cdnctl container apps rollback --account <uuid> --app <app_uuid> --revision <revision_uuid>Миграция: меньше, чем вы думаете
Ваше приложение уже живёт в Git, и под Dokku или Coolify оно уже собирается из Dockerfile или собираемой структуры — а значит, трудная часть миграции произошла давно. Переезд — это перенаправление того, куда идёт push, плюс проход по данным.
Подключите репозиторий к GitHub Deploy (или, если приложение описано в docker-compose.yml, импортируйте его: сервисы с секцией `build:` собираются из своих Dockerfile, базы данных становятся управляемыми дополнениями). Восстановите переменные окружения и секреты. Перенесите данные: сделайте дамп базы и восстановите его в управляемую, скопируйте загруженные файлы в объектное хранилище. Несколько дней держите обе платформы параллельно — старый сервер продолжает обслуживать, пока вы проверяете новый деплой, — затем переключите DNS и выведите машину из эксплуатации в удобном вам темпе.
Приложение, описанное в compose: посмотрите план, затем примените его
# see exactly what your compose file becomes — nothing is created yet
cdnctl container compose preview --account <uuid> --file docker-compose.yml
# apply when the plan looks right
cdnctl container compose apply --account <uuid> --file docker-compose.yml
# data: dump on the old box, restore into the managed database
pg_dump -Fc appdb > appdb.dump
pg_restore -d "$MANAGED_DATABASE_URL" appdb.dump
# uploads: from the old server's volume into object storage
aws --endpoint-url https://s3.cdn.com.tr s3 sync ./uploads s3://app-uploadsКогда стоит остаться на self-hosted
Симметрия требует этого раздела. Оставьте Dokku или Coolify, когда сервер вам действительно ничего не стоит — homelab, железо, которым вы уже владеете и которым нравится управлять. Оставьте, когда локальность данных — жёсткое требование и машина должна быть вашей. Оставьте, когда эксплуатационная работа и есть цель: содержать собственную платформу — один из лучших способов освоить всю эту область. И оставьте, когда вам нужно то, что управляемая сделка исключает: root, «сырые» TCP-порты, экзотические системные зависимости, которым не место в образе контейнера.
Если ничто из этого не про вас — если платформа под вашими приложениями скорее обуза, чем хобби или требование, — то любимый рабочий процесс переносим, а дежурство опционально.
Часто задаваемые вопросы
Потеряю ли я рабочий процесс git-push, уйдя с Dokku?
Нет — этот рабочий процесс здесь и есть продукт. GitHub Deploy превращает push в цикл «забрать — собрать — выпустить» с воротами healthcheck, а Docker Compose Instant Deploy покрывает многосервисные приложения. Что вы перестаёте делать — так это эксплуатировать машину, на которой это всё крутится.
Моё приложение на Dokku использует buildpacks, а не Dockerfile. Оно сможет переехать?
Да, с одним небольшим шагом: добавьте Dockerfile. Для большинства buildpack-приложений это горстка строк (базовый образ, копирование, установка, команда запуска), и она делает приложение переносимым на любую контейнерную платформу — включая эту. Это стоит сделать, даже если вы останетесь на Dokku.
Что заменяет базы данных «в один клик» из Coolify?
Управляемые дополнения Postgres и Redis — привязанные к вашим приложениям так же, но эксплуатируемые и бэкапируемые как сервис, а не работающие контейнерами, диск и дампы которых — ваша ответственность.
Можно ли мигрировать постепенно, а не одним переключением?
Да, и именно так и стоит: разверните на управляемой платформе, пока старый сервер продолжает обслуживать продакшен, проверьте на реальной сборке, заранее синхронизируйте данные и переносите DNS, когда будете довольны. Старая машина — отличный план отката, пока вы её не выключите.