Хватит жонглировать вкладками терминала.
Один бинарник, который запускает сервисы в правильном порядке, ждёт пока они реально поднимутся, и нормально останавливает всё при выходе.
Знакомо.
Postgres в одной вкладке, Redis в другой, API в третьей. Закрыл ноутбук, открыл — ничего не работает. Пять минут разбираешься, что перезапускать и в каком порядке.
kb-dev start. Одна команда. Всё поднимается в правильном порядке.
Запускаешь сервис — "address already in use". Что-то держит порт 3000. Делаешь ps aux | grep node и вглядываешься в список процессов, пытаясь угадать, который из них.
kb-dev doctor скажет, что именно держит порт, и даст команду, чтобы это исправить.
Запускаешь make dev, всё выглядит запущенным, но API сразу падает — postgres ещё не был готов. Перезапускаешь. Иногда работает, иногда нет.
kb-dev ждёт, пока health check пройдёт, прежде чем запустить то, что от него зависит. Никаких гонок.
Один файл, любой проект.
Положите devservices.yaml в корень проекта. kb-dev найдёт его автоматически, поднимаясь по директориям от текущей.
Проекты KB Labs используют .kb/devservices.yaml — тот же формат, другое место.
name: my-project
services:
postgres:
type: docker
command: docker run --rm -p 5432:5432 postgres:16
health_check: http://localhost:5432
port: 5432
api:
command: pnpm dev
port: 3000
health_check: http://localhost:3000/health
depends_on: [postgres]
worker:
command: pnpm worker
depends_on: [postgres]Как это работает
Детали, которые важны, когда боль уже знакома.
Знает, когда сервис реально умер
Отслеживает настоящий PID, потому что сам запустил процесс. Никаких сканирований портов, никакого устаревшего состояния.
Не называет его alive, пока он реально не ответит
HTTP, TCP и командные health-пробы с замером latency. Статус alive — только после того, как проверка прошла.
Запускает postgres раньше того, кому он нужен
Топологическая сортировка сервисов. Параллельный запуск в пределах слоя, правильный порядок гарантирован.
Поднимает снова, пока ты не смотришь на терминал
Watchdog с экспоненциальным backoff. Упавший сервис перезапускается автоматически, до 5 попыток.
Останавливает всё дерево, а не только родителя
Убивает группу процессов целиком. Никаких зависших дочерних процессов после остановки.
Каждая команда поддаётся автоматизации
Каждая команда отдаёт структурированный JSON с полем ok. Ошибки содержат hint с точной командой для исправления. Работает в CI, Makefile и агентных сценариях.
Команды
Все команды поддерживают --json для скриптов и агентных сценариев.
kb-dev startЗапустить все сервисы в порядке зависимостей. Укажите группу или имя сервиса для точечного запуска.
kb-dev stopОстановить сервисы. --cascade останавливает также всё, что зависит от цели.
kb-dev statusТаблица статусов с latency health-пробы. --json возвращает структурированный вывод с depsState.
kb-dev ensure api workerИдемпотентное приведение к состоянию: живые сервисы пропускаются, мёртвые запускаются.
kb-dev ready api --timeout 30sБлокировать до тех пор, пока сервис не станет alive. Используйте как gate в CI или агентных сценариях.
kb-dev logs api --followСтримить живые логи сервиса. Без --follow — последние 50 строк.
kb-dev doctorПроверить окружение: node, docker, конфликты портов. Возвращает подсказки для каждой проблемы.
kb-dev watch --jsonСтримить события жизненного цикла как JSONL: health, crashed, restarting, alive.
Скачать
Готовые бинарники для macOS, Linux и Windows. SHA-256 чексуммы включены в каждый релиз.
Часть KB Labs
kb-dev поставляется как самостоятельный инструмент и как часть платформы KB Labs. При установке KB Labs kb-dev включается автоматически.
Установить KB Labs →