Cum rulez un runner GitHub Actions propriu pe un VPS?

Pornești un VPS Linux (Small — 4 vCPU / 4 GB — e alegerea implicită rezonabilă), instalezi pachetul runnerului din Settings → Actions → Runners al repository-ului, îl înregistrezi cu tokenul primit de la GitHub și îl pornești ca serviciu. Pașii completi, de copiat, sunt mai jos; primești root în aproximativ un minut.

Pot rula runnerul în Docker?

Da. Rulezi imaginea oficială a runnerului (sau pe a ta) într-un container ori o folosești ca să dai fiecărei sarcini un mediu izolat, de unică folosință. Nu e nevoie de un plan cu IP dedicat — runnerul face doar conexiuni de ieșire spre GitHub, deci merge și un plan NAT.

Cum țin runnerul pornit ca serviciu?

Runnerul vine cu un ajutor svc.sh care instalează o unitate systemd: ./svc.sh install && ./svc.sh start. Apoi supraviețuiește repornirilor și repornește singur la erori. Ghidul de mai jos arată comenzile exacte.

E un runner propriu mai ieftin decât minutele găzduite de GitHub?

Pentru CI greu sau frecvent, da. Runnerele găzduite de GitHub se taxează la minut peste planul gratuit; un VPS de $8/lună rulează minute nelimitate la preț fix și rămâne „cald” (fără pornire la rece, dependențe în cache). Un singur repository aglomerat plătește de obicei serverul.

Cereți act de identitate sau card?

Nu. Te înregistrezi cu un e-mail și plătești cu USDC sau USDT. Fără documente, fără card, fără KYC — niciodată.

VPS pentru runnere GitHub Actions găzduite de tine

Rulează propriul runner GitHub Actions pe un VPS — CI mai rapid, fără plată la minut, control complet asupra mediului de build. Plată cripto, fără KYC. De la $8/lună.

Runnerele găzduite de GitHub sunt comode până când factura sau timpul de așteptare încep să doară. Peste planul gratuit plătești la minut, fiecare sarcină pornește la rece și dependențele se descarcă din nou la fiecare rulare. Un runner propriu pe VPS-ul tău le întoarce pe toate trei: cost lunar fix, o mașină caldă cu cache-urile deja pe disc și un mediu de build pe care îl controlezi complet — versiuni exacte ale uneltelor, mai multă RAM, cache de straturi Docker care chiar persistă.

Un runner trebuie doar să ajungă la GitHub spre exterior, așa că merge pe cele mai ieftine planuri ale noastre, se plătește cu cripto și nu cere KYC.

De ce are nevoie un runner

CPU și RAM pentru builduri. Small ($8/lună — 4 vCPU, 4 GB RAM, 35 GB NVMe) e alegerea implicită comodă pentru majoritatea CI-urilor: builduri Node/Go/Rust, suite de teste, construirea imaginilor Docker. Compilare grea sau sarcini în paralel? Urcă la Medium sau la un plan Pro.
Disc NVMe pentru cache-uri. Tot rostul găzduirii proprii e persistența — cache-urile de dependențe, straturile Docker și artefactele de build rămân pe disc între rulări. NVMe-ul ține restaurările rapide.
Nu e nevoie de IP dedicat. Runnerul se conectează spre GitHub prin HTTPS; nimic nu trebuie să ajungă la el din afară. Un plan NAT (de la $3/lună) ajunge. Ia IP dedicat doar dacă mai găzduiești ceva care servește trafic.

Configurează un runner (Ubuntu 24.04)

Creează runnerul în repository (sau în organizație): Settings → Actions → Runners → New self-hosted runner → Linux. GitHub îți arată o comandă de descărcare și un token de înregistrare de unică folosință. Pe VPS:

# as a non-root user (the runner refuses to run as 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

# register with the URL + token from the GitHub UI
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

Ține-l pornit ca serviciu

Nu rula ./run.sh într-un terminal — instalează-l ca serviciu systemd, ca să supraviețuiască repornirilor:

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

Runnerul apare acum ca Idle în interfața GitHub și preia orice sarcină care îl țintește.

Folosește-l dintr-un workflow

Îndreaptă o sarcină spre runnerul tău cu runs-on:

jobs:
  build:
    runs-on: self-hosted        # or a custom label you set at registration
    steps:
      - uses: actions/checkout@v4
      - run: make build && make test

Sarcini cu Docker

Instalezi Docker o dată, iar workflow-urile tale pot construi imagini sau rula containere de servicii, cu cache-ul de straturi păstrat între rulări:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner   # let the runner use Docker without sudo

Pentru izolare de unică folosință per sarcină, rulează runnerul însuși într-un container și recreează-l la fiecare rulare — un tipar obișnuit pentru builduri de matrice sau cod în care nu ai încredere.

De ce EQVPS pentru CI

Cost fix, minute nelimitate. Fără contorizare la minut — un pipeline aglomerat costă cât unul care stă.
Cache-uri calde. Dependențele și straturile Docker rămân pe NVMe între rulări; buildurile devin mai rapide, nu mai lente.
Root în ~60 de secunde, imagini curate. Ubuntu, Debian și altele prin cloud-init; instalezi exact uneltele de care ai nevoie.
Fără KYC, plată cripto. E-mail la înregistrare, USDC/USDT la plată. Pornești runnere în plus pentru perioadele aglomerate dinaintea unui release și le anulezi după — timpul plătit și nefolosit intră înapoi în sold.

Ghidul complet de configurare, pas cu pas →