Окружения, preview и production
Главная идея
У проекта один стабильный production-адрес — apex. Что именно отдаёт apex — указывает production-pointer, который двигается автоматически (push в default-ветку или прямая layero deploy-загрузка в проект без репозитория — она авто-промоутится в apex) либо вручную (промоут из UI/CLI). Именованные ветки получают отдельные preview-ссылки и apex не трогают — но создаются они пушем в репозиторий, а не флагом CLI: layero deploy --branch игнорируется, архивные загрузки всегда идут в окружение cli (см. layero deploy).
Это Vercel-style: «один production, много preview». Каждая ветка — это полноценное окружение со своей историей деплоев, своим preview-URL и своими настройками, но только один из них одновременно работает по apex'у.
Окружение = ветка
Push в любую ветку создаёт окружение с собственной историей сборок. У окружения есть:
branch_name— имя git-ветки (илиcliдля архивных загрузок)- свой preview-URL
active_deploy_id— последний успешный билд этой ветки
CLI-деплои приземляются в псевдо-ветку cli всегда — независимо от --branch.
Адреса
Зона layero.app
Пользовательские сайты живут в отдельной доменной зоне — layero.app. Так
делают все (vercel.app, netlify.app, pages.dev), и причина та же: сайты
пользователей не должны жить на бренд-домене платформы.
Переезд завершён 26 июля 2026 — на layero.ru пользовательских сайтов больше
нет.
| Production-адрес | Адрес ветки | |
|---|---|---|
| Проект, созданный после переезда | <project>.layero.app | <project>-<branch>.layero.app |
| Проект, созданный до переезда | <org>-<project>.layero.app | <org>-<project>-<branch>.layero.app |
Метка при переезде сохранилась — сменилась только зона. Поэтому у проектов, существовавших до 26 июля, в адресе остался префикс организации, а новые получают короткий адрес из одного слага проекта.
Реальный адрес показан на карточке проекта в дашборде и печатается в выводе
layero deploy (поле url в JSON-режиме). Берите его оттуда.
Всё, что было на <...>.layero.ru, включая адреса веток и превью-формы,
отдаёт 301 на новый адрес с сохранением пути и запроса. Ссылки, которыми вы
делились, продолжают работать. С 31 августа редирект отключится — замените
адрес там, где он опубликован: в письмах, в профилях, в чужих статьях.
Что важно знать про эту зону:
- Имя проекта глобально уникально. Слаг, уже занятый другим проектом на платформе, взять не получится — адрес складывается из него одного.
- Отдельной preview-зоны нет. Адрес ветки живёт плоской меткой в той же
зоне и под тем же wildcard-сертификатом. Per-deploy адреса с суффиксом
-<sha7>больше не выдаются — шерится адрес ветки. - Кастомные домены переезд не затронул — они привязаны к окружению, а не к платформенной зоне, и работают как работали.
Три типа URL
| URL | Когда работает | Срок жизни | Зачем |
|---|---|---|---|
| Production-адрес проекта | сразу после первого успешного деплоя | пока живёт проект | Production apex — то, что показываете пользователям |
| Preview-адрес ветки | сразу после успешного билда ветки | пока ветка существует | Preview ветки — для проверки и шеринга |
Per-deploy URL с суффиксом -<sha7> существовал в прежней зоне и больше не
выдаётся: он был нужен, пока адрес ветки прогревался на CDN, а CDN перед
пользовательскими зонами больше не стоит.
Production apex
Канонический адрес проекта. Один на проект. Покрыт wildcard-сертификатом
своей зоны и начинает работать сразу после первого успешного деплоя — ждать
регистрации хоста не нужно. Дальше живёт без перерывов: переключение между
деплоями идёт через указатель production_deploy_id, без перерегистрации
hostname'а.
Раньше *.layero.ru фронтил YC CDN, и первый деплой нового хоста ждал 5–15
минут прогрева. С июля 2026 пользовательская зона резолвится напрямую в
балансировщик платформы (NLB → edge). Отсюда три практических следствия:
адрес живой сразу; POST/PUT/DELETE работают на самом production-адресе;
WebSocket — тоже. Обходить апекс через preview-хост, как раньше, больше не
нужно.
Apex отдаёт тот деплой, на который указывает production_deploy_id. Этот указатель двигают:
- Auto-promote: успешный push в default-ветку → apex автоматически переключается на новый билд (включено по умолчанию, выключается на странице Settings проекта).
- Manual promote: кнопка «Promote» в UI или
layero promoteиз CLI — на любой ready-деплой любой ветки. - Rollback: одна кнопка «Откатить» возвращает apex на предыдущий production-деплой (атомарный swap pointer'а, см. ниже).
Preview-URL веток
Для каждой ветки (и для CLI-загрузок) выдаётся стабильный URL вида
<метка-проекта>-<branch>.layero.app. Он покрыт wildcard-сертификатом на edge
и работает сразу после успешной сборки.
Preview-хосты отдаются с X-Robots-Tag: noindex — в поиск попадает
production-адрес, а не каждая ветка.
Раньше preview-URL переставал работать через 24 часа после первого успешного деплоя ветки, а продлить его можно было кнопкой «Pin preview». Ни того, ни другого больше нет: воркер, снимавший хосты по TTL, удалён, кнопки в интерфейсе нет.
Проверено на живом проде 27.07.2026 — preview-адреса веток, созданных шесть и семь дней назад и никак не закреплённых, отдают 200. Из 579 зарегистрированных хостов сняты 4.
Ссылка живёт, пока существует сама ветка: удаление ветки в GitHub
архивирует окружение вебхуком branch_deleted.
Per-deploy URL — больше нет
Раньше к адресу ветки добавлялся sha-суффикс
(<label>-<branch>-<sha7>.preview.layero.ru), чтобы зашерить конкретный
коммит. Он существовал ради прежней зоны: адрес ветки там прогревался на CDN, и
нужен был отдельный уникальный хост.
В зоне layero.app такой адрес не выдаётся. Чтобы показать конкретный билд,
используйте адрес ветки — он всегда отдаёт её текущий деплой, — либо
задеплойте нужный коммит в отдельную ветку.
Production-pointer (V071)
Это и есть «новая логика определения доменов». Раньше каждая ветка получала свой отдельный канонический домен — это плохо масштабировалось и плохо матчилось с production-флоу (никто не хотел чтобы любая feature-ветка автоматом становилась прод). Сейчас:
projects.production_deploy_id ──→ deploys (конкретный билд)
│
▼
environments (любая ветка)
Production-адрес проекта всегда отдаёт именно этот deploy_id — независимо от того, на какой ветке он был собран.
Auto-promote (по умолчанию вкл)
При успешном push'е в default-ветку (main обычно) указатель автоматически переключается. Это сохраняет «push to main = ship to prod»-флоу для соло-проектов.
Когда команда растёт — выключите auto-promote в Settings проекта. Тогда каждый promote становится явным кликом — для предотвращения случайных production-релизов.
Manual promote
Из UI: кнопка «Promote to production» на странице любого ready-деплоя.
Из CLI:
# promote последнего ready-деплоя default-ветки
layero promote
# promote конкретного деплоя по SHA или ID
layero promote a3f9c2b
# выкатить из dev-ветки сразу в production одной командой
layero deploy --branch=staging --promote
Каждый promote логируется в promote_events — кто, когда, какой деплой, через какой канал (UI / CLI / auto). История доступна в дашборде.
One-click rollback
При каждом promote'е Layero сохраняет предыдущий production-деплой в previous_production_deploy_id. Кнопка «Откатить production» делает атомарный swap двух полей — apex возвращается на прошлый рабочий билд практически сразу; задержку даёт только короткий кеш на edge (до минуты).
layero deploys list # найти нужный commit_sha
layero promote <commit-sha> # вернуть апекс на него
layero rollback возвращает и апекс — при условии, что production
обслуживается той же веткой (починено 27.07.2026; раньше двигалось только
окружение). Флага layero promote --rollback не существует; чтобы вернуться
на конкретный старый деплой, используйте layero promote <commit-sha>.
Подробности — в Rollback.
Rollback стабильный: вызвав его дважды, вернётесь к исходному состоянию (ping-pong).
Что показывает UI
На странице проекта Production card — то, что сейчас отдаёт apex:
- Хост: production-адрес проекта (один и тот же всегда)
- Содержание: скриншот текущего production-деплоя
- Бейдж ветки:
productionнапротив той ветки, чей деплой сейчас pinned
В списке веток ниже — все остальные с их preview-URL и собственным статусом.
Coming Soon
Когда у проекта никогда не было успешного production-деплоя (только что создан, default-ветка не собралась, ещё не запушили ничего), apex показывает страницу «Сайт скоро появится» вместо 404 — чтобы зашаренная ссылка выглядела ожидающе, а не сломанно.
То же самое — для preview-URL ветки, build которой ещё в полёте (нет ready-деплоя для этой ветки).
Передача между членами команды
Preview-ссылка ветки — это публичный URL (если не включена site-auth). Шерится в любой чат / комментарий PR.
Канонический apex — тоже публичный, но это production: его показывают пользователям, а не QA. Promote — это release-action, делайте осознанно.