Когда слышишь «контейнеры в проде», рука тянется к Kubernetes. Но для многих проектов это слишком тяжёлая артиллерия: дорого по времени, сложно по операционным рискам, а профит появляется только при масштабе и зрелых процессах. На практике вебмастера и DevOps часто хотят другое: быстро и предсказуемо деплоить на VDS, иметь что-то похожее на PaaS, и при этом не строить полноценный кластер.
В этой статье разберём три популярных варианта «не-Kubernetes» деплоя: Kamal, Dokku и CapRover. Все они используют Docker, но отличаются философией: Kamal — это deploy tool (условно «современный Capistrano для контейнеров»), Dokku — минималистичный PaaS на одном сервере, CapRover — PaaS с панелью и готовыми шаблонами приложений.
Я буду говорить языком практики: что выбрать под ваши задачи, какие требования к серверу, как устроен zero downtime, где будут боль и грабли, и как не потерять данные.
Контекст: что заменяем и что хотим получить
Если упростить, Kubernetes решает три крупных задачи: оркестрация (куда и как запускать), сетевое взаимодействие (service discovery, ingress), и управление жизненным циклом (rolling update, healthchecks, autoscaling).
Когда мы выбираем Kamal/Dokku/CapRover, мы почти всегда целимся в сценарий:
- 1–2 сервера (иногда 3–5), без выделенной платформенной команды;
- несколько сервисов: веб-приложение + воркеры + очередь + БД (часто отдельно);
- регулярный deploy из Git/CI и быстрый откат;
- простая маршрутизация доменов, TLS, логи;
- минимально возможный даунтайм, в идеале почти zero downtime для API и фронта.
Важно: «zero downtime» почти никогда не получается «одной галочкой». Если релиз включает миграции БД, смену схемы, пересборку кешей или прогрев — придётся проектировать обновление так, чтобы старая и новая версия какое-то время жили вместе (backward-compatible migrations).
Kamal: деплой контейнеров по SSH без PaaS-магии
Kamal (его часто помнят как mrsk) — инструмент, который берёт Docker-образ, по SSH раскладывает его на сервер(а), поднимает контейнеры и переключает трафик через прокси/балансировщик. Концептуально это «инфраструктура как код», но без кластера и без отдельной PaaS-платформы.
Как Kamal устроен (упрощённо)
- Сборка образа локально или в CI.
- Пуш образа в registry (частный или публичный).
- SSH-доступ к серверам и установленный Docker.
- Запуск контейнеров приложения и аксессуаров (например, Redis) по декларативному конфигу.
- Rolling update: замена контейнеров с ожиданием готовности.
Плюс Kamal — минимальная «платформа» на сервере и высокая прозрачность. Минус — меньше готовых интеграций «из коробки» в стиле PaaS: сетевые правила, бэкапы, секреты и часть автоматизации придётся выстроить самому.
Zero downtime в Kamal: где реально работает
Чаще всего обновление выглядит так: поднять новый контейнер → дождаться «готов» → переключить прокси → остановить старый. Для веб-слоя это даёт очень приличный результат, если приложение умеет стартовать предсказуемо и корректно отдаёт сигнал готовности (readiness).
Типовые причины даунтайма при деплое с Kamal:
- долгий старт приложения (прогрев кеша, миграции в процессе старта);
- неверный healthcheck (контейнер «жив», а приложение ещё не готово);
- миграции БД, которые блокируют таблицы или ломают обратную совместимость;
- один сервер без запаса ресурсов: во время релиза живут старая и новая версия, а памяти/CPU не хватает.
Чтобы лучше представить механику «поднять новую версию и переключить трафик», держите в голове схему rolling update и проверки готовности.
Когда Kamal — лучший выбор
- Вы хотите управлять деплоем как кодом и не держать панель/платформу.
- У вас 1–5 серверов и понятная топология.
- Есть CI/CD, сборка образов и дисциплина по миграциям.
- Нужно предсказуемо делать rolling update без Kubernetes.
Dokku: минималистичный PaaS на одном сервере
Dokku часто описывают как «мини-Heroku, который вы хостите сами». Он хорошо ложится на VDS, потому что его сильная сторона — быстрый PaaS-опыт: git push → build → deploy, плюс плагины для аддонов (в зависимости от выбранной экосистемы плагинов).
Что Dokku даёт вебмастеру/DevOps
- Управление приложениями, доменами и прокси через команды Dokku.
- Buildpacks или Dockerfile (в зависимости от подхода).
- Переменные окружения, логи, перезапуски, простые «процессы» (web/worker).
- Аддоны через плагины (Postgres/Redis и т.д.) с понятным lifecycle.
Dokku выигрывает там, где нужен «PaaS-процесс» без написания большого количества инфраструктурного кода. Но помните: это дополнительный слой на сервере, и его нужно обновлять, бэкапить и мониторить как отдельный компонент.
Zero downtime в Dokku: нюансы
В Dokku многое зависит от прокси и режима деплоя. В простых случаях можно добиться обновления без заметной паузы, но есть ограничения:
- если приложение одноинстансное и происходит замена контейнера, возможен короткий разрыв;
- если есть несколько инстансов и прокси переключает трафик только на живые, даунтайм можно сильно уменьшить;
- на слабой VDS сборка/релиз могут съедать ресурсы и вызывать деградацию.
Практический совет: отделяйте сборку от запуска. Сборка образа в CI и деплой уже готового образа обычно стабильнее и быстрее, чем сборка на прод-сервере.
Когда Dokku — лучший выбор
- Нужен self-hosted PaaS на одном сервере для нескольких приложений.
- Важна скорость запуска проектов и привычный workflow «деплой одной командой».
- Команда небольшая: Kubernetes избыточен, но хочется стандартизировать окружение.
CapRover: PaaS с панелью, шаблонами и быстрым стартом
CapRover любят за простой вход: ставите на сервер, открываете админку, выбираете шаблон (Node.js/PHP/Dockerfile/готовые one-click apps), цепляете домен и получаете рабочее приложение. Он тоже построен на Docker и управляет публикацией через reverse proxy.
Сильные стороны CapRover
- Панель управления: удобно, когда не хочется всё делать в CLI.
- Готовые one-click apps и шаблоны.
- Быстрое подключение доменов и маршрутизация.
- Порог входа ниже, чем у инструментов «только для DevOps».
Слабые стороны и риски
- Панель — дополнительная поверхность атаки: следите за доступом, обновлениями и журналированием.
- С ростом проекта чаще требуется строгая дисциплина по секретам, сетям и разделению сервисов.
- Нестандартные сценарии деплоя иногда проще реализовать «в лоб» с Kamal, чем вписывать в GUI-логику.
Zero downtime в CapRover
Зависит от схемы публикации: сколько реплик, как настроены healthchecks, как происходит переключение. Для типичных веб-приложений можно добиться обновления без заметной паузы, если приложение стартует быстро, а прокси даёт трафик только «готовым» инстансам.
Сравнение: Kamal vs Dokku vs CapRover (практический взгляд)
Ниже — не «таблица маркетинга», а то, что реально влияет на эксплуатацию и восстановление после сбоев.
1) Модель управления
- Kamal: конфиг + команды, фокус на прозрачности и повторяемости; минимум серверного «состояния платформы».
- Dokku: PaaS-слой с командами и плагинами; workflow ближе к Heroku.
- CapRover: PaaS с GUI; удобно для быстрых запусков и для команд смешанной квалификации.
2) Операционные риски
- Kamal: меньше «магии», проще переносить и воспроизводить; больше ответственности за registry, секреты, бэкапы и мониторинг.
- Dokku/CapRover: платформа хранит больше настроек и логики; критично понимать, как бэкапить и восстанавливать сам PaaS-слой.
3) Масштабирование
- Kamal: естественно раскладывается на несколько хостов, если вы готовы управлять ролями и топологией.
- Dokku: в первую очередь про один сервер; дальше начинаются компромиссы и надстройки.
- CapRover: чаще single-server; расширение возможно, но быстро растёт сложность.
4) Обновления без простоя
- Kamal: сильная сторона — контролируемый rolling update при корректных healthchecks и наличии ресурсов.
- Dokku: может быть близко к zero downtime, но зависит от режима деплоя и архитектуры приложения.
- CapRover: даёт плавные обновления в типовых веб-сценариях при дисциплине readiness/liveness.
Требования к VDS: что важно для любого подхода
Инструмент деплоя — вторично, если сервер подобран «впритык». Большинство проблем, которые ошибочно списывают на Kamal/Dokku/CapRover, упираются в ресурсы, диск и сеть.
Если сомневаетесь в sizing, держите под рукой отдельный ориентир по подбору ресурсов: как выбрать VDS по CPU и RAM под нагрузку.
CPU/RAM: запас на двойной запуск
Для обновления без заметного простоя нужен запас: во время релиза одновременно живут старая и новая версия (плюс прокси и фоновые сервисы). Практичное правило: держите 30–50% свободной RAM в обычном режиме, иначе rolling update превращается в OOM и рестарты.
Диск и I/O
Docker-образы, логи, volume’ы и базы быстро съедают место. Добавьте сборку образов на сервере — и получите внезапные просадки по I/O. Практика:
- Ограничивайте и ротируйте логи контейнеров (чтобы не «съели» диск за ночь).
- Не храните бэкапы рядом с прод-данными в одном разделе без контроля квот и заполнения.
- Отделяйте данные БД от «одноразовых» артефактов сборки и временных файлов.
Сеть, порты и reverse proxy
Все три решения строятся вокруг reverse proxy (по роли это Nginx/Traefik-класс). Типовой набор проблем:
- конфликт портов (80/443 заняты другим сервисом);
- неверный проброс
X-Forwarded-Protoи проблемы с генерацией HTTPS-URL; - не настроены таймауты, из-за чего long requests рвутся на прокси;
- WebSocket/HTTP2 «не взлетели», потому что оставили дефолтные настройки.
Секреты, переменные окружения и доступы
В PaaS-инструментах удобно задавать переменные окружения, но важнее понимать жизненный цикл секретов: кто может читать, где хранятся, как ротируются, как попадают в CI/CD.
Минимальный практический стандарт для VDS:
- минимум прав для SSH-ключей и пользователей; отдельный пользователь под деплой;
- секреты не коммитим в репозиторий и не дублируем в чатах/тикетах;
- есть процедура ротации: токены registry, ключи API, пароли БД;
- в логах деплоя не должно «утекать» содержимое переменных.
Если вы реально целитесь в zero downtime, относитесь к секретам как к части релиза: смена ключа должна проходить так, чтобы старая и новая версия могли некоторое время работать параллельно.
Данные и бэкапы: граница между «просто деплой» и продом
Контейнеры — одноразовые. Данные — нет. Поэтому при выборе Kamal/Dokku/CapRover задайте себе вопрос: как именно я восстановлюсь после потери сервера?
Практический чеклист:
- БД (PostgreSQL/MySQL) — отдельный план бэкапов и регулярная проверка восстановления.
- Файлы пользователя (uploads) — отдельные volume’ы и их резервное копирование.
- Конфиги платформы (Dokku/CapRover) — экспорт/бэкап настроек, чтобы можно было развернуть заново.
- Образы — обычно пересобираемы, но registry должен быть доступен или воспроизводим.
Если у вас PostgreSQL на том же сервере или отдельным инстансом, полезно иметь «план Б» по обслуживанию: тюнинг PostgreSQL: autovacuum и индексы без сюрпризов.
Практичный выбор инструмента под типичный проект
Ниже — сценарии, которые чаще всего встречаются при деплое на одной или нескольких VDS.
Сценарий A: один сервис + один воркер, нужна максимальная прозрачность
Берите Kamal. Он хорошо ложится на «деплой как код», позволяет аккуратно обновляться и не тянет за собой PaaS-платформу. Заранее продумайте registry и схему хранения секретов.
Сценарий B: много небольших приложений, хочется «как Heroku»
Берите Dokku. Он удобен, если у вас несколько проектов и вы хотите единый способ деплоя и управления доменами/переменными без большого количества обвязки.
Сценарий C: нужна панель, шаблоны, быстрый запуск MVP
Берите CapRover. Подходит, когда нужно быстро поднять сервис на Docker, подключить домен и получить понятную схему релизов. Но не забывайте про обновления панели и ограничения доступа (вплоть до VPN/allowlist).
Перед релизом полезно быстро проверить, не упираетесь ли вы в ресурсы и диск — это частая причина «внезапных» проблем с деплоем на одиночной VDS.
Типовые ошибки при переходе «с Kubernetes в голове» на VDS-PaaS
- Ожидать autoscaling. На одном сервере масштабирование чаще вертикальное; горизонтальное возможно, но уже требует архитектуры.
- Смешивать прод и сборку. Сборка образов на прод-VDS — частая причина деградаций.
- Хранить БД в том же стеке без бэкапов. Контейнеризированная БД без дисциплины резервирования — путь к потере данных.
- Игнорировать healthchecks. Без корректных проверок готовности «zero downtime» превращается в «zero predictability».
- Не иметь плана отката. Откат — это не только «вернуть старый контейнер», но и совместимость схемы БД.
Мини-эталон: что должно быть настроено, чтобы деплой был «как прод»
Если вы хотите, чтобы Kamal/Dokku/CapRover давали стабильный деплой на VDS, ориентируйтесь на следующий минимум:
- отдельный пользователь и ключи для деплоя, закрытый SSH, аудит доступа;
- reverse proxy с понятной схемой доменов и TLS; при необходимости покупка и установка SSL-сертификаты;
- healthchecks и понятный сигнал готовности приложения;
- логирование с ротацией и алертами по заполнению диска;
- бэкапы данных и регулярная проверка восстановления;
- план релизов: backward-compatible миграции и поэтапное включение фич;
- запас ресурсов на rolling update (CPU/RAM).
Итоги
Kubernetes остаётся сильным решением, когда нужна настоящая оркестрация, много нод, сложная сеть, autoscaling и платформенная стандартизация. Но для большой доли проектов на VDS он избыточен.
Kamal — про инженерный deploy и контроль; Dokku — про минималистичный PaaS в стиле Heroku; CapRover — про панель и быстрый старт. Если вы правильно спроектируете релизы (особенно миграции) и заложите запас ресурсов, все три подхода дадут стабильный деплой и очень близкий к zero downtime опыт без Kubernetes.
Команды для быстрой самопроверки перед релизом
Небольшой набор проверок, который полезен независимо от выбранного инструмента (выполняйте на сервере перед крупным релизом):
docker ps
docker system df
df -h
free -h
uptime
ss -lntp
Эти команды не лечат проблемы, но быстро показывают типовую причину «почему релиз внезапно стал падать»: кончился диск, нет памяти на двойной запуск, или 80/443 уже заняты.
