# Сборка без Dockerfile

> Как платформа определяет язык, зависимости и команду запуска, и что делать, если сборка не прошла.

Раздел: Деплой
Источник: https://nodbox.ru/docs/deploy/build/

---
Платформа собирает приложение без Dockerfile: она читает файлы проекта, сама определяет язык, зависимости и команду запуска и превращает исходники в образ. Если сборка не прошла, версия получает причину отказа, а работающая версия продолжает отвечать.

## Как платформа определяет язык

Язык определяется по файлам в корне сборки. Ничего настраивать не нужно: ни конфига, ни пометок в репозитории.

| Файл в корне | Что собирается |
| --- | --- |
| `package.json` | приложение на Node.js |
| `requirements.txt` или `pyproject.toml` | приложение на Python |
| `go.mod` | приложение на Go |
| `index.html` | статический сайт |

Node.js, Python и Go проверены на реальных приложениях. Статический сайт из `index.html` тоже собирается. Другие языки платформа пробует определить сама, но на реальных приложениях они не проверены, поэтому здесь не обещаны. Если язык не определился, версия получает причину `language_not_detected`, и тогда помогает свой Dockerfile.

Версию рантайма и команду запуска платформа тоже выбирает по содержимому проекта. Если выбрано не то, команды и версии задаются вручную: это разобрано на странице [Настройки сборки и свой Dockerfile](/docs/deploy/build-settings/).

## Этапы деплоя

Деплой идёт по порядку: код, сборка, публикация образа, выкат. Панель показывает текущий этап словами из таблицы.

| Этап | Что происходит | Как называется в панели |
| --- | --- | --- |
| Код | Платформа клонирует выбранную ветку или разбирает архив, проверяет файлы и сохраняет снимок исходников | В очереди, Код загружается, Код получен |
| Сборка | Платформа определяет язык и собирает образ | Образ собирается |
| Публикация | Готовый образ загружается в реестр платформы и подписывается | Образ публикуется, Образ собран |
| Выкат | Платформа запускает приложение из образа и ждёт, пока оно ответит на своём порту | Деплоится |
| Готово | Версия принимает запросы на адресе приложения | Работает |

Версия из готового образа проходит только выкат: собирать ей нечего. Так же выкатывается запуск после остановки, он берёт образ прежней работавшей версии. Откуда берётся код, разобрано на странице [Источники кода](/docs/deploy/sources/).

## Время, сеть, кэш и деньги

- **Время.** На сборку отведено до 16 минут, на весь деплой от заказа версии до готовности - до 48. Сборка, которая не уложилась, останавливается с причиной `build_timeout`.
- **Очередь.** Если мощностей для сборки сейчас не хватает, она ждёт своей очереди. Лог сборки в это время пуст: он открывается, когда сборка началась.
- **Песочница.** Каждая сборка идёт в отдельной изолированной среде. Скрипты установки зависимостей и шаги Dockerfile исполняются там, а не на общей машине, и чужие сборки из неё не видны.
- **Сеть.** Сборка выходит в интернет без ограничений по портам и протоколам: зависимости, git-пакеты и файлы из шагов сборки скачиваются как обычно. Внутренняя сеть платформы из неё закрыта.
- **Кэш.** Кэша между сборками нет, каждая сборка начинается с чистого листа. Повторный деплой тех же исходников не быстрее первого. Исключение - публичные базовые образы: копия лежит рядом со сборкой, и скачиваются они быстро.
- **Деньги.** Сборка не тарифицируется: плата начинается с подтверждённого выката. Упавшая сборка ничего не стоит.
- **Работающая версия.** Пока собирается новая версия, прежняя отвечает на запросы. Упавшая сборка её не трогает: неудачная версия остаётся в истории с причиной, а работающая остаётся работающей.

На замерах платформы холодная сборка приложений на Node.js и Vite занимала от трёх до пяти минут. Тяжёлые деревья зависимостей идут дольше, поэтому потолок в 16 минут оставляет запас.

Временные сбои платформа переживает сама: недоступная сеть при скачивании рантайма или перегруженный реестр базовых образов не роняют деплой с первой попытки. Тогда в логе стоит строка «Причина временная: платформа повторит сборку».

Идущий деплой можно отменить, это описано на странице [Версии и откат](/docs/deploy/versions/).

## Dockerfile в корне

Если в корне сборки лежит файл с именем `Dockerfile`, платформа собирает образ по нему. Режим выбора называется `auto`, он включён по умолчанию. В логе сборки об этом стоит строка «В корне сборки найден Dockerfile - образ собирается по нему.»

Команды сборки и запуска и версии рантайма при этом не применяются: всё записано в самом Dockerfile. Собрать без него, даже если он лежит в репозитории, можно через настройки, они разобраны на странице [Настройки сборки и свой Dockerfile](/docs/deploy/build-settings/).

## Как понять, что язык определён не так

Первый признак стоит в логе сборки. Строка «План сборки составлен» называет распознанные языки и версии рантайма: сверь их с тем, что ты ожидал. Лог читается на странице [Лог сборки](/docs/observability/build-log/).

Типичные случаи:

- **В корне нет файлов проекта.** Так бывает в монорепозитории: приложение лежит в папке `apps/web`, а в корне только общий конфиг. Версия получает `language_not_detected`. Нужно указать корневую папку приложения в настройках сборки.
- **В корне лежит Dockerfile для локальной разработки.** Платформа собирает по нему, хотя ты рассчитывал на автоопределение. Строка про найденный Dockerfile в логе подскажет это сразу.
- **Сборка прошла, но приложение не запустилось.** Скорее всего, команда запуска определена не та или приложение слушает не тот порт. Версия получает `container_exited` или `port_unreachable`, и объяснение лежит в логе приложения.
- **Сборке нужна переменная.** Переменные и секреты приложения сборке не видны, у сборки свои. Они задаются в настройках сборки.

## Причины отказа версии

Если версия не выкатилась, в ней записана причина, а панель называет её словами. Кнопка в сообщении о провале открывает нужный лог: лог сборки, если версия упала до выката, и лог приложения, если после.

Причины сборки объясняет последняя строка лога сборки:

| Причина | Что случилось | Что делать |
| --- | --- | --- |
| `language_not_detected` | в корне сборки нет знакомых файлов: `package.json`, `requirements.txt`, `go.mod` и других | положить проект в корень, указать корневую папку или добавить Dockerfile |
| `build_failed` | шаг сборки завершился ошибкой: не встали зависимости, не прошла команда сборки, не нашлась команда запуска | прочитать строки лога выше и проверить, что проект собирается локально |
| `build_timeout` | сборка не уложилась в 16 минут и остановлена | найти в логе шаг, на котором сборка замолчала |
| `dockerfile_missing` | выбрана сборка по Dockerfile, а файла в корне сборки нет | положить файл или вернуть автоматический выбор сборщика |
| `root_directory_missing` | корневой папки в исходниках версии нет | проверить путь в настройках сборки |
| `image_too_large` | собранный образ больше допустимого размера | убрать из образа лишнее, например то, что нужно только при разработке |
| `limit_exceeded` | исходники не помещаются в отведённое место | уменьшить проект, размеры названы в разделе [Лимиты и квоты](/docs/project/limits/) |
| `source_unavailable` | до кода не добраться: подключение отозвано, репозиторий или ветка не найдены | проверить подключение и ветку |
| `archive_invalid`, `archive_encrypted`, `compression_unsupported` | архив не разобрался | собрать архив заново, правила описаны в разделе «Проверка архива» страницы [Источники кода](/docs/deploy/sources/) |

Две причины говорят о сбое на стороне платформы, а не о твоём коде:

| Причина | Что случилось | Что делать |
| --- | --- | --- |
| `push_failed` | образ собран, но не лёг в реестр | заказать деплой ещё раз |
| `internal` | внутренний сбой платформы | заказать деплой ещё раз |

Три причины относятся к выкату, и сборка к этому времени уже закончилась, поэтому лог сборки их не объясняет:

| Причина | Что случилось | Что делать |
| --- | --- | --- |
| `container_exited` | процесс приложения запускался раз за разом и каждый раз завершался | прочитать [логи приложения](/docs/observability/logs/) |
| `out_of_memory` | приложению не хватило памяти его размера, и процесс остановлен | выбрать размер побольше, см. [Размеры приложения](/docs/apps/sizes/) |
| `port_unreachable` | процесс запустился и не ответил на своём порту | проверить порт, см. [Порт, протокол и проверка готовности](/docs/apps/runtime/) |

Письмо о провале деплоя приходит само, если оно включено в проекте: оно цитирует последние строки лога сборки либо отсылает к логу приложения. Настройка описана на странице [Уведомления](/docs/project/notifications/).

## Что дальше

- [Настройки сборки и свой Dockerfile](/docs/deploy/build-settings/) - команды, корневая папка, версия рантайма, переменные сборки
- [Лог сборки](/docs/observability/build-log/) - как читать вывод сборки по строкам
- [Версии и откат](/docs/deploy/versions/) - история версий, отмена деплоя и возврат на прежнюю
- [Источники кода](/docs/deploy/sources/) - репозиторий, архив и готовый образ
- [Типичные сбои и что делать](/docs/help/troubleshooting/) - куда смотреть, если что-то не заработало