Waarom GitHub Actions traag is, en hoe je het sneller maakt

Het grootste deel van een trage GitHub Actions-job gebeurt vóór de eerste test. Node instellen, de dependencies downloaden, de Docker-image bouwen: dezelfde minuten, bij elke push, terwijl iemand in je team op een groen vinkje wacht. Bij facturering per minuut betaal je ook voor die minuten.

Skipbox is een GitHub Actions-runner die zijn machine tussen jobs bewaart, dus wat de ene job installeerde, staat voor de volgende nog op de schijf. Wijzig één regel, runs-on: skipbox, en de job draait op je eigen machine voor een vaste $39 per maand met onbeperkte minuten.

Elke job start op een lege VM

Een door GitHub gehoste runner is voor elke job een nieuwe virtuele machine. Niets van wat de vorige job downloadde of bouwde staat erop, dus elke job bouwt dezelfde toestand opnieuw op:

De eerste drie rijen leveren niets nieuws op. Ze zetten de machine terug waar hij gisteren was.

De cache van GitHub verzacht dit zonder het te veranderen. Hij houdt 10 GB per repository vast, verwijdert items die 7 dagen door geen job zijn gelezen, en een nieuwe featurebranch kan de cache van een andere featurebranch niet lezen. Zelfs bij een hit downloadt elke run een archief en pakt het uit.

Wat het wachten je kost

Stel dat de setup 3 minuten van elke job kost en je team 100 jobs per dag draait. Dat is 300 minuten runnertijd per dag om de machine terug te zetten, en elke pull request wacht op zijn deel daarvan. Reviews beginnen later, merges landen later, en engineers gaan iets anders doen terwijl ze wachten.

Bij facturering per minuut staan die minuten op de factuur. Een runner met 4 vCPU, naar minuten per maand:

De bedragen van GitHub zijn de rekening na het inbegrepen gebruik van GitHub Team. Vul je eigen minuten in bij de calculator op de startpagina; inloggen is niet nodig.

En het aantal runs gaat alleen maar omhoog:

• AI-codeeragents. Elke push van een agent start CI. Het wachten en de rekening groeien met de pushes, niet met het aantal mensen.
• Meer tests. Een E2E-suite of een matrix herhaalt de setup in elke job die hij toevoegt.
• Budgetten. Begrens je de rekening met een GitHub-budget, dan starten jobs halverwege de maand niet meer, en stoppen de merges.

Het zelf sneller maken is een project

GitHub-gehoste runners houden en ze snel maken betekent dat je dit soort werk op je neemt:

• Caches een key geven op basis van de hash van lockfiles en restore-keys afstellen tot ze raak zijn
• buildx toevoegen en de cache van Docker exporteren met cache-to, binnen dezelfde 10 GB
• Tests opsplitsen in shards, waarbij elke shard de setup herhaalt en de gerekende minuten stijgen
• Of je eigen self-hosted runner draaien: inrichten, OS-updates, opruimen tussen jobs, en hem repareren als hij uitvalt

Elk daarvan werkt om een machine heen die alles vergeet. Skipbox houdt de machine, dus niets daarvan is nodig.

Wat er op Skipbox verandert

De setup blijft op de schijf. Je jobs draaien op de eigen machine van je account, en die blijft tussen jobs bestaan. Docker-images, layers en buildcache; packagecaches voor npm, pip, Gradle en meer; de tools die setup-node en verwanten installeren. Minstens 7× de cacheruimte van GitHub, zonder verloop na 7 dagen en zonder branchregel.

Grotere machines voor een vaste prijs. Compilers en testrunners starten één worker per core, dus meer cores maken de CPU-gebonden steps korter.

De minuten zijn op elk abonnement onbeperkt. Jobs op Skipbox gebruiken geen GitHub-minuten, dus een GitHub-budget houdt ze nooit tegen.

Geen machine om naar om te kijken. Skipbox richt de machine in, werkt het OS en de tools bij, ruimt na elke job op, draait een health check en bouwt een machine die daarvoor zakt opnieuw op.

Overstappen kost één regel

jobs:
  build:
    runs-on: skipbox # was ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

1. Log in bij Skipbox met GitHub.
2. Installeer de GitHub-app van Skipbox en kies de repository's.
3. Wijzig runs-on en push.

Wat de eerste job installeert, staat op de schijf voor de tweede.

Beveiliging

• De machine is alleen van je account. Er draaien geen jobs van een ander bedrijf op.
• Na elke job worden de credentials, processen en containers van de runner gewist. Vanaf 13 november 2026 blijven je checkout en de builduitvoer ervan (target/ van Cargo) op je eigen machine staan voor je volgende jobs; met Schone VM per job krijgt elke job een nieuwe machine.
• Code van mensen zonder schrijfrechten (zoals pull requests vanuit forks) draait op een nieuwe wegwerpmachine.

De details staan in zo worden jobs geïsoleerd.

Probeer het op je traagste job

De proefperiode is gratis voor 7 dagen of 3.000 jobminuten, wat het eerst komt, en er is geen kaart voor nodig. Zet je traagste job op runs-on: skipbox, draai hem twee keer achter elkaar en leg de tijden per step naast die van GitHub.

Bijgewerkt op 11 november 2026