Self-hosted раннер GitHub: настройка Linux, Docker и Kubernetes

Собственный (self-hosted) раннер GitHub выполняет задачи (job) GitHub Actions на предоставленной вами машине с помощью агента actions/runner от GitHub с открытым исходным кодом. Раннер устанавливает исходящее HTTPS-соединение с GitHub, чтобы получать задачи. По состоянию на 4 ноября 2026 года документация GitHub по биллингу указывает, что вычисления на self-hosted раннерах бесплатны; вы платите за машину и её обслуживание. Справочник раннеров GitHub, биллинг GitHub Actions.

Мы создаём Lizard, который предлагает платные раннеры GitHub Actions; цены проверены 4 ноября 2026 года.

Самый короткий путь — VM с Linux, токен регистрации из настроек репозитория и workflow с соответствующими метками раннера. Начните с приватного тестового репозитория. Для парка раннеров выберите одноразовые VM, Kubernetes с ARC или модуль Terraform для AWS. Если раннеры уже работают, перейдите к безопасности, устранению неполадок или стоимости машин.

Self-hosted раннер и раннер под управлением GitHub

GitHub создаёт и обслуживает новое окружение для каждой задачи на раннере под своим управлением. Для self-hosted раннера вы сами предоставляете машину, устанавливаете обновления и обеспечиваете её защиту.

Источники: обзор self-hosted раннеров, обзор раннеров под управлением GitHub и документация по биллингу от GitHub.

Оставьте раннеры под управлением GitHub, если ваш проект с открытым исходным кодом уже использует их бесплатно или команда не хочет обслуживать машины для сборок. Самостоятельный хостинг имеет смысл, когда нужны определённое оборудование, доступ к приватной сети или достаточно постоянной работы, чтобы оправдать эксплуатацию машин.

Какой вариант подходит?

Как настроить self-hosted раннер GitHub Actions на Linux?

Чтобы добавить self-hosted раннер GitHub Actions:

1. Откройте Settings → Actions → Runners → New self-hosted runner в своём репозитории.
2. Скачайте actions/runner и проверьте его контрольную сумму SHA-256.
3. Зарегистрируйте его с помощью ./config.sh, URL репозитория и токена регистрации со страницы.
4. Запустите ./run.sh и убедитесь, что раннер ожидает задачи.
5. Отправьте задачу с runs-on: [self-hosted, linux, x64, linux-build], указав пользовательскую метку из примера ниже.

Используйте VM с Ubuntu 24.04 или Debian 12 x64 и systemd. Войдите под обычным пользователем без прав root, который может использовать sudo. Вам нужны приватный репозиторий GitHub, который вы администрируете, исходящий доступ в интернет и достаточно дискового пространства и памяти для сборки. Требования GitHub к раннерам допускают обе операционные системы и требуют исходящий HTTPS на порту 443. Раннеру не нужен входящий порт для вебхуков.

4 ноября 2026 года мы протестировали эти шаги на новой VM с Debian 12 x64, systemd и actions/runner v2.338.2: скачивание и проверку контрольной суммы, регистрацию в приватном тестовом репозитории, проверочный workflow, установку службы, удаление и JIT-раннер на уровне репозитория. Вывод ниже — фрагменты этого теста; наш тестовый логин был builder.

Скачайте раннер и проверьте его

В репозитории откройте Settings → Actions → Runners → New self-hosted runner, затем выберите Linux и x64. Для раннера организации используйте настройки организации и аккаунт её владельца. Администраторы Enterprise также могут добавлять раннеры на уровне Enterprise. Инструкция GitHub по настройке объясняет каждый уровень.

Выполните эти команды в Bash под своим пользователем без прав root. Они получают текущий релиз и его хеш SHA-256 через API релизов GitHub, затем проверяют архив перед распаковкой:

sudo apt-get update
sudo apt-get install -y ca-certificates curl jq
mkdir actions-runner
cd actions-runner
curl -fsSL https://api.github.com/repos/actions/runner/releases/latest -o release.json
RUNNER_VERSION=$(jq -er '.tag_name | ltrimstr("v")' release.json)
RUNNER_TARBALL="actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz"
RUNNER_URL=$(jq -er --arg name "$RUNNER_TARBALL" \
  '.assets[] | select(.name == $name) | .browser_download_url' release.json)
RUNNER_SHA=$(jq -er --arg name "$RUNNER_TARBALL" \
  '.assets[] | select(.name == $name) | .digest | select(startswith("sha256:")) | ltrimstr("sha256:")' release.json)
curl -fsSL "$RUNNER_URL" -o "$RUNNER_TARBALL"
printf '%s  %s\n' "$RUNNER_SHA" "$RUNNER_TARBALL" | sha256sum -c - && \
  tar xzf "$RUNNER_TARBALL" && \
  sudo ./bin/installdependencies.sh && \
  ./config.sh --help

Ожидаемый результат: actions-runner-linux-x64-2.338.2.tar.gz: OK. Распаковка выполняется только при успешной проверке контрольной суммы; остановитесь, если проверка не прошла или GitHub не предоставил хеш. Релизы развёртываются постепенно, поэтому при необходимости используйте версию и контрольную сумму со страницы настройки в вашем репозитории. Релизы раннера GitHub.

На Debian 12 скрипт installdependencies.sh выводил E: Unable to locate package libicu80 и похожие строки, перебирая версии ICU, а затем нашёл libicu72. В нашем тесте такие попытки найти подходящую версию были ожидаемыми; проверьте, что скрипт завершился успешно.

Зарегистрируйте раннер и запустите ожидание задач

Скопируйте токен регистрации со страницы настройки. По документации GitHub этот токен истекает через один час. Это токен регистрации раннера, а не персональный токен доступа. Замените YOUR_OWNER/YOUR_REPO ниже на путь репозитория; для уровня организации используйте https://github.com/YOUR_ORG.

read -rsp 'Registration token: ' RUNNER_TOKEN
printf '\n'
./config.sh --unattended \
  --url https://github.com/YOUR_OWNER/YOUR_REPO \
  --token "$RUNNER_TOKEN" \
  --name linux-build-01 \
  --labels linux-build
unset RUNNER_TOKEN
./run.sh

Ожидаемый результат: √ Connected to GitHub, √ Runner successfully added, √ Settings Saved., затем Listening for Jobs после ./run.sh. В разделе Settings → Actions → Runners ищите статус Idle, когда раннер подключён и готов. Оставьте процесс в терминале работающим на время первой задачи. Регистрация, статус раннера.

Отправьте раннеру задачу

Закоммитьте этот файл как .github/workflows/runner-check.yml в ветку репозитория по умолчанию:

name: Check self-hosted runner
on:
  workflow_dispatch:
permissions:
  contents: read
jobs:
  check:
    runs-on: [self-hosted, linux, x64, linux-build]
    steps:
      - name: Show the execution environment
        run: |
          echo "Runner accepted the job"
          uname -s -m
          whoami

Откройте Actions → Check self-hosted runner → Run workflow. Ожидаемый результат из нашего теста: Runner accepted the job / Linux x86_64 / builder. Ваш логин может отличаться. Для этой базовой проверки не нужны ни checkout, ни набор инструментов сборки; добавьте их для своей сборки. Если задача остаётся в очереди, см. почему задача ожидает.

GitHub сопоставляет все метки из списка runs-on. При регистрации раннер получает self-hosted, linux и x64; linux-build — наша пользовательская метка для примера. Метка описывает раннер, но не устанавливает ПО и не предоставляет доступ к репозиторию. Маршрутизация workflow GitHub.

Обеспечьте постоянную работу раннера как службы

После завершения теста нажмите Ctrl-C и убедитесь, что процесс ./run.sh, запущенный на переднем плане, завершился, прежде чем запускать службу. Иначе в журнале могут появиться A session for this runner already exists. и Conflict, пока старый процесс продолжает принимать задачи. Мы столкнулись с этим в своём тесте. Из каталога раннера, под тем же пользователем без прав root:

sudo ./svc.sh install
sudo ./svc.sh start
sudo ./svc.sh status

Ожидаемый результат: Active: active (running) в выводе svc.sh status. GitHub создаёт svc.sh после регистрации; на systemd эти команды обеспечивают работу раннера после выхода из системы и перезагрузки. Настройка службы GitHub.

Удалите раннер

В разделе Settings → Actions → Runners выберите раннер и нажмите Remove, чтобы получить токен удаления. Из его каталога остановите и удалите службу, затем удалите регистрацию:

sudo ./svc.sh stop
sudo ./svc.sh uninstall
read -rsp 'Removal token: ' REMOVAL_TOKEN
printf '\n'
./config.sh remove --token "$REMOVAL_TOKEN"
unset REMOVAL_TOKEN

Ожидаемый результат: √ Runner removed successfully, √ Removed .credentials, √ Removed .runner. Инструкция GitHub по удалению раннера описывает действия в интерфейсе; для автоматизации можно запросить токен удаления раннера на уровне репозитория.

Чем группы раннеров отличаются от меток?

Группа раннеров GitHub Actions определяет, какие репозитории могут использовать набор раннеров. Метки помогают выбрать раннер из разрешённого набора. Для раннеров организации откройте Settings → Actions → Runner groups, выберите группу и ограничьте Repository access репозиториями, которым нужен доступ. Управление группами раннеров GitHub.

Для раннера организации создайте группу с именем trusted-builds, затем выполните регистрацию с --url https://github.com/YOUR_ORG --runnergroup trusted-builds. Группа должна существовать заранее; этот флаг не применяется к настройке на уровне репозитория, описанной выше. Задача может требовать и группу, и метку:

runs-on:
  group: trusted-builds
  labels: linux-build

Не запускайте релизные задачи на раннерах, которые используются менее доверенными репозиториями. Группы ограничивают круг тех, кто может отправлять задачи; они не изолируют процессы и не делают общие диски безопасными. Документация GitHub по маршрутизации требует и доступа к группе, и совпадения меток.

Как работают одноразовые и just-in-time раннеры?

Одноразовый раннер принимает одну задачу, после чего GitHub удаляет его регистрацию; включите этот режим с помощью --ephemeral. Ваша инфраструктура всё равно должна уничтожить VM или очистить её диски. GitHub рекомендует одноразовые раннеры для автомасштабирования и указывает, что перед использованием в продакшене нужно настроить сохранение их логов во внешнем хранилище. Справочник GitHub по автомасштабированию.

Если вы сохранили прежний раннер с той же меткой linux-build, остановите его службу командой sudo ./svc.sh stop или используйте другую метку и в новом раннере, и в workflow. Иначе GitHub может отправить тестовую задачу прежнему раннеру. На новой VM и в каталоге раннера, который ещё не настроен, используйте новый токен регистрации:

read -rsp 'Registration token: ' RUNNER_TOKEN
printf '\n'
./config.sh --unattended \
  --url https://github.com/YOUR_OWNER/YOUR_REPO \
  --token "$RUNNER_TOKEN" \
  --name "ephemeral-$(hostname)" \
  --labels linux-build \
  --ephemeral
unset RUNNER_TOKEN
./run.sh

Уничтожайте машину после завершения процесса ожидания задач, в том числе после сбоев. Также предусмотрите отмену и машины, которые так и не получили задачу. Повторная регистрация той же VM с оставшимися данными не создаёт чистого окружения.

Создайте конфигурацию just-in-time через API

JIT-раннер получает конфигурацию при запуске и может выполнить не более одной задачи. Система подготовки машин может получить эту конфигурацию, не размещая долгоживущие учётные данные для API GitHub на рабочей машине. GitHub при этом предупреждает, что повторное использование оборудования требует чистого окружения. Рекомендации GitHub по безопасности JIT.

Для этого примера на уровне организации используйте токен API, авторизованный для организации, с разрешением Self-hosted runners: write. Администратор организации может использовать для теста токен с детализированными разрешениями; для автоматизации используйте токен установки GitHub App. Получите числовой ID группы через API групп раннеров GitHub и сначала ограничьте доступ репозиториев к этой группе.

В Bash замените заглушки организации и группы. Запускайте команды из каталога раннера на новой машине (сначала повторите блок скачивания) только для доверенного теста; в продакшене выполняйте запрос API в системе подготовки машин и передавайте рабочей машине только возвращённую конфигурацию.

ORG='YOUR_ORG'
RUNNER_GROUP_ID='REPLACE_WITH_NUMERIC_GROUP_ID'
read -rsp 'GitHub API token: ' GH_API_TOKEN
printf '\n'
JIT_CONFIG=$(
  jq -n --arg name "jit-$(date +%s)" --argjson group "$RUNNER_GROUP_ID" \
    '{name: $name, runner_group_id: $group,
      labels: ["self-hosted", "linux", "x64", "linux-build"],
      work_folder: "_work"}' |
  curl -fsSL -X POST \
    -H 'Accept: application/vnd.github+json' \
    -H "Authorization: Bearer $GH_API_TOKEN" \
    -H 'X-GitHub-Api-Version: 2026-03-10' \
    --data-binary @- \
    "https://api.github.com/orgs/$ORG/actions/runners/generate-jitconfig" |
  jq -er '.encoded_jit_config'
)
unset GH_API_TOKEN
[ -n "$JIT_CONFIG" ] && ./run.sh --jitconfig "$JIT_CONFIG"
unset JIT_CONFIG

GitHub документирует этот JIT-запрос для организации и JIT-эндпоинт на уровне репозитория для тестов с одним репозиторием; в нашем тесте использовался второй вариант с runner_group_id: 1. Флаг --jitconfig работает, хотя ./run.sh --help его не показывает. Обращайтесь с закодированной конфигурацией как с секретом; маршрутизация по-прежнему зависит от уровня регистрации, групп и меток.

Ожидаемый результат после JIT-задачи: Job check completed with result: Succeeded, √ Removed .credentials, √ Removed .runner, затем Runner listener exit with 0 return code, stop the service, no retry needed. и Exiting runner....

Как запустить self-hosted раннер GitHub в Docker?

Поддерживаемый GitHub образ ghcr.io/actions/actions-runner запускает агент в контейнере. В этом примере используется тег 2.338.2, последний релиз раннера на 4 ноября 2026 года; мы проверили его манифест Linux x64, но не запускали с ним задачу Docker.

Сначала установите Docker Engine по инструкции для Ubuntu или инструкции для Debian от Docker. Команда использует sudo; альтернативная настройка группы docker из документации Docker предоставляет доступ уровня root.

Получите новую конфигурацию на одну задачу через API GitHub generate-jitconfig с помощью JIT-запроса, но пропустите строки локального запуска раннера и unset JIT_CONFIG. Когда возвращённая конфигурация находится в JIT_CONFIG, выполните:

sudo docker run --rm --init --platform linux/amd64 \
  --entrypoint /home/runner/run.sh \
  ghcr.io/actions/actions-runner:2.338.2 \
  --jitconfig "$JIT_CONFIG"
unset JIT_CONFIG

Отправьте проверочный workflow на метку контейнера. Контейнер работает от имени пользователя runner из образа, не подключает постоянный рабочий каталог и удаляется при завершении. В исходном коде образа GitHub перечислены его инструменты; добавьте зависимости сборки в производный образ.

Запуск агента в Docker отличается от использования настройки container: в workflow для запуска шагов задачи в Docker. Для действий на основе контейнеров Docker и сервисных контейнеров GitHub требует Linux и работающую установку Docker. Команда выше не настраивает демон Docker для вложенных контейнерных задач. Контейнерные задачи GitHub.

Монтирование сокета Docker с хоста позволяет коду задачи управлять этим демоном, что может открыть доступ к файловой системе хоста. Docker-in-Docker часто требует привилегированного контейнера и отдельного плана работы с диском, сетью и очисткой. Ни один из подходов не делает обычный общий хост Docker безопасным для вредоносных pull request. Для недоверенной нагрузки используйте границу изоляции в виде одноразовой VM и прочитайте рекомендации Docker по безопасности демона.

Как настроить автомасштабирование на Kubernetes с Actions Runner Controller?

Actions Runner Controller (ARC) — контроллер Kubernetes с открытым исходным кодом для self-hosted раннеров GitHub Actions, поддерживаемый GitHub и участниками сообщества. Он создаёт поды раннеров для задач в очереди и масштабирует парк в пределах настроек minRunners и maxRunners, вплоть до нуля, если это настроено. Используйте его, если ваша команда уже эксплуатирует Kubernetes; для быстрого старта с ARC по инструкции GitHub требуются кластер и Helm 3. Архитектура ARC.

Установите контроллер в отдельное пространство имён:

helm install arc \
  --namespace arc-systems \
  --create-namespace \
  oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set-controller
kubectl create namespace arc-runners

Для этого примера на уровне организации создайте и установите GitHub App с разрешениями Self-hosted runners: read and write для организации и Metadata: read-only для репозитория. Сохраните его закрытый ключ локально как github-app.pem. Для регистрации на уровне репозитория также требуется Administration: read and write. Следуйте инструкции GitHub по аутентификации ARC.

Замените ID приложения и установки, затем создайте секрет в пространстве имён раннеров:

kubectl create secret generic arc-github-app \
  --namespace arc-runners \
  --from-literal=github_app_id=YOUR_APP_ID \
  --from-literal=github_app_installation_id=YOUR_INSTALLATION_ID \
  --from-file=github_app_private_key=./github-app.pem

Сохраните это как runner-values.yaml. В примере выбраны ноль простаивающих раннеров и максимум четыре раннера; это ваши настройки бюджета, а не ограничения продукта ARC.

githubConfigUrl: https://github.com/YOUR_ORG
githubConfigSecret: arc-github-app
runnerScaleSetName: arc-linux
minRunners: 0
maxRunners: 4

Установите масштабируемый набор раннеров и проверьте контроллер:

helm install arc-linux \
  --namespace arc-runners \
  --values runner-values.yaml \
  oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set
helm list -A
kubectl get pods -n arc-systems

В предыдущем проверочном workflow замените список меток на:

runs-on: arc-linux

Запустите workflow и наблюдайте за пространством имён раннеров:

kubectl get pods -n arc-runners -w

Ожидаемый по документации GitHub результат — работающий контроллер и под раннера, созданный для задачи. Сокращение числа подов раннеров до нуля не убирает постоянные расходы на кластер. Эти названия чартов и значения сверены с документацией GitHub по развёртыванию и значениями чарта; для этой статьи мы не развёртывали кластер.

Перед использованием в продакшене зафиксируйте проверенные версии чартов и образов, настройте сбор логов контроллера и раннеров и задайте запросы ресурсов подов в соответствии со своими сборками. Ограничьте доступ к секрету GitHub App. Для контейнерных задач выберите документированный режим ARC Docker-in-Docker или режим контейнеров Kubernetes и проверьте его привилегии. Минимальные значения выше не настраивают ни один из этих режимов.

Как настроить автомасштабирование self-hosted раннеров на AWS?

terraform-aws-github-runner — модуль Terraform с открытым исходным кодом, который автоматически масштабирует self-hosted раннеры на EC2 в вашем аккаунте AWS без Kubernetes. Его конфигурация на основе вебхуков получает события о задачах в очереди через GitHub App и использует Lambda и SQS для управления ресурсами по мере спроса. Он поддерживает одноразовые раннеры и инстансы Spot. Архитектура проекта.

Используйте пример проекта, подходящий для вашей конфигурации, и зафиксируйте версию модуля. Укажите свои VPC, подсети, GitHub App и образ раннера, затем проверьте разрешения IAM и план Terraform перед его применением. Предусмотрите прерывания задач Spot, сбои создания машин и оставшиеся без управления инстансы. Включите в счёт EC2, диски, логи, сетевые сервисы и ресурсы AWS, которые использует контроллер.

Выберите этот вариант, если политика требует размещать раннеры в вашем аккаунте AWS. Ваша команда по-прежнему обновляет образы и устраняет сбои. Мы не развёртывали эту конфигурацию Terraform для статьи.

Можно ли безопасно использовать self-hosted раннеры для публичных репозиториев?

По умолчанию — нет. GitHub рекомендует self-hosted раннеры только для приватных репозиториев, поскольку pull request из форка может выполнить на машине код, контролируемый злоумышленником. Приватные репозитории тоже требуют внимания: человек, которому разрешено создать форк и открыть pull request, может получить возможность запустить код в окружении вашего раннера. Рекомендации GitHub по безопасности.

Для изменений от внешних участников публичного проекта более безопасная отправная точка — раннеры под управлением GitHub. Не подключайте постоянную VM из этого руководства к публичному репозиторию. Если вам необходимо запускать недоверенный код на своей инфраструктуре, используйте отдельное изолированное одноразовое окружение для каждой задачи с ограниченными учётными данными и доступом к сети. Одна лишь одноразовая регистрация не создаёт такой границы изоляции.

• Не храните SSH-ключи, учётные данные облачного администратора и данные продакшена на дисках раннеров. По возможности используйте краткоживущие учётные данные с узкими полномочиями.
• Разделяйте репозитории с разным уровнем доверия с помощью групп раннеров и отдельных окружений выполнения. Пользовательская метка не является контролем доступа.
• Не выполняйте checkout и запуск недоверенного pull request в привилегированном workflow pull_request_target. Проверьте разрешения событий и политики согласования запусков из форков.
• Ограничьте доступ к внутренним сервисам и эндпоинтам метаданных облака. Разрешите доступ к эндпоинтам GitHub, нужным вашим задачам, и реестрам их зависимостей; даже только исходящие соединения позволяют похищать данные.
• Рассматривайте кэши как общее состояние. Не позволяйте недоверенным задачам записывать данные, которые позже выполнит привилегированная сборка.

Эти меры следуют рекомендациям GitHub по безопасному использованию. В справочнике по сетевому взаимодействию перечислены домены, необходимые для обновлений раннера, действий, логов, артефактов и кэшей.

Поддерживайте раннер и его образ в актуальном состоянии

Справочник GitHub требует обновлять раннеры с отключённым автоматическим обновлением в течение 30 дней после нового релиза, включая патч-релизы. GitHub прекращает направлять задачи в очередь устаревших раннеров; обязательное критическое обновление безопасности может заблокировать задачи раньше. Политика обновлений GitHub.

Обычно раннер обновляется сам. Используйте --disableupdate, только если ваша команда пересобирает образы раннеров в указанный срок. Обновления агента не обновляют Ubuntu, Docker или ваши инструменты сборки. Для обслуживания заменяйте машины или выводите их из приёма новых задач, не прерывая уже выполняющиеся задачи.

Почему раннер не в сети или задача ожидает?

Задача ожидает, когда нет свободного раннера в сети с подходящими метками и разрешённым уровнем регистрации или группой. Раннер не в сети перестал ожидать задачи или не может связаться с GitHub. В справочнике GitHub по маршрутизации сказано, что задачи завершаются ошибкой после более чем 24 часов в очереди.

Справочник GitHub по устранению неполадок описывает статус раннера, логи, сетевое подключение и разрешения Docker.

На машине с systemd просмотрите, например, последние 100 строк журнала, затем диагностические файлы и использование диска:

sudo ./svc.sh status
sudo journalctl -u "$(cat .service)" -n 100 --no-pager
ls -lt _diag/
df -h

В _diag файлы Runner_ описывают процесс ожидания задач, а файлы Worker_ — отдельные задачи. Сохраните их перед уничтожением одноразовых раннеров. Если задача так и не запустилась, читайте самый новый лог Runner_; если она запустилась и завершилась ошибкой, читайте её лог Worker_ и вывод задачи.

Сколько стоит машина для self-hosted раннера?

Заложите бюджет на машину и её обслуживание: обновления образов, очистку диска, мониторинг и неудачные задачи.

По состоянию на 4 ноября 2026 года документация GitHub по биллингу по-прежнему указывает, что вычисления на self-hosted раннерах бесплатны после отсрочки предложенной платы; о платежах и включённом использовании см. полный прайс-лист GitHub Actions.

Пример: одна постоянно работающая VM с Linux

4 ноября 2026 года в таблице цен Basic Regular Droplet от DigitalOcean были указаны 2 разделяемых vCPU, 4 GiB RAM, 80 GiB SSD и 4 000 GiB трафика за $24 в месяц. Согласно документации по биллингу, плата за Droplets с пакетными ресурсами продолжает начисляться, пока они выключены; уничтожьте Droplet, чтобы прекратить начисления.

Предположим, VM работает весь месяц в NYC3, где доступны Basic Droplets, выполняет сборки вашего приватного репозитория по одной, без бонусных средств и использования сверх пакета. Этот пример бюджета не учитывает налоги, резервные копии, снимки, дополнительное хранилище или трафик, платежи GitHub и время на обслуживание; он ничего не утверждает о производительности.

При этих допущениях строка счёта за VM остаётся $24 независимо от того, выполняет она редкие задачи или постоянно занята. Назначьте ответственного за её обслуживание, прежде чем полагаться на неё для релизов.

Сравнивайте полные месячные счета по недавней истории задач, включая простаивающие мощности и повторные попытки, и учитывайте включённый лимит раннеров под управлением GitHub перед сравнением платного использования.

Когда управляемый раннер — лучший выбор?

Раннеры GitHub Actions на Lizard запускают actions/runner от GitHub с JIT-конфигурацией в новой VM Firecracker для каждой задачи; после выполнения регистрация раннера удаляется. Lizard сохраняет диск кэша только для приватных репозиториев, а задачи из форков никогда его не используют. Pull request и другие ветки могут читать кэш, но сохранять в него могут только запуски по push, по расписанию и вручную на ветке по умолчанию.

Lizard Pro стоит $19 в месяц, включая налоги и использование на $19; это месячный минимум, а использование сверх него оплачивается по модели pay as you go. Время VM раннера оплачивается посекундно, включая подготовку и простой.

Раннеры Lizard поддерживают только Linux x64 на Ubuntu 24.04 и организации GitHub, а не личные аккаунты. Администратор организации устанавливает Lizard GitHub App. Для 7-дневного пробного периода нужна карта, в него включено использование на $5, и доступны только раннеры Small с лимитом до 4 vCPU одновременно; нагрузка приостанавливается после исчерпания пробного объёма использования, если вы не подключите Pro.

Используйте метку Small для пробной задачи:

runs-on: lizard-small-ubuntu-2404

Задачи Windows, macOS и ARM остаются на GitHub; для задач GPU выберите подходящего провайдера. Сравните производительность провайдеров, если важнее всего минимальное время сборки, используйте конфигурацию в своём облаке, если это необходимо, и сохраняйте бесплатные раннеры под управлением GitHub для публичных проектов, когда они отвечают вашим потребностям. См. сравнение управляемых раннеров и других CI-платформ.

На нашей сборке фронтенда Lizard был дешевле и медленнее; посмотрите замер сборки и настройку раннеров Lizard, затем попробуйте одну доверенную задачу Linux и сравните время выполнения, полный счёт и затраты на обслуживание.

Часто задаваемые вопросы

Как задать переменные окружения для self-hosted раннера GitHub Actions? Например, добавьте BUILD_MODE=test в actions-runner/.env, затем перезапустите службу с помощью sudo ./svc.sh stop и sudo ./svc.sh start. Используйте буквальные строки NAME=value, без export, подстановок оболочки или кавычек вокруг значений. В инструкции GitHub по прокси описано использование .env; парсер раннера читает его при запуске, а env.sh сохраняет PATH отдельно в .path. Задачи могут читать эти значения, поэтому для настроек задач используйте env: в workflow, а для учётных данных — секреты GitHub. Не включайте .env в систему контроля версий.

Бесплатны ли self-hosted раннеры GitHub? По состоянию на 4 ноября 2026 года GitHub не берёт плату за вычисления на self-hosted раннерах, согласно документации по биллингу. Вы по-прежнему платите за машину и её обслуживание.

Нужен ли self-hosted раннеру открытый входящий порт? Нет. Требования GitHub к сетевому взаимодействию предусматривают исходящий HTTPS на порту 443; раннеру не нужен входящий порт для вебхуков.

Как долго действует токен регистрации раннера? В инструкции GitHub по настройке раннера указан один час. Сгенерируйте новый токен, если регистрация не проходит из-за истечения его срока действия.