Build Settings

Настройки сборки определяют как ONREZA собирает и деплоит ваш проект.

Где найти настройки

Проект → Настройки → Сборка и развертывание

Основные настройки

Framework Preset

Выбранный фреймворк определяет значения по умолчанию для остальных настроек.

Auto-detected — ONREZA автоматически определил фреймворк
Override — вы вручную выбрали другой фреймворк

Build Command

Команда для сборки проекта.

Значение по умолчанию: npm run build

Примеры:

npm run build
yarn build
pnpm run build
bun run build
next build && next export

Override:

Если поле пустое — используется значение по умолчанию для фреймворка
Если заполнено — используется ваше значение

Output Directory

Папка с результатом сборки, которая будет развёрнута.

Примеры по фреймворкам:

Next.js (static): out
Vite: dist
Create React App: build
Nuxt: .output/public
SvelteKit: build (как для SSG, так и для SSR)

Install Command

Команда для установки зависимостей.

Значение по умолчанию: Определяется автоматически по lock-файлу:

package-lock.json → npm install
yarn.lock → yarn install
pnpm-lock.yaml → pnpm install
bun.lockb → bun install

Root Directory

Путь к корню проекта относительно репозитория. Используется для монорепозиториев.

По умолчанию: . (корень репозитория)

Пример для монорепо:

my-monorepo/
├── packages/
│   ├── web/          ← Root Directory: packages/web
│   └── api/
└── package.json

Include Files Outside Root

Если включено, файлы за пределами Root Directory также будут включены в контекст сборки. Полезно для монорепозиториев с общими зависимостями.

По умолчанию: выключено

Когда включать:

Монорепо с общими пакетами в корне
Shared configuration files (tsconfig.base.json)
Workspaces с hoisted зависимостями

Расширенные настройки

Runtime Version

Версия рантайма зависит от package manager вашего проекта:

Node.js проекты (npm, yarn, pnpm)

Версия	Описание
Node 22	LTS, минимальная поддерживаемая версия
Node 24	LTS, рекомендуется
Node 26	Current

Bun проекты

Для проектов с bun.lock или bun.lockb используется зафиксированный patch-релиз Bun 1.4.2. Выбор версии недоступен.

Build Timeout

Максимальное время сборки зависит от плана:

План	Build Timeout
Hobby	20 минут
Pro	30 минут
Enterprise	60 минут

Если сборка занимает больше времени, она будет отменена с ошибкой.

Concurrent Builds

Количество одновременных сборок для проекта.

План	Лимит
Hobby	1
Pro	3

Prioritize Production Builds

Только для Pro плана

Если включено, production деплои (из main ветки) будут иметь приоритет в очереди над preview деплоями.

Ignored Build Step

Находится в: Project → Settings → Git

Позволяет пропустить сборку при определённых условиях.

Варианты

Опция	Описание
Automatic	Каждый коммит создаёт деплой
Only Production	Сборка только для production-окружения
Only Preview	Сборка только для preview-окружения
Only Changes	Сборка только если есть изменения в отслеживаемых файлах
Changes in Folder	Сборка только если изменения в указанной папке
Never	Никогда не собирать
Bash Script	Пользовательский bash-скрипт для проверки
Node Script	Пользовательский Node.js-скрипт для проверки
Custom	Произвольная команда с контрактом exit code

Changes in Folder

Полезно для монорепозиториев — собирать только если изменения затронули этот пакет.

Пример:

Root Directory: packages/web
Ignored Build Step: Changes in Folder
Folder: packages/web

Custom Command

Bash скрипт, который определяет нужно ли запускать сборку.

Пример:

# Пропустить если изменения только в README
if git diff --name-only HEAD~1 | grep -qvE '^README\.md$'; then
  exit 1  # Запустить сборку
else
  exit 0  # Пропустить сборку
fi

Exit code 0 — пропустить сборку
Exit code 1 — запустить сборку
Другой exit code или таймаут — завершить deployment с ошибкой, не публикуя артефакт

Ignored Build Step выполняется после checkout нужного commit и до Install Command. Ему доступны те же материализованные переменные сборки, включая ONREZA_ENV и ONREZA_GIT_BRANCH, если системные переменные включены в настройках проекта.

Environment Variables при сборке

System Environment Variables

ONREZA автоматически предоставляет переменные при сборке и runtime:

Переменная	Описание
`ONREZA_ENV`	Режим: `production`, `preview` или `development`; custom-окружения используют `preview`
`ONREZA_GIT_BRANCH`	Ветка, из которой создан deployment
`ONREZA_PROTECTION_BYPASS`	Секрет для обхода защиты preview (если настроен)

Expose System Env Vars

Если отключено, системные переменные не будут доступны при сборке. Это может быть нужно если они конфликтуют с вашим кодом.

Оптимизация сборки

Кэширование

ONREZA автоматически кэширует:

node_modules/ — зависимости
.next/cache/ — кэш Next.js
Другие кэши фреймворков

Это ускоряет последующие сборки.

Параллельные зависимости

Для ускорения установки зависимостей:

Используйте npm ci вместо npm install
Используйте pnpm или bun для более быстрой установки

Troubleshooting

Сборка слишком долгая

Проверьте Build Timeout — возможно нужно увеличить
Оптимизируйте сборку (code splitting, dynamic imports)
Убедитесь что кэширование работает
Рассмотрите upgrade до Pro плана для увеличения ресурсов

“Command not found”

Убедитесь что команда есть в scripts в package.json
Или используйте полный путь: npx next build

Output directory is empty

Проверьте что сборка завершилась успешно
Проверьте правильность Output Directory
Проверьте конфигурацию фреймворка (может генерировать в другую папку)

LIMIT_EXCEEDED и лимит файлов runtime-артефакта

Output Directory указывает основной результат сборки, но не всегда совпадает со всем runtime-артефактом. Серверному PROCESS-деплою нужны не только файлы из build или dist, но и доступные при запуске Node.js-зависимости, метаданные пакета и, для workspace, связанные runtime roots. Поэтому node_modules может учитываться и при Output Directory, отличном от ..

Перед загрузкой CLI выводит breakdown по непересекающимся категориям:

build output:       1 055
node_modules:      19 620
metadata:               4
workspace packages:     0
other:                  0
total:              20 679

total — то же количество deployable files, которое сравнивается с maxDeploymentFiles. В JSON progress frame и в structured details ошибки LIMIT_EXCEEDED те же счётчики доступны в details.runtimeArtifactFiles; абсолютные локальные пути в него не попадают.

Что можно сделать:

Удалить dev dependencies после сборки. Например, для npm используйте npm run build && npm prune --omit=dev; для другого package manager — его эквивалент.
Собрать self-contained production bundle, если инструменты проекта это поддерживают.
Перейти на static adapter только если SSR, server routes и другие серверные возможности приложению действительно не нужны.

Само наличие node_modules в PROCESS-артефакте не означает, что SSR-фреймворк не поддерживается. Лимит защищает pipeline от чрезмерно больших файловых деревьев; повышение тарифа не заменяет сокращение runtime dependency tree.

См. также

Фреймворки — настройки по фреймворкам
Environment Variables — переменные окружения
Деплои — управление деплоями