Jak uruchomić samodzielnie hostowany runner GitHub Actions na VPS?

Zaprowidżuj VPS z Linuksem (Small — 4 vCPU / 4 GB — to rozsądny domyślny wybór), zainstaluj pakiet runnera z Settings → Actions → Runners swojego repozytorium, zarejestruj go tokenem, który daje GitHub, i uruchom jako usługę. Pełne kroki do skopiowania są poniżej; root otrzymujesz w około minutę.

Czy mogę uruchomić runner w Dockerze?

Tak. Uruchom oficjalny obraz runnera (lub własny) w kontenerze albo użyj go, by dać każdemu zadaniu izolowane, jednorazowe środowisko. Dedykowany IP nie jest wymagany — runner nawiązuje tylko połączenia wychodzące do GitHuba, więc plan NAT też wystarczy.

Jak utrzymać runner działający jako usługa?

Runner zawiera skrypt pomocniczy svc.sh, który instaluje jednostkę systemd: ./svc.sh install && ./svc.sh start. Potem przetrwa restarty i uruchomi się ponownie po awarii. Dokładne polecenia są w przewodniku poniżej.

Czy samodzielnie hostowany runner jest tańszy niż minuty hostowane przez GitHub?

Przy ciężkim lub częstym CI tak. Runnery hostowane przez GitHub rozliczają się za minutę powyżej darmowego limitu; VPS za $8/mies uruchamia nieograniczone minuty za stałą opłatę i pozostaje „ciepły” (bez zimnego startu, z zależnościami w pamięci podręcznej). Jedno aktywne repozytorium zwykle spłaca maszynę.

Czy pytacie o dokument tożsamości lub kartę kredytową?

Nie. Rejestracja przez e-mail, płatność w USDC lub USDT. Bez dokumentów, bez karty, nigdy KYC.

VPS dla samodzielnie hostowanych runnerów GitHub Actions

Uruchom własny samodzielnie hostowany runner GitHub Actions na VPS — szybsze CI, bez rozliczeń za minutę, pełna kontrola nad środowiskiem budowania. Płatność kryptowalutą, bez KYC. Od $8/mies.

Runnery hostowane przez GitHub są wygodne, dopóki rachunek albo czas oczekiwania nie zaczną boleć. Powyżej darmowego limitu płacisz za minutę, każde zadanie startuje „na zimno” i za każdym razem pobiera zależności od nowa. Samodzielnie hostowany runner na twoim własnym VPS odwraca wszystkie trzy punkty: stały koszt miesięczny, „ciepła” maszyna z twoimi cache'ami już na dysku i środowisko budowania, które w pełni kontrolujesz — konkretne wersje narzędzi, więcej RAM, cache warstw Dockera, który naprawdę się utrzymuje.

Runner potrzebuje tylko połączenia wychodzącego do GitHuba, więc działa na naszych najtańszych planach, płaci się kryptowalutą i nie wymaga KYC.

Czego potrzebuje runner

CPU i RAM na twoje buildy. Small ($8/mies — 4 vCPU, 4 GB RAM, 35 GB NVMe) to wygodny domyślny wybór dla większości CI: buildy Node/Go/Rust, zestawy testów, buildy obrazów Dockera. Ciężka kompilacja lub równoległe zadania? Przejdź na Medium lub plan Pro.
Dysk NVMe na cache. Cały sens samodzielnego hostowania to trwałość — cache zależności, warstwy Dockera i artefakty buildów zostają na dysku między uruchomieniami. NVMe utrzymuje szybkie przywracanie.
Dedykowany IP niepotrzebny. Runner dzwoni do GitHuba przez HTTPS; dostęp przychodzący nie jest potrzebny. Wystarczy plan NAT (od $3/mies). Weź dedykowany IP tylko, jeśli hostujesz też coś, co serwuje ruch.

Konfiguracja runnera (Ubuntu 24.04)

Utwórz runner w repozytorium (lub organizacji): Settings → Actions → Runners → New self-hosted runner → Linux. GitHub pokazuje polecenie pobrania i jednorazowy token rejestracji. Na VPS:

# jako użytkownik nie-root (runner odmawia działania jako root)
adduser --disabled-password --gecos "" runner
su - runner

mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64.tar.gz -L \
  https://github.com/actions/runner/releases/latest/download/actions-runner-linux-x64.tar.gz
tar xzf actions-runner-linux-x64.tar.gz

# zarejestruj z URL + tokenem z interfejsu GitHuba
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

Utrzymanie jako usługa

Nie uruchamiaj ./run.sh w terminalu — zainstaluj runner jako usługę systemd, by przetrwał restarty:

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

Runner pojawia się teraz jako Idle w interfejsie GitHuba i podejmuje każde zadanie skierowane do niego.

Użycie z workflow

Skieruj zadanie do swojego runnera przez runs-on:

jobs:
  build:
    runs-on: self-hosted        # lub własna etykieta ustawiona przy rejestracji
    steps:
      - uses: actions/checkout@v4
      - run: make build && make test

Zadania oparte na Dockerze

Zainstaluj Dockera raz, a twoje workflow będą mogły budować obrazy lub uruchamiać kontenery usług, z cache'em warstw utrzymywanym między uruchomieniami:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner   # pozwól runnerowi używać Dockera bez sudo

Dla jednorazowej izolacji na zadanie uruchom sam runner w kontenerze i twórz go od nowa przy każdym uruchomieniu — częsty wzorzec dla niezaufanych lub macierzowych buildów.

Dlaczego EQVPS do CI

Stały koszt, nieograniczone minuty. Bez pomiaru za minutę — zajęty pipeline kosztuje tyle samo, co bezczynny.
„Ciepłe” cache. Zależności i warstwy Dockera zostają na NVMe między uruchomieniami; buildy przyspieszają, a nie zwalniają.
Root w ~60 sekund, czyste obrazy. Ubuntu, Debian i więcej przez cloud-init; zainstaluj dokładnie ten toolchain, którego potrzebujesz.
Bez KYC, płatność kryptowalutą. E-mail do rejestracji, USDC/USDT do zapłaty. Uruchamiaj dodatkowe runnery na szczyty wydań i anuluj je później.

Pełny przewodnik konfiguracji krok po kroku →