Деплой из GitHub Actions

Официальный Action — LayeroInfra/deploy-action.

name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: LayeroInfra/deploy-action@v1
        with:
          token: ${{ secrets.LAYERO_TOKEN }}
          prod: true

Сначала — нужен ли вам Action вообще

Если репозиторий просто привязан к проекту, сборка запускается вебхуком при каждом push, и Action не нужен: вы добавите вторую копию той же работы.

Action нужен, когда сборку надо выполнить в вашем пайплайне:

• сборке требуются секреты, которых у платформы нет;
• используются приватные npm-пакеты из вашего реестра;
• перед публикацией должны пройти тесты, линтеры или кодогенерация;
• собираете монорепу и публикуете только один пакет из неё.

Тогда собираете у себя и отправляете готовый артефакт:

      - run: npm ci && npm run build
        env:
          API_KEY: ${{ secrets.API_KEY }}
      - uses: LayeroInfra/deploy-action@v1
        with:
          token: ${{ secrets.LAYERO_TOKEN }}
          prebuilt: dist
          prod: true

Токен

Обычная сессия входа живёт неделю — для CI не годится: сборки начнут падать с 401 ровно через семь дней. Поэтому для пайплайнов есть отдельный бессрочный токен.

1. Откройте app.layero.ru/settings/cli, раздел «Токены для CI».
2. Введите название (например, GitHub Actions) и нажмите «Создать токен».
3. Скопируйте значение сразу — оно показывается один раз. В базе хранится только хеш, восстановить токен невозможно.
4. В репозитории: Settings → Secrets and variables → Actions → New repository secret, имя LAYERO_TOKEN.

Отключить токен можно там же, где создавали, — сборки, которые им пользуются, сразу начнут получать 401.

:::warning Токен даёт права уровня аккаунта Токен может всё то же, что и обычный вход. Заводите отдельный токен на каждый репозиторий: тогда компрометацию одного закрываете, не ломая остальные. :::

CLI читает токен из переменной LAYERO_TOKEN раньше, чем локальный ~/.layero/config.json. Это сделано намеренно: иначе на машине разработчика с активным логином переменная молча проигрывала бы, и деплой уходил не в тот аккаунт.

Параметры

Параметр	Обязателен	По умолчанию	Что делает
token	да	—	CI-токен Layero
project	нет	из .layero/project.json	Проект-получатель (id или slug)
name	нет	—	Имя проекта при создании на первом деплое
prod	нет	false	Публиковать в production
branch	нет	—	Окружение конкретной ветки; приоритетнее prod
prebuilt	нет	—	Каталог с готовой сборкой
type	нет	автоопределение	Фреймворк: vite, next, astro, static…
root	нет	—	Монорепа: подкаталог как корень приложения
working-directory	нет	.	Откуда запускать деплой
version	нет	latest	Версия npm-пакета layero

:::danger name создаёт новый проект на каждом прогоне Если workflow должен раз за разом обновлять один и тот же проект, указывайте project — он принимает id или slug и бьёт в конкретный существующий проект.

name задаёт имя только в момент создания проекта на первом деплое. А первым деплой оказывается каждый раз, когда в репозитории нет .layero/project.json — обычно его там и нет. При совпадении имён слаг получает суффикс, поэтому ошибка не падает: сборка зелёная, просто адрес каждый раз новый.

Мы наступили на это в собственном репозитории примеров: за сутки набежало 11 проектов на 4 примера. :::

Выходы шага

      - uses: LayeroInfra/deploy-action@v1
        id: deploy
        with:
          token: ${{ secrets.LAYERO_TOKEN }}
      - run: 'echo "Опубликовано — ${{ steps.deploy.outputs.url }}"'

Выход	Что содержит
url	Адрес, по которому опубликован деплой
deploy-id	Идентификатор деплоя

Адрес дополнительно попадает в summary задачи — его видно на странице запуска, без чтения логов.

Превью на пулл-реквесты

on: [pull_request]

jobs:
  preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: LayeroInfra/deploy-action@v1
        with:
          token: ${{ secrets.LAYERO_TOKEN }}
          branch: pr-${{ github.event.number }}

Без prod деплой уходит в preview-окружение и продакшн не трогает.

Несколько примеров одним workflow

Матрица публикует несколько приложений из одного репозитория. Так устроен репозиторий примеров — четыре живых сайта собираются и выкатываются при каждом push.

    strategy:
      fail-fast: false
      matrix:
        include:
          - dir: vite-react
            output: dist
          - dir: astro
            output: dist

:::tip fail-fast: false — не перестраховка Без него один сломанный пример отменяет выкатку всех остальных, включая уже собранные. Одна битая зависимость гасит все живые демо. :::

Типовые ошибки

prebuilt_no_index

'.next' has no index.html — nothing to serve

prebuilt предназначен для статики — каталога, в котором лежит готовый index.html. Сборка Next.js в режиме сервера таким каталогом не является.

Для SSR-приложений prebuilt не указывайте вовсе: отправляйте исходники, и Layero поднимет приложение как runtime. Статический экспорт Next.js (output: 'export') наоборот отправляйте через prebuilt: out.

auth_required сразу после старта

Токена нет или он пустой. Проверьте, что секрет называется именно LAYERO_TOKEN и проброшен в шаг.

Раньше в этой ситуации CLI пытался открыть браузерный вход и висел 15 минут, пока код не истечёт. Начиная с версии 0.8.4 в CI он падает сразу — молчаливое ожидание на раннере было хуже честной ошибки.

address_required / impersonation

Имя проекта похоже на чужой бренд или на служебный адрес платформы. Возьмите другое имя — например, с префиксом своей организации.

project_not_found

project указывает на несуществующий проект. Либо уберите параметр (проект создастся на первом деплое), либо посмотрите доступные: npx layero projects list.

Другие CI-системы

Action — обёртка над обычным вызовом CLI, поэтому в любой другой системе достаточно переменной окружения:

LAYERO_TOKEN=... npx layero@latest deploy --prod --yes

Флаг --yes пропускает подтверждения; в CI без него команда будет ждать ввода, которого не дождётся.