Deploy to Layero — GitHub Action

Layero — российская платформа хостинга и деплоя фронтенд-приложений. Деплой одной командой npx layero deploy, серверы и CDN внутри России, поддержка Next.js / Vite / Astro / SvelteKit / Nuxt и деплой прямо из AI-агентов (Cursor, Claude Code).

🌐 Сайт: https://layero.ru · 📚 Документация: https://docs.layero.ru · 📦 npm: https://www.npmjs.com/package/layero

Публикует сайт или приложение на Layero из GitHub Actions.

📖 Полное руководство в документации: Деплой из GitHub Actions

Быстрый старт

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

Токен создаётся на странице app.layero.ru/settings/cli и кладётся в секреты репозитория как LAYERO_TOKEN. Он бессрочный — в отличие от обычной сессии входа не протухает через неделю; отключается там же, где создавался.

Когда это нужно

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

Action нужен, когда сборку надо выполнить в CI: нужны секреты, к которым у платформы нет доступа, приватные 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

Параметры

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

project или name — не одно и то же

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

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

Мы наступили на это в собственном репозитории примеров — за сутки набежало 11 проектов на 4 примера, и ссылки в README устаревали после каждого push.

          project: my-site      # ← повторяемый деплой в один проект

Оставляйте name только для сценария «проект создаётся этим же workflow и живёт один раз».

Результаты

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

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

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

Куда попадает деплой: важное про prod и branch

Action всегда грузит архив — упакованный каталог, а не git-ссылку. Бэкенд для архивных загрузок жёстко кладёт деплой в служебное окружение cli (branch_name = "cli" до всякой проверки входов), поэтому:

• branch при работе через этот Action не действует. Флаг принимается и молча игнорируется — отдельного окружения на ветку не появится.
• prod меняет поведение только у проекта с подключённым репозиторием.

Дальше всё зависит от того, подключён ли к проекту репозиторий на стороне Layero (Project → Settings → Repository), а не от того, что код лежит на GitHub:

Проект	Что делает обычный запуск Action
без подключённого репозитория	окружение cli и есть апекс → каждый запуск заменяет живой сайт
с подключённым репозиторием	окружение cli изолировано → продакшн не затрагивается, prod публикует в него явно

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

⚠️ Не делайте превью пулл-реквестов этим Action. Workflow вида on: [pull_request] с branch: pr-${{ github.event.number }} не создаст изолированного превью: у проекта без репозитория он опубликует ветку PR на живой адрес, у проекта с репозиторием — сложит все PR в одно общее окружение cli, где они будут затирать друг друга.

Настоящие превью на ветку даёт только подключённый репозиторий: подключите его в настройках проекта, и Layero будет собирать пуши сам, без этого Action.

Безопасность

Токен передаётся в CLI через переменную окружения, а не аргументом: аргументы процесса видны другим процессам на раннере и попадают в трассировки.

У токена узнаваемый префикс layero_ci_ — если он случайно попадёт в публичный репозиторий, это заметно и автоматическими сканерами секретов.

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

Живой пример

Репозиторий LayeroInfra/examples публикует четыре приложения этим Action при каждом push — Vite, Next.js (SSR), Astro и статику. Там же лежат готовые workflow-файлы, включая матричный.

Лицензия

MIT