Защо да пускам собствен runner вместо GitHub-хостнат?

Три реални причини: собствените ти зависимости и toolchain вградени (без реинсталиране на всяко изпълнение), достъп до частни ресурси като вътрешен registry или база данни, и контрол над машината — размера ѝ, кешовете ѝ, мрежата ѝ. Ако GitHub-хостнатите минути и чиста среда ти пасват, остани на тях. Хоствай сам, когато специфично се нуждаеш от едно от тези три.

Безопасно ли е да използвам self-hosted runner?

На частен repo, да. На публичен repo, не — никога. Workflow пуска произволен код от когото го задейства, а на публичен repo pull request на непознат може да пусне неговия код на runner-а ти. Собствената документация на GitHub казва същото. Дръж self-hosted runners за частни repos, или приеми, че предаваш машината си на интернет.

Колко CPU и RAM се нуждае runner?

Зависи изцяло от build-а ти. Типична задача компилирай-и-тествай е комфортна с 2 ядра и 4-8 GB — Small или Medium тук. Тежки build-ове (големи native компилации, големи Docker образи, гладни за памет test suites) искат повече, и трябва да оразмериш за реалната си задача, не за предположение. Гледай едно реално изпълнение и ще знаеш.

Може ли един runner да обработва няколко repos?

Runner може да бъде регистриран на организация и взет от няколко repos, една задача наведнъж по подразбиране. За повече паралелизъм, пусни повече runners — всеки е собствена systemd услуга. Просто ги дръж всички на частни repos.

Трябва ли да ви дам документ?

Не. Имейл за регистрация, USDC или USDT за плащане. Без документи, root за около минута.

Пускане на self-hosted GitHub Actions runner на VPS

GitHub-хостнатите runners са добър избор по подразбиране. Спираш да се нуждаеш от тях в мига, в който build иска нещо, което те нямат — частния ти package registry, конкретна версия на toolchain, която ти е омръзнало да реинсталираш всяко изпълнение, база данни на собствената ти мрежа, или просто повече контрол над машината. Тогава self-hosted runner на VPS си заслужава.

Това ръководство пуска един както трябва: инсталиран, регистриран, жив под systemd, и — частта, която хората грешат — безопасен. Нека започнем от последната, защото тя е частта, която хапе.

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

GitHub Actions workflow пуска произволен код — каквото е в workflow файла, и каквото този код издърпа. На собствения ти repo това е твоят код, и е наред. На публичен repo, pull request от непознат може да пусне неговия код на runner-а ти. Това не е бъг; така работи CI. Собствената документация на GitHub казва ясно: не използвай self-hosted runners с публични repositories.

Така че правилото е просто и ненегоцируемо: self-hosted runners са за частни repos. Ако repo-то ти е публично, използвай GitHub-хостнати runners и продължи. Всичко по-долу предполага частен repo.

Какво runner се нуждае от машината

Зависи от build-а, и трябва да оразмериш за твоя, вместо число от страница:

Типична задача компилирай-и-тествай — 2 ядра и 4-8 GB е комфортно. Small ($8, 4 vCPU / 4 GB) или Medium ($12, 6 vCPU / 6 GB) покриват повечето от тези.
По-тежки build-ове — големи native компилации, build-ове на големи Docker образи, гладни за памет test suites — искат повече запас. Гледай едно реално изпълнение (htop, докато build-ва) и оразмери за това, което реално виждаш, не за надежда.

Дискът също има значение: build кешове, Docker layers и клонирани repos се натрупват. Дръж око и прунвай.

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

Създай non-root потребител за runner-а — инсталаторът на GitHub така или иначе се отказва да работи като root, и го искаш така:

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # only if your builds genuinely need sudo

Инсталирай каквото build-овете ти се нуждаят — toolchain на език, Docker, build tools. Например, ако задачите ти строят контейнери:

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

2. Свали и регистрирай runner-а

В repo-то ти (или org) на GitHub, отиди на Settings → Actions → Runners → New self-hosted runner. GitHub ти дава точните команди за сваляне и регистрационен токен (той е с кратка давност — вземи го свеж). Като потребителя runner:

sudo -iu runner
mkdir actions-runner && cd actions-runner
# use the exact URL GitHub shows you for your OS/arch:
curl -o actions-runner-linux-x64.tar.gz -L "URL_FROM_GITHUB"
tar xzf actions-runner-linux-x64.tar.gz
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

config.sh пита за име на runner, labels и work folder — по подразбиране са наред за начало. Labels са как workflow-ът ти таргетира този runner (runs-on: self-hosted).

3. Пусни го като systemd услуга

Runner-ът идва с helper, който инсталира systemd услуга вместо теб — използвай го, така че runner-ът да преживява рестарти и да рестартира при провал. Все още от инсталацията на потребителя runner, но командите на услугата се нуждаят от root:

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

Това регистрира actions.runner.* като systemd unit, работещ като потребителя runner, стартиращ при boot. Логовете отиват в journald:

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

Обратно в страницата Runners на GitHub, runner-ът ти сега показва Idle — зелена точка. Насочи workflow към него:

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

Push, и задачата се пуска на машината ти.

4. Дръж го чист

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

Прунвай редовно. Docker особено — docker system prune на cron, или дискът се пълни тихо с мъртви layers.
Не съхранявай secrets на машината. Използвай GitHub Actions secrets, инжектирани за-run, не файлове, седящи в home-а на runner-а. Ако runner-ът е компрометиран, всичко на диска си отива с него.

Ако се нуждаеш от наистина чиста среда за всяка задача, пусни всяка задача вътре в container step — runner-ът остава, бъркотията на задачата не.

Кога да хоствам сам, честно

Хоствай сам, когато се нуждаеш от собствения си toolchain вграден, достъп до частни мрежови ресурси, или контрол над машината. Остани на GitHub-хостнати runners, когато чиста, за изхвърляне среда и минутите им ти пасват — това е генуинно по-просто, и по-простото струва нещо. И никога, на публичен repo, не хоствай сам. Това не е предпочитание.

Ако runner за частен repo е това, което ти трябва: избери план — Small ($8) за по-леки build-ове, Medium ($12), когато станат по-тежки — плати в USDC или USDT (без KYC, без документи), и ще имаш root за около 60 секунди. После работи надолу по тази страница и ще имаш runner, взимащ задачи няколко минути по-късно.

Виж плана и поръчай VPS →