Конвейер сборки

Сборки выполняются на узлах сборки Lizard — вам не нужен Docker локально. При развёртывании платформа по заданному порядку решает, как превратить ваш исходный код в образ контейнера, а затем запускает этот образ в изолированном поде. Не каждый контейнер как сервис собирает образ за вас; в блоге сравниваются три формы, в которых встречается эта категория.

Порядок выбора стратегии сборки

Платформа выбирает ровно одну стратегию сборки, в таком порядке:

Синтезированный Dockerfile — если на сервисе заданы buildCommand и/или startCommand (или переданы через lizard up --build-command / --start-command), Lizard генерирует Dockerfile из этих команд. lizardpack не вызывается.
Dockerfile из репозитория (как есть) — если на сервисе задан dockerfilePath, используется тот Dockerfile из вашего репозитория без изменений.
Автоопределение lizardpack — иначе платформа клонирует ваш исходный код и запускает lizardpack, свой генератор Dockerfile / buildpack.

Автоопределение lizardpack

lizardpack анализирует ваш репозиторий и собирает оптимизированный многостадийный образ. Поддерживаемые стеки, проверяемые в таком порядке:

Hugo → Go → Node → Python → Rust → Ruby → PHP → Java → static

См. Руководства по фреймворкам для продакшн-скриптов, адаптеров, путей вывода и портов. Определение использует файлы проекта и зависимости; репозиторий, подходящий под несколько провайдеров, следует этому порядку.

На этом пути:

Если в репозитории есть Dockerfile и в нём есть реальный шаг сборки (строка RUN <package-manager>, а не только COPY dist/), он используется как есть.
Иначе lizardpack генерирует Dockerfile за вас.
Команда запуска определяется автоматически: строка Procfile web: (Python/Ruby) или package.json scripts.start (Node) подхватывается автоматически. Для точной строки, которую хотят Django, Flask и FastAPI, см. Хостинг Python-приложений.
Порт выводится из EXPOSE, значений фреймворка по умолчанию или явной переменной окружения PORT.

Подвох: Dockerfile, который только копирует предварительно собранные артефакты (COPY dist/, build/, out/, .next/, public/) без шага сборки RUN, считается неполным и регенерируется lizardpack. Добавьте реальный шаг сборки или задайте dockerfilePath для принудительного использования как есть.

Что вызывает пересборку

Действие	Пересобирает?
`git push` в отслеживаемую ветку	✅ через вебхук GitHub
`lizard redeploy` / `lizard up`	✅ явно
Изменение переменных `VITE_` или `NEXT_PUBLIC_`	✅ значения времени сборки запекаются в образ
`service set` полей сборки (`repoUrl`, `branch`, `sourceType`, `buildCommand`, `dockerfilePath`, `rootDirectory`)	✅ автопересборка
`service set` полей только времени выполнения (`startCommand`, `preDeployCommand`, `containerPort`, `watchPatterns`)	❌ запустите `lizard redeploy` для применения
Любое другое изменение переменной окружения / секрета	❌ применяется при быстром перезапуске (без пересборки)

Не дублируйте сборку. После service set, меняющего поле сборки, пересборка запускается автоматически — не ставьте в цепочку lizard redeploy после этого, иначе поставите в очередь вторую избыточную сборку.

Наблюдение за сборкой

Логи сборки стримятся во время lizard up. Для любого сервиса:

lizard logs --build            # the most recent build's logs
lizard events                  # deploy history + replica status

Если сборка упала, прочитайте lizard logs --build, устраните причину (в репозитории или скорректировав buildCommand / startCommand через lizard service set), затем lizard redeploy.

Примечания к рантайму

Нет Docker HEALTHCHECK. Рантайм не запускает цикл healthcheck Docker, поэтому директивы HEALTHCHECK игнорируются. Lizard выполняет TCP-пробирование вашего порта вместо этого (пропускается в режиме воркера).
Не пишите Dockerfile без нужды. lizardpack автоопределяет большинство стеков — попробуйте сначала задеплоить, и добавляйте Dockerfile (или задавайте dockerfilePath) только если автосборка не подходит.

Справочник по конфигурации сборки

Поле	Описание
`buildCommand`	Команда сборки вашего приложения → принудительно использует путь синтезированного Dockerfile
`startCommand`	Команда запуска приложения во время выполнения
`preDeployCommand`	Выполняется один раз перед каждым деплоем (например, миграции БД)
`dockerfilePath`	Путь к Dockerfile в репозитории для использования как есть
`rootDirectory`	Поддиректория для сборки (монорепозитории)
`watchPatterns`	Передеплой только при изменении соответствующих путей
`containerPort`	TCP-порт, который слушает приложение (по умолчанию `3000`; `0` = воркер)

Любое из этих полей можно задать через lizard service set <svc> --set <field>=<value>. См. lizard service.

Архитектура Развёртывания