Зачем свой раннер вместо GitHub-hosted?

Три реальные причины: свои зависимости и тулчейн уже вшиты (не переустанавливать каждый прогон), доступ к приватным ресурсам вроде внутреннего реестра или базы и контроль над машиной — её размер, кеши, сеть. Если минуты GitHub-hosted и чистое окружение вас устраивают — оставайтесь на них. Self-host, когда конкретно нужно одно из этих трёх.

Безопасно ли использовать self-hosted раннер?

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

Сколько CPU и RAM нужно раннеру?

Целиком зависит от сборки. Типичная задача «собрать и протестировать» комфортна на 2 ядрах и 4-8 ГБ — Small или Medium здесь. Тяжёлым сборкам (крупная нативная компиляция, большие Docker-образы, прожорливые тест-сьюты) нужно больше, и считать надо под свою реальную задачу, а не по догадке. Посмотрите один реальный прогон — и узнаете.

Один раннер может обслуживать несколько репо?

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

Нужен ли документ?

Нет. Email для регистрации, USDC или USDT для оплаты. Ни документов, root примерно за минуту.

Свой self-hosted раннер GitHub Actions на VPS

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

Этот гайд поднимает его как надо: установлен, зарегистрирован, жив под systemd и — та часть, в которой ошибаются, — безопасен. Начнём с последнего, потому что именно это кусается.

Единственное правило безопасности

Воркфлоу GitHub Actions выполняет произвольный код — всё, что в файле воркфлоу, и всё, что этот код тянет. На вашем репо это ваш код, и всё нормально. На публичном репо pull request от чужака может выполнить его код на вашем раннере. Это не баг; так устроен CI. Документация GitHub прямо говорит: не используйте self-hosted раннеры с публичными репозиториями.

Так что правило простое и без исключений: self-hosted раннеры — для приватных репо. Если репозиторий публичный, используйте GitHub-hosted раннеры и не думайте. Всё ниже предполагает приватный репозиторий.

Что раннеру нужно от машины

Зависит от сборки, и считать надо под свою, а не по цифре со страницы:

Типичная задача «собрать и протестировать» — 2 ядра и 4-8 ГБ комфортны. Small ($8, 4 vCPU / 4 ГБ) или Medium ($12, 6 vCPU / 6 ГБ) покрывают большинство.
Тяжёлые сборки — крупная нативная компиляция, сборка больших Docker-образов, прожорливые тест-сьюты — просят больше запаса. Посмотрите один реальный прогон (htop во время сборки) и считайте по тому, что реально видите, а не по надежде.

Диск тоже важен: кеши сборки, слои Docker и склонированные репо накапливаются. Держите на глазу и чистите.

1. Подготовить машину

Создайте не-root пользователя для раннера — установщик GitHub всё равно откажется работать под root, и это правильно:

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # только если сборкам реально нужен sudo

Поставьте то, что нужно сборкам — тулчейн языка, Docker, инструменты сборки. Например, если задачи собирают контейнеры:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner

2. Скачать и зарегистрировать раннер

В вашем репо (или организации) на GitHub зайдите в Settings → Actions → Runners → New self-hosted runner. GitHub выдаст точные команды загрузки и токен регистрации (он короткоживущий — берите свежий). Под пользователем runner:

sudo -iu runner
mkdir actions-runner && cd actions-runner
# используйте точный URL, который GitHub показал под вашу ОС/архитектуру:
curl -o actions-runner-linux-x64.tar.gz -L "URL_ОТ_GITHUB"
tar xzf actions-runner-linux-x64.tar.gz
./config.sh --url https://github.com/ВАША_ORG/ВАШ_REPO --token ВАШ_ТОКЕН

config.sh спросит имя раннера, метки и рабочую папку — для старта дефолты подойдут. Метки — то, как воркфлоу нацеливается на этот раннер (runs-on: self-hosted).

3. Запустить как сервис systemd

Раннер идёт с помощником, который ставит сервис systemd за вас — используйте его, чтобы раннер переживал перезагрузки и рестартовал при падении. Всё под установкой пользователя runner, но команды сервиса требуют root:

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

Это регистрирует actions.runner.* как unit systemd, работающий от пользователя runner, со стартом при загрузке. Логи идут в journald:

sudo journalctl -u 'actions.runner.*' -f

Обратно на странице Runners в GitHub ваш раннер теперь показывает Idle — зелёная точка. Нацельте на него воркфлоу:

jobs:
  build:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - run: make test

Пушьте — и задача выполнится на вашей машине.

4. Держать в чистоте

Self-hosted раннер переиспользует свою файловую систему между задачами — это выигрыш в скорости (тёплые кеши) и грабли (остаточное состояние). Две привычки держат его здоровым:

Регулярно чистите. Особенно Docker — docker system prune по крону, иначе диск тихо забивается мёртвыми слоями.
Не храните секреты на машине. Используйте secrets GitHub Actions, инжектящиеся на каждый прогон, а не файлы в домашней папке раннера. Если раннер скомпрометируют, всё на диске уйдёт вместе с ним.

Если нужно по-настоящему чистое окружение на каждую задачу — запускайте каждую внутри шага-контейнера: раннер остаётся, а мусор задачи — нет.

Когда self-host, честно

Self-host, когда нужен свой тулчейн вшитым, доступ к приватным ресурсам сети или контроль над машиной. Оставайтесь на GitHub-hosted раннерах, когда чистое одноразовое окружение и их минуты вас устраивают — это правда проще, а простота чего-то стоит. И никогда, на публичном репо, не делайте self-host. Это не вопрос предпочтений.

Если нужен раннер под приватный репо: выберите тариф — Small ($8) для лёгких сборок, Medium ($12), когда тяжелеют, — оплатите в USDC или USDT (без KYC, без документов), и root будет примерно за 60 секунд. Дальше идите по этой странице — и через пару минут раннер начнёт подхватывать задачи.