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

> GitHub Actions is traag omdat elke job op een lege VM start en eerst zijn tools downloadt, zijn dependencies opnieuw installeert en zijn Docker-images opnieuw bouwt, nog vóór de eerste test. Skipbox bewaart dat allemaal tussen jobs op je eigen machine, voor een vaste $39 per maand met onbeperkte minuten: bij 20.000 minuten op 4 vCPU is dat $183 per maand minder dan GitHub.

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.

- Dependencies, Docker-layers en tools blijven op de schijf staan, dus jobs slaan het downloaden en opnieuw bouwen over
- Minstens 7× de cacheruimte van GitHub, zonder verloop na 7 dagen en zonder cache keys om af te stellen
- 20.000 minuten per maand op 4 vCPU: $222 op GitHub, $39 op Skipbox

**GitHub Actions voor een vaste prijs, onbeperkte minuten** Skipbox draait je GitHub Actions-jobs op je eigen dedicated machine: $39 per maand, hoeveel minuten je ook draait. Docker-layers en dependencycaches blijven tussen jobs bewaard, dus de volgende job start meteen.

Een runner met 4 vCPU, 20.000 minuten per maand: GitHub $222 → Skipbox $39. Je bespaart elke maand $183.

Overstappen kost één regel: `runs-on: skipbox`.

[Gratis 7-daagse proefperiode starten](https://app.skipbox.dev/sign-in?ref=g-github-actions-slow-nl)

## 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:

| Step | Door GitHub gehoste runner | Skipbox |
|---|---|---|
| Node, Python, Java instellen | Downloadt de toolchain | Vindt hem in de toolcache van de vorige job |
| Dependencies installeren | Downloadt het cachearchief en pakt het uit; bij een miss de hele download uit de registry | Leest de cache van de packagemanager van de schijf |
| De Docker-image bouwen | Begint zonder layers en bouwt elke stap opnieuw | Hergebruikt de layers van de vorige build |
| De tests draaien | 2 CPU's op `ubuntu-latest` van een privé-repository | Vanaf 4 vCPU |

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:

| Minuten per maand (4 vCPU) | GitHub | Skipbox S | Je bespaart per maand |
|---|---|---|---|
| 10.000 | $102 | $39 | **$63** |
| 20.000 | $222 | $39 | **$183** |
| 30.000 | $342 | $39 | **$303** |

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](https://skipbox.dev/?ref=g-github-actions-slow-nl#cost); 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.

| Abonnement | Machine | Prijs |
|---|---|---|
| S | 4 vCPU · 16 GB | $39 per maand |
| M | 8 vCPU · 16 GB | $79 per maand |
| L | 16 vCPU · 32 GB | $149 per maand |

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

```yaml
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](https://docs.skipbox.dev/isolation).

## 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.

## Veelgestelde vragen

### Waarom is GitHub Actions zo traag?

Elke job op een door GitHub gehoste runner start op een nieuwe VM zonder iets van de vorige run, dus hij downloadt zijn tools, installeert zijn dependencies opnieuw en bouwt zijn Docker-images opnieuw voordat je tests beginnen. Skipbox draait je jobs op de eigen machine van je account en houdt die toestand op de schijf, dus de volgende job begint waar de vorige ophield.

### Ik heb actions/cache toegevoegd. Waarom is mijn workflow nog steeds traag?

Ook bij een cache hit downloadt elke job een archief en pakt hij het uit, omdat de VM elke keer nieuw is. En de cache van GitHub houdt 10 GB per repository vast, verwijdert items die 7 dagen niet zijn gebruikt, en kan niet worden gelezen vanuit een naastliggende branch. Op Skipbox staan de packagecaches en Docker-layers al op de schijf van de machine, zonder keys om te beheren.

### Hoe maak ik Docker-builds in GitHub Actions sneller?

Geef de build de layers van de vorige build. Op door GitHub gehoste runners betekent dat de cache met buildx exporteren en hem bij elke run importeren, binnen dezelfde limiet van 10 GB. Op Skipbox blijven de images en buildcache van Docker tussen jobs op de machine staan, dus docker build hergebruikt de layers vanzelf.

### Moet ik mijn workflows herschrijven om Skipbox te gebruiken?

Nee. Wijzig voor Linux-jobs runs-on in skipbox. De machine draait Ubuntu 24.04 met Docker, Node.js en Python, en je steps en actions draaien zoals ze zijn.

### Kan ik het gratis proberen op mijn eigen trage job?

Ja. De proefperiode is 7 dagen of 3.000 jobminuten, wat het eerst komt, zonder kaart. Zet je traagste job op runs-on: skipbox, draai hem twee keer achter elkaar en vergelijk de tijden per step met die van GitHub.

Bijgewerkt op 2026-11-11 · https://skipbox.dev/nl/guides/github-actions-slow