Waarom mijn eigen runner draaien in plaats van GitHub-hosted?

Drie echte redenen: je eigen dependencies en toolchain ingebakken (niet elke run opnieuw installeren), toegang tot private resources zoals een interne registry of database, en controle over de machine — zijn grootte, zijn caches, zijn netwerk. Als GitHub-hosted minuten en een schone omgeving je passen, blijf erbij. Zelf-host wanneer je specifiek een van die drie nodig hebt.

Hoeveel CPU en RAM heeft een runner nodig?

Hangt volledig af van je build. Een typische compile-and-test-job is comfortabel met 2 cores en 4-8 GB — Small of Medium hier. Zware builds (grote native compiles, grote Docker-images, geheugen-hongerige test-suites) willen meer, en je moet dimensioneren voor je echte job, niet een gok. Bekijk één echte run en je weet het.

Kan één runner meerdere repos aan?

Een runner kan geregistreerd worden bij een organisatie en opgepikt door meerdere repos, standaard één job per keer. Voor meer parallellisme, draai meer runners — elk is zijn eigen systemd-service. Houd ze allemaal maar op private repos.

Moet ik je een ID geven?

Nee. E-mail om aan te melden, USDC of USDT om te betalen. Geen documenten, root in ongeveer een minuut.

Een self-hosted GitHub Actions runner draaien op een VPS

Q: Is het veilig om een self-hosted runner te gebruiken?

Op een private repo, ja. Op een publieke repo, nee — nooit. Een workflow draait willekeurige code van wie het ook triggert, en op een publieke repo kan de pull request van een vreemde hun code op je runner draaien. GitHub's eigen docs zeggen hetzelfde. Houd self-hosted runners op private repos, of accepteer dat je je box aan het internet overhandigt.

GitHub-hosted runners zijn een prima standaard. Je stopt met ze nodig hebben op het moment dat een build iets wil dat ze niet hebben — je private package-registry, een specifieke toolchain-versie die je moe bent elke run opnieuw te installeren, een database op je eigen netwerk, of gewoon meer controle over de machine. Dat is wanneer een self-hosted runner op een VPS zijn geld waard is.

Deze gids krijgt er een goed draaiend: geïnstalleerd, geregistreerd, in leven onder systemd, en — het deel dat mensen verkeerd doen — veilig. Laten we met dat laatste beginnen, want het is het deel dat bijt.

De ene security-regel

Een GitHub Actions-workflow draait willekeurige code — wat er ook in het workflow-bestand staat, en wat die code binnenhaalt. Op je eigen repo is dat je code, en het is prima. Op een publieke repo kan een pull request van een vreemde hun code op je runner draaien. Dat is geen bug; zo werkt CI. GitHub's eigen documentatie zegt het duidelijk: gebruik geen self-hosted runners met publieke repositories.

Dus de regel is simpel en niet-onderhandelbaar: self-hosted runners zijn voor private repos. Als je repo publiek is, gebruik GitHub-hosted runners en ga door. Alles hieronder gaat uit van een private repo.

Wat een runner nodig heeft van de box

Het hangt af van de build, en je moet voor die van jou dimensioneren in plaats van een getal van een pagina:

Een typische compile-and-test-job — 2 cores en 4-8 GB is comfortabel. Small ($8, 4 vCPU / 4 GB) of Medium ($12, 6 vCPU / 6 GB) dekt de meeste hiervan.
Zwaardere builds — grote native compiles, grote Docker-image-builds, geheugen-hongerige test-suites — willen meer ruimte. Bekijk één echte run (htop terwijl het bouwt) en dimensioneer voor wat je werkelijk ziet, niet voor hoop.

Schijf doet er ook toe: build-caches, Docker-layers, en gekloonde repos stapelen op. Houd een oogje erop en prune.

1. Bereid de box voor

Maak een non-root-gebruiker voor de runner — GitHub's installer weigert sowieso als root te draaien, en je wilt het zo:

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

Installeer wat je builds nodig hebben — een taal-toolchain, Docker, build-tools. Bijvoorbeeld, als je jobs containers bouwen:

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

2. Download en registreer de runner

In je repo (of org) op GitHub, ga naar Settings → Actions → Runners → New self-hosted runner. GitHub geeft je de exacte download-commando's en een registratie-token (het is kortlevend — pak het vers). Als de runner-gebruiker:

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 vraagt om een runner-naam, labels, en een work-folder — de standaarden zijn prima om te beginnen. Labels zijn hoe je workflow deze runner target (runs-on: self-hosted).

3. Draai hem als een systemd-service

De runner komt met een helper die een systemd-service voor je installeert — gebruik hem, zodat de runner reboots overleeft en herstart bij falen. Nog steeds als de install van de runner-gebruiker, maar de service-commando's hebben root nodig:

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

Dat registreert actions.runner.* als een systemd-unit die draait als de runner-gebruiker, startend bij boot. Logs gaan naar journald:

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

Terug op GitHub's Runners-pagina toont je runner nu Idle — groene stip. Richt een workflow erop:

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

Push, en de job draait op je box.

4. Houd het schoon

Een self-hosted runner hergebruikt zijn filesystem tussen jobs — dat is de snelheidswinst (warme caches) en de footgun (achtergebleven state). Twee gewoontes houden het gezond:

Prune regelmatig. Docker vooral — docker system prune op een cron, of schijf vult stilletjes met dode layers.
Sla geen secrets op de box op. Gebruik GitHub Actions secrets, per-run geïnjecteerd, geen bestanden in de home van de runner. Als de runner gecompromitteerd is, gaat alles op schijf mee.

Als je een echt schone omgeving per job nodig hebt, draai elke job binnen een container-step — de runner blijft, de rommel van de job niet.

Wanneer zelf-hosten, eerlijk

Zelf-host wanneer je je eigen toolchain ingebakken nodig hebt, toegang tot private netwerk-resources, of controle over de machine. Blijf op GitHub-hosted runners wanneer een schone, wegwerp-omgeving en hun minuten je passen — dat is genuine simpeler, en simpeler is iets waard. En nooit, op een publieke repo, zelf-host. Die is geen voorkeur.

Als een private-repo-runner is wat je nodig hebt: kies een plan — Small ($8) voor lichtere builds, Medium ($12) wanneer ze zwaarder worden — betaal in USDC of USDT (geen KYC, geen documenten), en je hebt root in ongeveer 60 seconden. Werk dan deze pagina af en je hebt een runner die een paar minuten later jobs oppikt.

Bekijk het plan & bestel een VPS →