GitHub hat am 28. September 2026 den Durchsetzungstermin für die Mindestversionen von Self-hosted Runnern auf GitHub Enterprise Cloud verschoben: Er gilt nun ab dem 29. September 2026. Runner unter Version 2.329.0 können sich nicht mehr registrieren, Runner unter der höheren Ausführungs-Mindestversion nehmen keine Jobs mehr an. GitHub Enterprise Server ist nicht betroffen. Eine neue REST-API nennt die Stichtage je Runner-Version.
Am 29. September 2026 sperrt GitHub auf Enterprise Cloud veraltete Self-hosted Runner. Wer seine Flotte nicht aktualisiert hat, riskiert ausfallende Workflows ab dem nächsten Tag.
Das Wichtigste in Kürze
- Die Durchsetzung beginnt am Dienstag, 29. September 2026. Sie gilt für GitHub Enterprise Cloud und ersetzt den zuvor angekündigten Termin.
- Runner unter Version 2.329.0 können sich nicht mehr registrieren. Das gilt auch für eine erneute Registrierung.
- Bestehende Runner unter der Ausführungs-Mindestversion nehmen keine Jobs mehr an. Diese Grenze liegt höher als die Registrierungsgrenze.
- GitHub Enterprise Server ist nicht betroffen. Für Enterprise Cloud mit Data Residency läuft die Durchsetzung seit dem 31. Juli 2026.
Was sich bei den Self-hosted Runnern ändert
GitHub hat die Meldung am 28. September 2026 im Changelog veröffentlicht und nennt kein späteres Update. Die Anforderungen selbst bleiben gleich, nur der Stichtag verschiebt sich. Die erste Terminübersicht stammt vom 12. Juni 2026 und nannte für Enterprise Cloud den 25. September 2026.
Dabei gelten zwei Grenzen. Für die Registrierung braucht ein Runner mindestens die Version 2.329.0. Für die Ausführung von Jobs gilt eine höhere Mindestversion. Laut der Juni-Meldung müssen Runner innerhalb von 30 Tagen nach einer Veröffentlichung aktualisiert werden, wobei jede Version zählt, ob Major, Minor oder Patch.
| Umgebung | Stand der Durchsetzung | Bemerkung |
|---|---|---|
| Enterprise Cloud mit Data Residency | Seit 31. Juli 2026 | Hier greift die Regel bereits |
| Enterprise Cloud | Ab 29. September 2026 | Vorher war der 25. September angekündigt |
| Enterprise Server | Nicht betroffen | Keine Änderung nötig |
Warum GitHub die Mindestversion durchsetzt
Die Juni-Meldung nennt als Hintergrund die Umstellung auf eine neue Architektur, die laut GitHub über 120 Millionen Jobs pro Tag verarbeitet. Vor den Stichtagen kündigte GitHub zeitweilige Sperren an, die sich über vier Wochen von einzelnen Tagen auf mehrtägige Zeiträume ausweiten sollten.
Was Admins jetzt tun
Der Termin liegt unmittelbar vor dir. Gehe deshalb in dieser Reihenfolge vor:
- Prüfe die Version jedes Self-hosted Runners und aktualisiere alle Instanzen auf den aktuellen Stand.
- Passe Deployment-Skripte und Container-Images an, damit neue Runner nicht mit einer alten Version starten.
- Erstelle Runner neu, die aus älteren Vorlagen entstanden sind.
- Nutze die neue REST-API für Runner-Versionen, um Stichtage zu prüfen und Warnungen für deine Flotte einzurichten.
- Suche als Enterprise-Owner im Audit-Log nach Registrierungen, um veraltete Runner zu finden.
Die Abfrage GET /actions/runners/deprecations/{version} nennt zwei Daten: wann die Registrierung und wann die Ausführung für eine Version endet. Sie steht auf Repository-, Organisations- und Enterprise-Ebene bereit.
Wer zudem seine Workflows härten will, liest den Beitrag zu den Workflow-Lockfiles in GitHub Actions.
Fazit
Der Termin ist nur einen Tag entfernt, die Anforderungen sind klar. Aktualisiere heute alle Runner auf Enterprise Cloud und richte danach die Abfrage über die neue API ein. So fällt dir der nächste Stichtag früh auf und nicht erst, wenn Jobs ausbleiben.
Quellen: GitHub Changelog vom 28. September, GitHub Changelog vom 12. Juni, GitHub Changelog vom 3. September. Foto: StockSnap / Pixabay. Stand: 28. September 2026.
Recherche und Entwurf KI-gestützt, geprüft und freigegeben von Andreas Brauckmann · So arbeitet die Redaktion
Änderungshistorie
- — Artikel veröffentlicht.