GitHub Actions langsam? Ursache und wie Jobs schneller starten

Der größte Teil eines langsamen GitHub-Actions-Jobs passiert, bevor der erste Test läuft. Node einrichten, die Abhängigkeiten herunterladen, das Docker-Image bauen: dieselben Minuten bei jedem Push, während jemand in deinem Team auf einen grünen Check wartet. Bei Minutenabrechnung bezahlst du diese Minuten auch noch.

Skipbox ist ein GitHub-Actions-Runner, der seine Maschine zwischen den Jobs behält, also liegt, was ein Job installiert hat, für den nächsten noch auf der Festplatte. Ändere eine Zeile, runs-on: skipbox, und der Job läuft auf deiner eigenen Maschine, pauschal für $39 im Monat mit unbegrenzten Minuten.

Jeder Job startet auf einer leeren VM

Ein von GitHub gehosteter Runner ist für jeden Job eine neue virtuelle Maschine. Nichts, was der letzte Job heruntergeladen oder gebaut hat, ist darauf, also baut jeder Job denselben Zustand neu auf:

Step	Von GitHub gehosteter Runner	Skipbox
Node, Python, Java einrichten	Lädt die Toolchain herunter	Findet sie im Tool-Cache des letzten Jobs
Abhängigkeiten installieren	Lädt das Cache-Archiv herunter und entpackt es; bei einem Fehltreffer der komplette Download aus der Registry	Liest den Cache des Paketmanagers von der Festplatte
Das Docker-Image bauen	Startet ohne Layer und baut jeden Schritt neu	Verwendet die Layer des letzten Builds wieder
Die Tests ausführen	2 CPUs auf `ubuntu-latest` in einem privaten Repository	Ab 4 vCPU

Die ersten drei Zeilen erzeugen nichts Neues. Sie bringen die Maschine nur wieder dorthin, wo sie gestern war.

Der Cache von GitHub mildert das, ohne es zu ändern. Er fasst 10 GB pro Repository, löscht Einträge, die 7 Tage lang kein Job gelesen hat, und ein neuer Feature-Branch kann den Cache eines anderen Feature-Branches nicht lesen. Selbst bei einem Treffer wird bei jedem Lauf ein Archiv heruntergeladen und entpackt.

Was dich das Warten kostet

Angenommen, das Einrichten dauert in jedem Job 3 Minuten, und dein Team führt 100 Jobs am Tag aus. Das sind 300 Minuten Runner-Zeit am Tag, nur um die Maschine wiederherzustellen, und jeder Pull Request wartet auf seinen Anteil. Reviews beginnen später, Merges landen später, und Entwickler wechseln zu etwas anderem, während sie warten.

Bei Minutenabrechnung stehen diese Minuten auf der Rechnung. Ein Runner mit 4 vCPU, nach Minuten im Monat:

Minuten im Monat (4 vCPU)	GitHub	Skipbox S	Du sparst jeden Monat
10.000	$102	$39	$63
20.000	$222	$39	$183
30.000	$342	$39	$303

Die GitHub-Werte sind die Rechnung nach Abzug der in GitHub Team enthaltenen Nutzung. Trag deine eigenen Minuten in den Rechner auf der Startseite ein; ohne Anmeldung.

Und die Zahl der Läufe steigt nur:

KI-Coding-Agents. Jeder Push eines Agents startet die CI. Das Warten und die Rechnung wachsen mit den Pushes, nicht mit der Teamgröße.
Mehr Tests. Eine E2E-Suite oder eine Matrix wiederholt das Einrichten in jedem Job, den sie hinzufügt.
Budgets. Deckelst du die Rechnung mit einem GitHub-Budget, starten mitten im Monat keine Jobs mehr, und damit stoppen die Merges.

Selbst beschleunigen ist ein Projekt

Wer bei von GitHub gehosteten Runnern bleibt und sie schnell machen will, übernimmt Arbeit wie diese:

Caches über Hashes der Lockfiles verschlüsseln und restore-keys feinjustieren, bis sie treffen
buildx einbauen und den Cache von Docker mit cache-to exportieren, innerhalb derselben 10 GB
Tests aufteilen, wobei jeder Teil das Einrichten wiederholt und die berechneten Minuten steigen
Oder einen eigenen selbstgehosteten Runner betreiben: bereitstellen, Betriebssystem aktualisieren, zwischen den Jobs aufräumen und ihn reparieren, wenn er ausfällt

Jedes davon umgeht eine Maschine, die alles vergisst. Skipbox behält die Maschine, also braucht es nichts davon.

Was sich mit Skipbox ändert

Das Eingerichtete bleibt auf der Festplatte. Deine Jobs laufen auf der eigenen Maschine deines Kontos, und sie bleibt zwischen den Jobs bestehen. Docker-Images, Layer und Build-Cache; Paket-Caches für npm, pip, Gradle und mehr; die Tools, die setup-node und Co. installieren. Mindestens 7× so viel Cache-Speicher wie bei GitHub, ohne Ablauf nach 7 Tagen und ohne Branch-Regel.

Größere Maschinen zum Festpreis. Compiler und Test-Runner starten einen Worker pro Kern, also verkürzen mehr Kerne die CPU-lastigen Steps.

Tarif	Maschine	Preis
S	4 vCPU · 16 GB	$39 im Monat
M	8 vCPU · 16 GB	$79 im Monat
L	16 vCPU · 32 GB	$149 im Monat

Die Minuten sind in jedem Tarif unbegrenzt. Skipbox-Jobs verbrauchen keine GitHub-Minuten, also stoppt ein GitHub-Budget sie nie.

Keine Maschine zu betreuen. Skipbox stellt die Maschine bereit, aktualisiert Betriebssystem und Tools, räumt nach jedem Job auf, führt einen Health Check aus und baut eine Maschine neu auf, die ihn nicht besteht.

Der Wechsel ist eine Zeile

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

Melde dich bei Skipbox mit GitHub an.
Installiere die GitHub-App von Skipbox und wähle die Repositorys.
Ändere runs-on und pushe.

Was der erste Job installiert, liegt für den zweiten auf der Festplatte.

Sicherheit

Die Maschine gehört nur deinem Konto. Keine Jobs eines anderen Unternehmens laufen darauf.
Nach jedem Job werden die Zugangsdaten, Prozesse und Container des Runners gelöscht. Ab dem 13. November 2026 bleiben dein Checkout und seine Build-Ausgabe (target/ von Cargo) für deine nächsten Jobs auf deiner eigenen Maschine; „Jeder Job sauber“ gibt jedem Job eine frische Maschine.
Code von Personen ohne Schreibzugriff (etwa Pull Requests aus Forks) läuft auf einer frischen Wegwerf-Maschine.

Die Einzelheiten stehen unter Wie Jobs isoliert werden.

Probier es mit deinem langsamsten Job

Die Testphase ist kostenlos für 7 Tage oder 3.000 Job-Minuten, je nachdem, was zuerst erreicht ist, und braucht keine Karte. Verschiebe deinen langsamsten Job auf runs-on: skipbox, führe ihn zweimal hintereinander aus und leg die Zeiten der Steps neben die von GitHub.

FAQ

Warum ist GitHub Actions so langsam?

Jeder Job auf einem von GitHub gehosteten Runner startet auf einer neuen VM ohne irgendetwas vom letzten Lauf, also lädt er seine Tools herunter, installiert seine Abhängigkeiten neu und baut seine Docker-Images neu, bevor deine Tests starten. Skipbox führt deine Jobs auf der eigenen Maschine deines Kontos aus und behält diesen Zustand auf ihrer Festplatte, sodass der nächste Job dort weitermacht, wo der letzte aufgehört hat.

Ich habe actions/cache eingebaut. Warum ist mein Workflow trotzdem langsam?

Auch bei einem Cache-Treffer wird in jedem Job ein Archiv heruntergeladen und entpackt, weil die VM jedes Mal neu ist. Außerdem fasst der Cache von GitHub 10 GB pro Repository, entfernt Einträge, die 7 Tage nicht genutzt wurden, und lässt sich von einem Schwester-Branch nicht lesen. Auf Skipbox liegen die Paket-Caches und Docker-Layer schon auf der Festplatte der Maschine, ohne Keys, die du verwalten musst.

Wie mache ich Docker-Builds in GitHub Actions schneller?

Gib dem Build die Layer des letzten Builds. Auf von GitHub gehosteten Runnern heißt das, den Cache mit buildx zu exportieren und bei jedem Lauf zu importieren, innerhalb desselben Limits von 10 GB. Auf Skipbox bleiben die Images und der Build-Cache von Docker zwischen den Jobs auf der Maschine, also verwendet docker build die Layer von selbst wieder.

Muss ich meine Workflows für Skipbox umschreiben?

Nein. Bei Linux-Jobs änderst du runs-on auf skipbox. Auf der Maschine läuft Ubuntu 24.04 mit Docker, Node.js und Python, und deine Steps und Actions laufen, wie sie sind.

Kann ich es kostenlos mit meinem eigenen langsamen Job ausprobieren?

Ja. Die Testphase dauert 7 Tage oder 3.000 Job-Minuten, je nachdem, was zuerst erreicht ist, und braucht keine Karte. Verschiebe deinen langsamsten Job auf runs-on: skipbox, führe ihn zweimal hintereinander aus und vergleiche die Zeiten der Steps mit denen von GitHub.

Aktualisiert am 11. November 2026