Деплой до того как нужен Kubernetes.
docker compose, только для прода — git-aware, мультихост, по SSH. Build, push, pull, restart — по порядку, только то что поменялось. Один бинарь, один конфиг, никакого кластера.
Знакомо?
Три сервиса на одной VPS. Чтобы задеплоить — SSH, git pull, пересобрать образ, docker compose up -d, потом таращиться в логи и надеяться что новый образ действительно поднялся. Каждый раз.
kb-deploy run. Образы собраны, запушены, вытянуты, перезапущены — по порядку, с проверкой health на каждом шаге.
Поменяли один сервис, а скрипт пересобирает все. Двухминутная правка превращается в пятнадцатиминутный деплой. Либо пересобирается ничего — и в прод уезжает не тот SHA.
kb-deploy сравнивает с git и трогает только те цели, которые действительно поменялись. Остальное не перезапускается.
Половина инфры — база, кеш, брокер — живёт отдельно от приложения. Никто ими не управляет вместе. Поднимаете их ad-hoc compose-файлами, которые потом никто не поддерживает.
kb-deploy infra up поднимает stateful-слой из того же deploy.yaml. Один файл, идемпотентно, без drift.
Знаете docker compose — уже знаете kb-deploy.
Та же ментальная модель, та же форма YAML, тот же ритм up/down — только расширенный тем, что compose намеренно не делает.
Один файл. Приложения и инфра вместе.
Положите .kb/deploy.yaml в репозиторий. kb-deploy прочитает и решит что собрать, что запушить и что перезапустить — по SSH, на целевом хосте.
Этот же файл потом читает kb-monitor. Деплой и наблюдение — из одного источника правды.
registry: ghcr.io/your-org
targets:
api:
path: apps/api
dockerfile: Dockerfile
host: prod-1
compose: infra/compose/api.yml
health: http://localhost:3000/health
web:
path: apps/web
host: prod-1
compose: infra/compose/web.yml
infrastructure:
postgres:
host: prod-1
image: postgres:16
volumes:
- /data/postgres:/var/lib/postgresql/data
redis:
host: prod-1
image: redis:7Как это работает
То, что важно когда деплой становится рутиной.
Раскатывает только то, что изменилось
Затронутые цели определяются по git diff против последнего задеплоенного SHA. Ничего лишнего не пересобирается.
Собирает, пушит, вытягивает, перезапускает — по порядку
Сборка локально или в CI, push в registry, pull на хосте, docker compose up. Каждый шаг проверяется до начала следующего.
Помнит последний SHA для каждой цели
status показывает что сейчас крутится в проде и насколько это разошлось с HEAD в репозитории.
Управляет stateful-инфрой рядом с приложениями
Базы, кеши, брокеры — объявляются в том же deploy.yaml, поднимаются через infra up, идемпотентно, без дублей.
SSH-first, без cloud-аккаунтов
Работает по обычному SSH с docker compose на хосте. Любой VPS подойдёт. Без вендоров, API-токенов и отдельного control plane.
Все команды удобны для скриптов
У каждой команды есть --json со структурированным выводом. Подходит для CI, Makefile и агентных workflow. У ошибок есть подсказки.
Команды
Все команды поддерживают --json — для скриптов и агентных workflow.
kb-deploy runСобрать и раскатать затронутые цели (git diff против последнего SHA).
kb-deploy run --allПолный деплой всех целей, вне зависимости от git.
kb-deploy run kb-labs-webРаскатать конкретную цель по имени. Удобно для хотфиксов.
kb-deploy statusПоказать последний задеплоенный SHA для каждой цели и насколько он отстал от HEAD.
kb-deploy listСписок целей из .kb/deploy.yaml — с compose-файлами и хостами.
kb-deploy infra upПоднять stateful-инфру из infrastructure. Идемпотентно: работающие сервисы пропускаются.
kb-deploy infra statusСостояние stateful-сервисов на хосте.
kb-deploy infra down <name>Остановить и удалить конкретный infra-сервис. Тома сохраняются, если явно не попросить иначе.
Скачать
Готовые бинарники для macOS, Linux и Windows. SHA-256 есть в каждом релизе.
Часть KB Labs
kb-deploy есть как отдельный бинарь и как часть платформы KB Labs. Ставите KB Labs — kb-deploy уже внутри.
Установить KB Labs →