GitHub Actions Node 24-Migration: Mac-CI-Upgrade-Checkliste 2026

Zuletzt aktualisiert am 02.09.2026; Datums- und Laufzeitangaben wurden anhand der offiziellen Node-20-Abkündigung von GitHub sowie der offiziellen Durchsetzungsplanung für self-hosted Runner geprüft.

Seit dem 16.06.2026 verwenden GitHub Actions Runner standardmäßig Node 24; die vorübergehende Rückfallmöglichkeit auf Node 20 endet am 23.09.2026. Deshalb sollten Unternehmen nicht warten, bis Node 20 endgültig entfernt wird: Ein isolierter Mac-Knoten sollte sofort mit Node 24 getestet werden, anschließend sind Actions, Runner, macOS und die vollständige Xcode-Pipeline im Doppelbetrieb zu prüfen. Nicht aktualisierbare Knoten gehören aus dem Produktionspool entfernt oder durch neue Remote-Mac-Knoten ersetzt.

Diese Anleitung ist für drei Gruppen gedacht: Plattformteams, die einen self-hosted runner und mehrere macOS Runner verwalten; Teams für Entwicklungsproduktivität, die iOS-Releases mit Xcode signieren; sowie IT-Verantwortliche, die Ersatzkapazität, Zugriffsrechte und Geschäftskontinuität planen. Wer ausschließlich GitHub-hosted Runner nutzt und keine eigene Mac-Infrastruktur betreibt, benötigt diese spezielle Ablaufplanung nur eingeschränkt.

Der Ausgangspunkt: drei Versionen sauber auseinanderhalten

Bei der Migration werden häufig drei voneinander unabhängige Komponenten vermischt:

1. Die Node-Laufzeit einer JavaScript Action: Eine Action kann in ihrer Metadatei eine Laufzeit wie node20 oder node24 deklarieren. Das betrifft die Ausführung dieser Action innerhalb von GitHub Actions.
2. Die Node-Version des Projekts: Ein iOS-Projekt kann zusätzlich Node für JavaScript-Abhängigkeiten, Skripte, React-Native-Bestandteile oder Web-Assets verwenden. Diese Version wird etwa über package.json, eine Versionsdatei oder die CI-Konfiguration festgelegt.
3. Die Runner-Anwendung: Der self-hosted runner selbst ist eine separate Anwendung. Seine unterstützte Laufzeit, Registrierung, Aktualisierung und Dienstverwaltung dürfen nicht mit der Node-Version des Projekts gleichgesetzt werden.

Die offizielle Abkündigung betrifft zunächst die von Actions verwendete JavaScript-Laufzeit. Ein Workflow kann daher trotz erfolgreicher Projektinstallation mit Node 24 scheitern, wenn eine benutzerdefinierte Action noch eine inkompatible Laufzeit oder ein altes Runner-Verhalten voraussetzt. Umgekehrt kann eine Action funktionieren, während ein Projekt-Skript wegen einer eigenen Node-Abhängigkeit fehlschlägt.

GitHub hat den Standardwechsel auf Node 24 ab dem 16.06.2026 bestätigt. Node 20 kann nur vorübergehend erzwungen werden; diese Übergangsfrist läuft am 23.09.2026 aus. Für GitHub Enterprise Cloud beginnt die umfassende Durchsetzung der Mindestversion des self-hosted runner nach aktuellem Plan am 25.09.2026. GitHub weist zugleich darauf hin, dass Mindestversion, gestaffelte Einführung und konkrete Termine über Changelog und Organisationsseite geprüft werden müssen. Die Dokumentation zu selbstverwalteten Runnern bleibt daher die maßgebliche technische Referenz.

Die Bestandsaufnahme vor dem ersten Upgrade

Die Asset-Tabelle sollte mindestens diese Spalten enthalten:

• Organisation, Repository und Workflow-Datei
• verwendete Action samt Version oder festem Commit
• Kennzeichnung als JavaScript-, Container- oder Composite-Action
• Runner-Gruppe und Runner-Labels
• installierte Runner-Version und letzter erfolgreicher Dienststart
• macOS-Version und CPU-Architektur
• Xcode-Version, Toolchain und simulierte Geräte, sofern genutzt
• Zugriff auf Zertifikate, Provisioning-Profile, Keychain und private Abhängigkeiten
• letzter erfolgreicher Build, Archivierung und Upload
• verantwortliches Team sowie geplante Rückfallroute

Die REST-API für self-hosted Runner liefert unter anderem Registrierungs- und Statusinformationen der Knoten. Für die Workflow-Seite können die Workflow-Runs-Endpunkte verwendet werden, um fehlgeschlagene Ausführungen, Laufzeiten und betroffene Workflows zu gruppieren. Damit wird sichtbar, welche produktiven Aufgaben nach der Node-20-Entfernung besonders gefährdet sind.

Eine reine Suche nach node20 in YAML-Dateien reicht nicht aus. Versionen können in wiederverwendeten Workflows, Marketplace-Actions, internen Repositories oder festen Commit-Referenzen verborgen sein. Auch ein alter Commit kann verhindern, dass eine bereits korrigierte Action automatisch übernommen wird.

Erster Arbeitstag: Inventar, Warnungen und Risikoklassen

Die Migration von GitHub Actions zu Node 24 sollte mit einer Risikoklassifizierung beginnen, nicht mit einem flächendeckenden Neustart aller Runner. Für jeden Workflow wird festgehalten, ob er nur Tests ausführt, ein signiertes Archiv erzeugt oder direkt ein Release veröffentlicht.

Besonders kritisch sind Workflows mit diesen Eigenschaften:

• sie verwenden eine JavaScript Action mit alter Laufzeit;
• sie signieren oder veröffentlichen ohne manuelle Freigabe;
• sie greifen auf private Paketquellen oder interne Zertifikatsdienste zu;
• sie nutzen selbstgeschriebene Actions, die nicht regelmäßig gewartet werden;
• sie laufen auf einem einzelnen Mac-Knoten ohne Ersatzrouting;
• sie kombinieren Xcode-Build, Cache-Wiederherstellung und Artefakt-Upload in einem ungeteilten Job.

Die Warnungen in Workflow-Ausgaben sollten mit der Asset-Tabelle abgeglichen werden. Ein grüner Lauf beweist nicht, dass die Migration abgeschlossen ist, wenn der Workflow zufällig noch über die vorläufige Node-20-Variable läuft. Umgekehrt ist ein einzelner Fehler noch kein Beweis für eine generelle Inkompatibilität: Entscheidend sind Action-Version, Runner-Version, Betriebssystem, Architektur und konkreter Ausführungspfad.

Für die spätere Abnahme empfiehlt sich eine Statusdefinition:

• Bereit: Node 24 erzwungen, Kernworkflow grün, signierte Artefakte geprüft.
• Beobachtung: Workflow läuft, aber Cache, private Abhängigkeit oder benutzerdefinierte Action benötigt Nachprüfung.
• Blockiert: Runner oder macOS erfüllt die aktuelle Voraussetzung nicht.
• Außer Betrieb: Knoten ist nicht mehr für Produktionsjobs zugelassen und besitzt keine produktiven Signaturrechte.

Zweite Phase: Node 24 auf einem isolierten Mac Runner erzwingen

Der erste Versuch sollte auf einem Mac stattfinden, der keine produktiven Signaturzertifikate und keine unbeschränkten Veröffentlichungsrechte besitzt. Die Trennung ist wichtig, weil ein Laufzeitfehler während eines Upgrades nicht gleichzeitig zu einem unkontrollierten Release führen darf.

Das Testverfahren besteht aus fünf aufeinanderfolgenden Schritten:

1. Einen Testknoten auswählen: Der Knoten erhält ein eigenes Label und wird einer separaten Runner-Gruppe zugeordnet. Produktions-Workflows dürfen dieses Label noch nicht verwenden.
2. Den offiziellen Migrationsschalter aktivieren: Die von GitHub vorgesehene Einstellung für die vorzeitige Node-24-Ausführung wird ausschließlich auf dem Testpfad gesetzt. Eine Rückfallvariable wird dokumentiert, aber nicht als dauerhafte Lösung behandelt.
3. Eine Baseline ausführen: Der Workflow muss mindestens Code-Checkout, Cache-Lese- und Schreibvorgang, Artefakt-Upload sowie eine interne oder benutzerdefinierte JavaScript Action enthalten.
4. Ausführungsergebnisse sichern: Pro Schritt werden Log, Runner-Label, Action-Referenz, macOS-Bedingung und Rückfallaktion protokolliert.
5. Den Test wiederholen: Ein einmaliger erfolgreicher Lauf genügt nicht. Erst wiederholte Läufe mit Cache-Treffer, Cache-Miss und einem absichtlich neu gestarteten Dienst geben ein belastbares Bild.

Die Anleitung zur Konfiguration des Runner-Dienstes ist für Registrierung, Dienstinstallation und Neustart heranzuziehen. Dabei sollte geprüft werden, ob der Runner nach einem Neustart wieder registriert, erreichbar und der richtigen Gruppe zugeordnet ist.

Achtung: Der Node-24-Test darf nicht nur eine Kompilierung ausführen. Ein iOS-Build kann erfolgreich sein, obwohl die nachgelagerte Action für Signierung, Artefakt-Upload oder Benachrichtigung bereits fehlschlägt.

Können alte GitHub Actions unter Node 24 weiterlaufen?

Das hängt von der Action-Implementierung ab. Eine alte Action kann unter Node 24 funktionieren, wenn sie keine entfernten oder veränderten Node-Schnittstellen verwendet. Für die Produktionsfreigabe reicht diese Annahme jedoch nicht aus. Die Action sollte auf eine vom Maintainer unterstützte Version aktualisiert werden; bei einer festen Commit-Referenz muss geprüft werden, ob dieser Commit die neue Laufzeit tatsächlich enthält.

Bei internen Actions sind insbesondere folgende Stellen zu kontrollieren:

• direkte Verwendung veralteter Node-Module;
• Annahmen über Dateipfade oder Umgebungsvariablen;
• Synchronität von Prozessaufrufen und Shell-Kommandos;
• TLS- und Proxy-Zertifikate;
• Fehlerbehandlung bei Artefakten und Cache-Zugriffen;
• Abhängigkeiten, die nur auf einem älteren Runner installiert sind.

Die aktuellen Releases der Actions-Runner-Anwendung sollten gegen die im Unternehmenskonto angebotene Version verglichen werden. Für die Produktion zählt letztlich die Version, die GitHub in der Organisationsansicht zum Download und zur Registrierung bereitstellt, nicht nur ein lokal archiviertes Installationspaket.

Dritte Phase: Action, Runner und macOS am ersten Tag aktualisieren

Nach dem isolierten Test wird zuerst die Action-Landschaft bereinigt. Offizielle und Drittanbieter-Actions werden priorisiert nach Produktionskritikalität, Wartungsstand und Änderungsumfang aktualisiert. Ein Update sollte nicht gleichzeitig mit einer Xcode- oder macOS-Änderung in denselben ungetesteten Produktionslauf gelangen, sofern sich die Änderungen getrennt validieren lassen.

Danach folgt der Runner:

1. aktuelle Version aus der Organisationsansicht oder den offiziellen Releases bestimmen;
2. installierte Version jedes Knotens dokumentieren;
3. automatisches Update prüfen, ohne es als garantiertes Rollback zu behandeln;
4. bei Bedarf manuell aktualisieren;
5. Dienst neu starten;
6. Registrierung, Labels, Runner-Gruppe und Erreichbarkeit kontrollieren;
7. einen nicht signierenden Testworkflow ausführen.

Die Durchsetzungsplanung für die Mindestversion selbstverwalteter Runner nennt den 25.09.2026 als Beginn der umfassenden Durchsetzung für GitHub Enterprise Cloud. Da sich gestaffelte Rollouts ändern können, sollte die Organisationsseite vor dem Umschalten jedes Produktionspools nochmals geprüft werden.

Ein alter macOS Runner, der die aktuelle Node-24- oder Runner-Voraussetzung nicht erfüllt, sollte nicht dauerhaft mit einer Rückfallvariable betrieben werden. Zulässige Optionen sind ein getestetes Betriebssystem-Upgrade, der Austausch des Knotens oder die Entfernung aus der Produktionsgruppe. Vorher muss die Kompatibilität von Xcode, Simulatoren, privaten Abhängigkeiten und Gerätezertifikaten separat bewertet werden.

Muss macOS zusammen mit dem Runner aktualisiert werden?

Nicht automatisch. Die Node-24-Migration, die Runner-Anwendung und das Betriebssystem sind drei getrennte Prüfungen. Ein Runner-Upgrade kann möglich sein, während eine alte macOS-Version nicht mehr im vorgesehenen Supportbereich liegt; umgekehrt kann ein aktuelles macOS mit einer veralteten Runner-Anwendung registriert sein.

Die Entscheidung richtet sich deshalb nach der Kombination aus offizieller Runner-Unterstützung, verfügbarer Xcode-Toolchain, Sicherheitsvorgaben und Wiederherstellbarkeit. Die Self-hosted-Runner-Referenz von GitHub sollte für die unterstützten Systembedingungen verwendet werden. Die Organisationsansicht kann zusätzlich eine abweichende Mindestversion erzwingen.

Produktionsprüfung: Xcode, Signierung und Artefakte als Kette

Ein produktiver iOS-Workflow ist erst validiert, wenn die gesamte Lieferkette funktioniert. Der Test muss deshalb über den reinen Build hinausgehen:

1. Repository und Submodule aus privaten Quellen auschecken.
2. Abhängigkeiten über die vorgesehenen Paketquellen abrufen.
3. Cache mit einem vorhandenen und einem leeren Cache prüfen.
4. Xcode-Projekt oder Workspace bauen.
5. Unit- und gegebenenfalls UI-Tests ausführen.
6. Archiv erstellen und dessen Signaturbedingungen kontrollieren.
7. Keychain-Zugriff, Zertifikate und Provisioning-Profile validieren.
8. Artefakt hochladen und anschließend wieder abrufen.
9. Release-Freigabe bewusst getrennt vom technischen Test ausführen.

Die häufigsten versteckten Fehler liegen nicht im Compiler, sondern in den Übergängen: Ein Proxy-Zertifikat wird von einer Action anders geladen, ein Cache-Pfad besitzt nach dem Runner-Update andere Rechte, ein Shell-Skript interpretiert Fehlercodes anders oder eine benutzerdefinierte JavaScript Action behandelt eine Node-24-Ausnahme nicht korrekt.

Die Signierung sollte auf einem kontrollierten Knoten stattfinden, dessen Berechtigungen nur für die konkrete Aufgabe reichen. Der isolierte Testknoten erhält keine zusätzlichen Produktionsgeheimnisse, nur weil die Xcode-Pipeline dort ausgeführt wird. Hinweise zur Absicherung von Token, Geheimnissen und Runnern enthält der offizielle Leitfaden zur sicheren Nutzung von GitHub Actions.

Die einzige Vergleichsmatrix: Produktionspool, Testpool oder Ersatzknoten

Die folgende Matrix unterstützt die Entscheidung, wie mit einem betroffenen Mac-Knoten verfahren wird. Sie ersetzt keine Prüfung der offiziellen Systembedingungen.

Für zusätzliche Test- oder Ersatzknoten kann ein Remote-Mac-Mietmodell von RUVCLOUD sinnvoll sein, wenn die bestehende Hardware nicht rechtzeitig aktualisiert werden kann. Die Entscheidung sollte jedoch anhand der tatsächlich benötigten Testdauer, Signierungsisolierung, Netzwerkanbindung und Organisationsrichtlinien getroffen werden, nicht anhand eines einzelnen erfolgreichen Builds.

Erste Produktionswoche: Doppelbetrieb und Rückfall

Nach der technischen Abnahme werden die Workflows nicht gleichzeitig umgestellt. Der bisherige Produktionspool bleibt zunächst verfügbar, während der Node-24-Pool eigene Labels und eine eigene Runner-Gruppe erhält. Zuerst werden nicht veröffentlichende Tests und interne Builds umgeleitet, danach signierende Workflows mit kontrollierter Freigabe.

Für jeden migrierten Workflow sollte die Rückfallbedingung vorher festgelegt werden:

• Welche Fehlermeldung stoppt die weitere Migration?
• Wer darf den Workflow zurück auf den geprüften Produktionspool routen?
• Wie wird verhindert, dass ein Rückfall versehentlich Node 20 nach dem 23.09.2026 erneut aktiviert?
• Welche Secrets dürfen auf dem Rückfallknoten vorhanden sein?
• Wie wird ein halb aktualisierter Runner aus der Jobverteilung entfernt?

Ein Rückfallknoten ist kein dauerhaftes Archiv. Er muss weiterhin erreichbar, sicher und für den konkreten Zeitraum zulässig sein. Sobald die Übergangsfrist endet oder die Mindestversion erzwungen wird, darf er nicht mehr als stillschweigende Produktionsversicherung eingeplant werden.

Während des Doppelbetriebs werden reale Warteschlangen, fehlgeschlagene Schritte und Wiederanlaufzeiten erfasst. Exakte Kapazitäts- oder Leistungswerte sollten nur aus den eigenen Messungen stammen. Ohne solche Messungen lässt sich seriös lediglich sagen, dass ein zusätzlicher Mac-Knoten die Ausweichkapazität erhöht; eine konkrete Zahl für Durchsatz oder Wiederherstellungszeit wäre ohne Test nicht belastbar.

Was geschieht bei einem fehlgeschlagenen Runner-Upgrade?

Der betroffene Knoten wird zunächst aus dem Produktionsrouting genommen, nicht mehrfach unkontrolliert neu installiert. Danach werden Dienststatus, Registrierung, lokale Logs, Netzwerkzugang und Runner-Gruppe geprüft. Ist die Registrierung beschädigt oder die Betriebssystembedingung nicht erfüllbar, wird der Knoten aus der Gruppe entfernt und durch einen bereits getesteten Ersatzpfad ersetzt.

Die Wiederherstellung sollte als eigener Testfall behandelt werden: Neustart des Mac, Start des Runner-Dienstes, erneute Erreichbarkeit, Ausführung eines nicht signierenden Workflows und erst danach ein signierter Produktionslauf. So bleibt nachvollziehbar, ob der Fehler bei der Installation, beim Dienststart oder in der Pipeline selbst lag.

Fristwoche: Produktionszulassung und Ersatzkapazität

Vor dem 23.09.2026 sollten keine ungeprüften alten Actions mehr in neue Produktionsworkflows aufgenommen werden. Vor dem geplanten Mindestversionszwang am 25.09.2026 wird jeder Produktionsknoten anhand einer Zulassungsliste bewertet:

• Runner-Version aus der aktuellen Organisationsansicht bestätigt
• macOS-Bedingung und CPU-Architektur dokumentiert
• Node-24-Test ohne temporären Rückfall erfolgreich
• Xcode-Build, Tests und Archivierung erfolgreich
• private Abhängigkeiten und Cache geprüft
• Signierung auf einem kontrollierten Knoten nachgewiesen
• Artefakt-Upload und Abruf geprüft
• Neustart und automatische Wiederaufnahme getestet
• Verantwortliche Person und Rückfallende eingetragen

Ein Unternehmen sollte die Download-Seite der eigenen Organisation und den offiziellen Changelog unmittelbar vor der finalen Umschaltung erneut prüfen, weil GitHub die gestaffelte Einführung oder konkrete Mindestversionen anpassen kann. Zusätzlich ist eine erneute Abfrage der REST-API sinnvoll, damit offline befindliche oder falsch gelabelte Runner nicht unbemerkt im Produktionsplan bleiben.

Wenn nach der Bestandsaufnahme mehrere alte Macs nicht rechtzeitig aktualisiert werden können, sollte die Ersatzkapazität nicht erst beim ersten ausgefallenen Release beschafft werden. Eine isolierte Remote-Mac-Umgebung kann zunächst als Testpool dienen und später, nach bestandener Abnahme, gezielt einen stillgelegten Produktionsknoten ersetzen. Für eine konkrete Bestellung können IT-Verantwortliche die RUVCLOUD-Mietoptionen für Unternehmen mit dem geplanten Übergangszeitraum abgleichen; laufende Signierungsrechte und interne Compliance-Vorgaben bleiben dabei in der Verantwortung des Unternehmens.

Was die aktuelle Infrastruktur gegenüber Remote-Mac-Knoten verliert

Eine vorhandene Mac-Flotte wirkt zunächst günstiger, wenn die Geräte bereits abgeschrieben sind. Für diese Migration entstehen jedoch reale Nachteile: Alte Macs lassen sich möglicherweise nicht auf die erforderlichen Systembedingungen bringen, einzelne Geräte werden zum Ausfallpunkt, und die Beschaffung physischer Ersatzgeräte verlängert die Übergangsphase. Zusätzlich müssen IT-Teams Stromversorgung, Remote-Zugriff, Austausch, Registrierung und Wiederherstellung selbst koordinieren.

Ein gemieteter Remote-Mac ist nicht für jedes Szenario die beste Dauerlösung. Bei dauerhaft hoher Auslastung, speziellen physischen Schnittstellen oder streng vorgeschriebener lokaler Datenhaltung kann der Kauf eigener Hardware besser passen. Für einen zeitlich begrenzten Node-24-Test, eine parallele Abnahme oder den Ersatz eines nicht aktualisierbaren Knotens bietet RUVCLOUD jedoch einen klareren Weg: Eine zusätzliche Mac-Umgebung lässt sich anfordern, getrennt registrieren und nach erfolgreicher Pipeline-Prüfung wieder aus dem Übergangsplan entfernen. Damit wird nicht blind Hardware gekauft, bevor feststeht, wie viele Knoten tatsächlich ersetzt werden müssen.

Der nächste sinnvolle Schritt ist daher kein globales Umschalten, sondern die Bestellung beziehungsweise Bereitstellung eines isolierten Remote-Mac-Testknotens, die Registrierung in einer separaten Runner-Gruppe und die Prüfung der realen Xcode-, Signierungs- und Artefaktkette. Weitere Details zum vorgesehenen Zugang finden Sie auf der deutschen RUVCLOUD-Seite.