Перейти к основному содержимому

Основные концепции

Прежде чем погружаться в детали, разберёмся в словаре платформы: проект, окружение, деплой, runtime и handle. Эти пять понятий встречаются во всём остальном дока-сайте.

Организация​

Организация — scope, объединяющий людей, проекты и интеграции под одним slug'ом. Бывает двух видов:

  • Personal — личная, создаётся автоматически на signup, slug = ваш username. Один на пользователя, без приглашений.
  • Team — командная, создаётся вручную ("+ Создать команду"), принимает приглашения по email, может подключить GitHub App.

Подробно — Организации.

В верхнем углу дашборда — OrganizationSwitcher, persist'ит активную организацию в localStorage. Все списки (проекты, репы для импорта, деплои) фильтруются по активной orgе.

Проект​

Проект — единица деплоя. Принадлежит одной организации, имеет уникальный slug в её namespace'е. Канонический адрес — https://<organization>-<project>.layero.ru.

Источник кода:

  • github — код берётся из GitHub-репозитория, push автоматически запускает деплой через webhook (OAuth или GitHub App).
  • cli — код приходит из локального layero deploy (загрузка тарбола).

Один проект может одновременно принимать оба источника (mixed-mode): GitHub push + CLI uploads сосуществуют. См. layero deploy.

Окружение​

Окружение соответствует ветке репозитория. Push в любую ветку создаёт своё окружение со своей историей деплоев и своим preview-URL на 24 часа.

У проекта есть один production-адрес — apex <org>-<project>.layero.ru. Какое окружение его сейчас отдаёт — решает production_deploy_id (см. ниже). Это не обязательно default-ветка — может быть любой promoted-билд.

См. Окружения, preview и production.

Деплой​

Деплой — конкретная сборка с конкретного коммита (commit_sha). У каждого деплоя есть статус:

СтатусЧто значит
queuedпоставлен в очередь, ждёт билд-инстанса
buildingсборка идёт прямо сейчас
readyартефакты загружены, можно promote'ить и отдавать
failedсборка упала, см. логи деплоя

environments.active_deploy_id — последний ready-деплой ветки, обновляется атомарно после билда. Доступен по preview-URL ветки.

projects.production_deploy_id — указатель на тот один деплой, который сейчас отдаёт apex. Двигается auto-promote'ом на default-ветке или вручную через UI/CLI promote.

Rollback — обмен production_deploy_id и previous_production_deploy_id одним атомарным шагом. Apex моментально возвращается на прошлый рабочий билд; повторный rollback вернёт всё обратно. См. layero promote или кнопку «Откатить» в UI.

Runtime: статика vs SSR​

Layero различает два режима исполнения:

  • SPA / static (по умолчанию) — после сборки получаем папку с HTML/JS/CSS, она лежит в S3 и отдаётся через CDN. Никаких процессов на стороне Layero не запускается. Это самый быстрый и дешёвый режим.
  • Runtime — приложение запускается как контейнер (SSR Next.js, Streamlit, Gradio, Flask и т. п.). Контейнер активируется по первому запросу и останавливается при простое. См. Runtime.

Username и организация​

При первом входе вы выбираете уникальный username — handle вашего аккаунта. На его основе автоматически создаётся ваша персональная организация со slug'ом, равным username. Например, username alice → проекты этой организации доступны на https://alice-<project>.layero.ru.

Помимо персональной, можно создавать дополнительные организации со своими slug'ами — например, для совместной работы с командой. В каждой организации могут состоять несколько участников (admin / member), приглашаемых по email. Управление участниками — в разделе Команда.

Username задаётся один раз при онбординге. Подробнее в Onboarding.

Билд-окружение​

  • Node.js — nvm use <detected_version>. Версия определяется по .nvmrc, .node-version, engines.node в package.json. По умолчанию — Node 20.
  • Пакетный менеджер — детектируется по lock-файлу: yarn.lock → yarn, pnpm-lock.yaml → pnpm, иначе npm.
  • node_modules удаляется перед install.
  • Команда сборки — берётся из проекта (build_cmd), по умолчанию npm run build. Output-директория определяется по фреймворку (см. Поддерживаемые фреймворки).