GitHub Actions Runner Scale Set Client: Lohnt sich Mac CI 2026?

Ihre Mac-CI-Warteschlange wächst bei Pull-Request-Spitzen, aber ein neuer Runner ist nicht automatisch eine neue Mac-Buildmaschine.

Die schnellste Lösung: Testen Sie den GitHub Actions Runner Scale Set Client zunächst mit wiederaufbaubaren Build-Aufträgen in einem begrenzten elastischen Pool; ersetzen Sie den festen Mac-Pool nicht vollständig. Produktionssignierung und zeitkritische Jobs bleiben auf vorgewärmten oder dedizierten Knoten.

SECTION 01Für wen diese Entscheidung relevant ist

Dieser Leitfaden richtet sich an Sie, wenn Sie mehrere GitHub-Actions-Repositories mit self-hosted Mac Runnern betreiben und Lastspitzen bei iOS- oder macOS-Builds abfangen müssen.

Er ist ebenfalls relevant, wenn Sie als Sicherheitsverantwortlicher die Risiken von Quellcode-, Cache- und Keychain-Rückständen bewerten oder als IT-Leitung eine feste Mac-Flotte, Remote-Mac-Kapazität und einen hybriden TCO vergleichen.

Zuletzt aktualisiert am 20.09.2026. Die Aussagen zum Funktionsstatus wurden anhand des GitHub Changelog-Eintrags zur öffentlichen Vorschau, der offiziellen Scale-Set-Dokumentation und der verlinkten Referenzdokumente geprüft.

SECTION 02Entscheidungsmatrix für den ersten Architekturentscheid

Der GitHub Actions Runner Scale Set Client ist ein Bindeglied zwischen der Scale Set API und Ihrer Runner-Umgebung. Er erkennt beziehungsweise verarbeitet Kapazitätsanforderungen, registriert Runner und nimmt Aufträge an. Er erstellt jedoch nicht eigenständig die physische oder virtuelle Mac-Infrastruktur.

Die Verantwortung ist deshalb in fünf getrennte Ebenen aufzuteilen:

1. Scale Set API: liefert Steuerungs- und Auftragsinformationen.
2. Scale Set Client: kommuniziert mit dem Dienst und verarbeitet Runner-Lebenszyklen.
3. Runner-Prozess: führt den GitHub-Actions-Job aus.
4. macOS-Host: muss bereitgestellt, initialisiert, entsperrt, überwacht und gelöscht werden.
5. Arbeitsbereich und Signaturidentität: müssen nach dem Auftrag bereinigt oder in einer vertrauenswürdigen Umgebung gehalten werden.

Der erste Entscheid ist damit nicht „Scale Set oder kein Scale Set“, sondern: Welche Aufgaben dürfen auf einem kurzlebigen Mac ausgeführt werden? Wenn Sie diese Frage nicht mit Repository-, Branch-, Secret- und Signaturregeln beantworten können, sollten Sie den elastischen Pool zunächst nur für nicht vertrauliche Validierungsjobs einsetzen.

Die offizielle Beschreibung führt macOS als unterstützte Plattform für die benutzerdefinierte Infrastruktur auf, kennzeichnet die Funktion aber weiterhin als Public Preview. Das ist keine GA-Zusage und kein Beleg dafür, dass ein echter Mac so schnell wie ein Container bereitsteht. Prüfen Sie vor einer Beschaffungsentscheidung deshalb die jeweils aktuelle actions/scaleset-Referenz.

SECTION 03Kapazitätsmetrik statt Ereigniszählung

Eine häufige Fehlentscheidung entsteht, wenn jede neue Meldung aus der Steuerung direkt als zusätzlicher Mac interpretiert wird. Für die Kapazitätsplanung müssen Sie mindestens vier Zustände getrennt erfassen:

• zugewiesene Aufträge: Jobs, die einem Runner oder einer Runner-Gruppe zugeordnet sind;
• laufende Aufträge: Jobs, die tatsächlich auf einem Mac ausgeführt werden;
• wartende Aufträge: Jobs ohne verfügbaren passenden Runner;
• bereitstellbare Mac-Kapazität: Hosts, die Ihr System innerhalb der zulässigen Zeit liefern kann.

Ein Anstieg bei TotalAssignedJobs bedeutet daher nicht automatisch, dass dieselbe Anzahl neuer Macs benötigt wird. Ein Auftrag kann bereits einem noch nicht bereiten Runner zugewiesen sein, während ein anderer Runner zwar registriert, aber wegen macOS-Initialisierung noch nicht einsatzfähig ist. Die offizielle Scale-Set-Beschreibung sollte für die jeweilige Semantik der Meldungen und Zustände maßgeblich sein.

Messgrößen für die elastische Kapazität

Führen Sie für jede Job-Klasse mindestens diese Messreihen:

1. Zeitstempel des Job-Eingangs;
2. Zeitpunkt der Zuweisung;
3. Zeitpunkt der Host-Bereitschaft;
4. Zeitpunkt der Runner-Registrierung;
5. Zeitpunkt des ersten akzeptierten Jobs;
6. Zeitpunkt der Bereinigung und Rückgabe des Hosts.

Diese sechs Zeitpunkte erlauben Ihnen, Queue-Zeit, Bereitstellungszeit und tatsächliche Ausführungszeit zu trennen. Ohne diese Trennung kann ein scheinbarer Skalierungserfolg lediglich bedeuten, dass Jobs schneller zugewiesen werden, während sie weiterhin auf die Mac-Bereitstellung warten.

Vergleichen Sie anschließend zwei Betriebsarten:

• Reine Nachfrageskalierung: Jeder zusätzliche Host wird erst bei nachgewiesenem Bedarf erstellt. Dadurch sinkt die Leerkapazität, aber der erste Job einer Spitze trägt die gesamte Bereitstellungszeit.
• Begrenzte Vorwärmung: Eine festgelegte Grundkapazität bleibt betriebsbereit, weitere Macs werden nur bei Bedarf geliefert. Dadurch wird ein Teil der Startlatenz abgefangen, während die Spitzenkapazität elastisch bleibt.

Die richtige Mindestkapazität lässt sich nicht seriös aus einer allgemeinen Empfehlung ableiten. Sie benötigen Ihre eigene Verteilung von Job-Ankünften, Laufzeiten, Xcode-Initialisierung und Fehlern. Wenn die Queue regelmäßig während des Host-Starts wächst, ist ein vollständig bedarfsgesteuerter Pool für interaktive Pull-Request-Rückmeldungen wahrscheinlich die falsche Betriebsart.

SECTION 04JIT-Isolation und die tatsächliche Löschgrenze

Ein JIT Runner ist kein Synonym für einen sauberen Mac. Der JIT-Lebenszyklus beschreibt, wie ein Runner kurzfristig konfiguriert und anschließend aus dem Runner-System entfernt wird. Er beweist nicht, dass der macOS-Host, der Benutzerbereich, der Arbeitsbereich oder die Keychain vernichtet wurde.

Sie müssen daher vier Lebenszyklen getrennt abnehmen:

• Runner-Registrierung: Ist der Runner nach dem Job abgemeldet und nicht mehr für neue Aufträge verfügbar?
• Host-Lebenszyklus: Wird der gesamte Mac zurückgesetzt, neu installiert oder verworfen?
• Arbeitsbereich: Werden Repository-Dateien, Artefakte, temporäre Dateien und Tool-Caches entfernt?
• Keychain und Identität: Werden Zertifikate, Provisioning-Profile, Tokens und Entsperrungszustände sicher entfernt?

Die GitHub-Dokumentation zur sicheren Verwendung weist auf die Risiken selbst gehosteter Runner bei nicht vertrauenswürdigem Code hin. Besonders kritisch sind Pull Requests aus Forks, externe Beiträge und Workflows, die Shell-Befehle, Umgebungsvariablen oder Artefakte kontrollieren können.

Für die Abnahme eines elastischen Mac Runner genügt deshalb kein erfolgreicher grüner Build. Sie sollten nach einem absichtlich markierten Testauftrag prüfen, ob:

• der Runner nicht erneut in der Runner-Gruppe erscheint;
• der Arbeitsbereich nicht auf dem Host verbleibt;
• die Keychain keine verwendbaren Testgeheimnisse mehr enthält;
• temporäre Logs und Artefakte extern gesichert wurden;
• der Host nicht versehentlich für einen anderen Repository-Kontext wiederverwendet wird.

Produktionssignierung gehört standardmäßig nicht in dieselbe elastische Ausführungsumgebung wie untrusted Branches. Die Trennung sollte über Runner-Gruppen und Zugriffskontrollen umgesetzt werden. Ein Label wie macos-signing ist allein keine Sicherheitsgrenze, wenn ein anderes Repository dieselbe Gruppe oder dieselben Secrets verwenden darf.

SECTION 05Startlatenz als Lieferkette

Bei Mac CI wird „Startzeit“ oft zu grob gemessen. Für eine belastbare Entscheidung zerlegen Sie sie in einzelne Phasen:

1. Host ist physisch oder logisch verfügbar.
2. macOS ist vollständig gestartet und der erforderliche Benutzerkontext ist bereit.
3. Netzwerk, SSH, Remote-Zugriff und Monitoring funktionieren.
4. Der Runner wird registriert und authentifiziert.
5. Xcode, SDKs, Zertifikate und Abhängigkeiten sind verfügbar.
6. Der erste Job wird angenommen.

Diese Phasen haben unterschiedliche Fehlerbilder. Ein gestarteter Mac kann beispielsweise noch gesperrt sein, während der Runner-Prozess bereits läuft. Ein registrierter Runner kann den Job annehmen, obwohl Xcode beim ersten Zugriff Komponenten initialisiert. Eine vermeintliche Skalierung kann dadurch die Queue lediglich von GitHub in die Host-Initialisierung verschieben.

Vergleichen Sie drei Betriebsmodelle:

Vollständig bedarfsgesteuerte Macs

Dieses Modell minimiert Leerkapazität und eignet sich für Jobs, deren Nutzer eine längere Rückmeldung akzeptieren. Es ist weniger geeignet für häufige Pull-Request-Prüfungen, wenn die Host-Lieferung und Xcode-Bereitschaft einen wesentlichen Anteil der Gesamtzeit ausmachen.

Kleine vorgewärmte Grundkapazität

Hier bleiben einige Macs für typische Validierungsjobs bereit. Zusätzliche Hosts werden nur bei Lastspitzen geliefert. Das reduziert den Druck auf die Provisionierung, verlangt aber eine Regel für Alter, Patchstand und Bereinigung der warmen Knoten.

Fester Basis-Pool mit elastischer Ergänzung

Der feste Pool übernimmt Signierung, Release-Archive und Aufgaben mit empfindlichen Caches. Der elastische Pool verarbeitet parallelisierbare Tests und wiederaufbaubare PR-Builds. Für viele Unternehmen ist dies der robusteste Übergang, weil ein Fehler im Scale-Set-Pfad nicht automatisch die gesamte Release-Pipeline blockiert.

Verwenden Sie für jede Variante reale Unternehmensdaten. Versionsabhängige Initialisierung, Abhängigkeitstransfers und Xcode-Vorbereitung dürfen nicht als allgemeine Leistungswerte behauptet werden. Wenn Sie Remote-Macs als elastische Ergänzung prüfen, dokumentieren Sie Host-Bereitstellung, Zugriff, Rückgabe und Fehlerumschaltung separat; eine Übersicht der verfügbaren MACNOX-Mietoptionen kann dabei als Beschaffungsreferenz dienen, ersetzt aber keine eigene CI-Abnahme.

SECTION 06Kontrollfläche, Berechtigungen und Wiederanlauf

Der Client ist nur dann betriebssicher, wenn auch die Kontrollfläche abgesichert und beobachtbar ist. Prüfen Sie zunächst, ob die verwendete GitHub-App oder das Token nur die für Scale Sets und Runner-Verwaltung erforderlichen Berechtigungen besitzt. Die Authentifizierungsanforderungen des offiziellen Projekts sind dabei die technische Referenz; vermeiden Sie breit gefasste Organisationsrechte als schnelle Abkürzung.

Danach testen Sie diese Fehlerfälle:

• Der Client beendet sich während der Runner-Registrierung.
• Die Mac-Bereitstellung gelingt, aber der Host meldet sich nicht zurück.
• Ein Auftrag wird zugewiesen, bevor der Host tatsächlich bereit ist.
• Eine Nachricht wird erneut zugestellt.
• Der Host verliert die Netzwerkverbindung während des Jobs.
• Die Bereinigung schlägt fehl, während der Runner weiterhin sichtbar ist.

Ihre Implementierung muss bei wiederholten Nachrichten idempotent bleiben. Das bedeutet: Eine erneute Zustellung darf nicht unkontrolliert einen zweiten Host für denselben Zustand erstellen oder einen bereits verworfenen Runner wieder freischalten. Die genaue Umsetzung hängt von Ihrer Provisionierungslogik ab; sie darf nicht aus einer bloßen Prozessüberwachung abgeleitet werden.

Diagnoselogs müssen vor der Zerstörung des temporären Hosts an einen externen Speicher übertragen werden. Das betrifft mindestens Client-Logs, Provisionierungsereignisse, Runner-Zustand, Job-Zuordnung und den Grund für die Rückgabe. Die offizielle Monitoring- und Troubleshooting-Dokumentation ist für die GitHub-seitige Diagnose nützlich, deckt aber nicht automatisch Ihre Mac-Lieferkette ab.

Definieren Sie außerdem eine Rückfallroute:

1. elastischen Pool pausieren;
2. neue, nicht kritische Jobs auf den festen Pool umleiten;
3. Produktionssignierung unverändert auf dedizierten Knoten ausführen;
4. fehlerhafte Hosts sperren und Logs sichern;
5. erst nach einer erfolgreichen Wiederanlaufprobe wieder skalieren.

Ein Backup-Runner-Prozess allein ist keine Wiederanlaufstrategie, wenn der Mac nicht mehr erreichbar ist.

SECTION 07FAQ zur Auswahl des Mac-Pools

Kann der Runner Scale Set Client Mac-Buildmaschinen selbst bereitstellen?

Nein. Der Client stellt die Verbindung zur Scale Set API und zum Runner-Lebenszyklus her, aber Ihre Plattform muss den tatsächlichen Mac liefern, initialisieren, entsperren, überwachen und nach dem Auftrag zurückbauen. Ohne diese Kette bleibt die Skalierung theoretisch. Prüfen Sie daher Host-Provisionierung und Löschung als eigenständige Abnahmekriterien.

Benötigt ein elastischer Mac Runner zwingend Kubernetes?

Nein. Kubernetes kann eine passende Orchestrierung sein, ist aber keine zwingende Voraussetzung für diese Architektur. Eine eigene API-Steuerung, eine Queue oder ein verwalteter Remote-Mac-Pool kann dieselbe Aufgabe erfüllen. Entscheidend sind Zustandsverwaltung, Wiederholbarkeit und sichere Rückgabe. Der offizielle Leitfaden zur Actions Runner Controller-Integration beschreibt nur einen möglichen Weg.

Trennt ein JIT Runner Xcode-Arbeitsbereich und Signaturgeheimnisse vollständig?

Nein, nicht automatisch. JIT beendet den Runner-Zustand, aber ein wiederverwendeter Mac kann Dateien, Caches, Keychain-Einträge oder Zugangsdaten behalten. Für eine belastbare Grenze muss der Host selbst verworfen oder nachweisbar zurückgesetzt werden. Produktionssignierung sollte deshalb auf dedizierten oder streng vorgewärmten Knoten mit separaten Berechtigungen stattfinden.

Wie sollten feste Mac Runner und ein elastischer Scale Set Pool aufgeteilt werden?

Feste Knoten übernehmen Produktionssignierung, Release-Archive und zeitkritische Aufgaben. Der elastische Pool übernimmt wiederaufbaubare PR-Builds, parallele Tests und Lastspitzen ohne vertrauliche Signaturidentität. Erzwingen Sie diese Zuordnung mit Runner-Gruppen, Repository-Berechtigungen, getrennten Secrets und passenden Workflow-Labels. Eine rein organisatorische Absprache reicht bei mehreren Teams nicht aus.

SECTION 08TCO-Modell ohne erfundene Einsparung

Für den Vergleich sollten Sie keine pauschale Prozentzahl verwenden. Bilden Sie stattdessen die Kosten je Betriebsmodell als Variablen:

Gesamtkosten = feste Mac-Kapazität + vorgewärmte Kapazität + bedarfsgesteuerte Kapazität + Automatisierungsaufwand + Überwachung + Wartung + Ausfallkosten + Sicherheitskontrollen.

Beim festen Pool sind Leerkapazität, Hardwarealter, Ersatzgeräte, Patchfenster und interne Administration die wesentlichen Positionen. Beim elastischen Pool verschieben sich die Kosten in Provisionierung, Bereinigung, externe Logspeicherung, Host-Fehler, Startlatenz und die Pflege der Zustandsautomaten. Ein hybrider Pool verursacht beide Arten von Kosten, kann aber die teure Produktionssignierung von der variablen Testlast entkoppeln.

Ordnen Sie Ihre Pipeline-Aufgaben einzeln zu:

• Pull-Request-Validierung: elastischer Pool, sofern der Job reproduzierbar und ohne Produktionsgeheimnisse ist;
• Simulator- und Unit-Test-Regression: elastischer Pool, wenn Abhängigkeiten reproduzierbar geliefert werden;
• Archivierung und Release-Build: fester oder vorgewärmter vertrauenswürdiger Pool;
• Produktionssignierung: dedizierter Mac mit begrenztem Zugriff und getrenntem Secret-Lebenszyklus.

Der wirtschaftliche Vorteil entsteht nur, wenn die elastische Kapazität tatsächlich Leerlauf vermeidet, ohne neue manuelle Betriebsarbeit in gleicher Größenordnung zu erzeugen. Dokumentieren Sie deshalb für einen begrenzten Piloten Queue-Zeit, Host-Lieferung, Fehlerrate, Wiederanlauf und Bereinigungsnachweis. Vergleichen Sie diese Werte anschließend mit Ihrem festen Pool und nicht mit einem idealisierten Containerbetrieb.

SECTION 09Entscheidung und begrenzter Pilot

Der GitHub Actions Runner Scale Set Client ist für Mac CI im Jahr 2026 einen Pilotversuch wert, aber nicht als pauschaler Ersatz für feste Runner. Sie sollten mit einer Jobklasse beginnen, deren Workspace neu erzeugt werden kann, deren Signaturgeheimnisse nicht produktiv sind und deren Fehlschlag auf einen festen Pool zurückfallen kann.

Lehnen Sie den elastischen Ansatz vorerst ab, wenn Sie Macs nicht zuverlässig bereitstellen und löschen können, wenn die Produktionspipeline dieselben Hosts und Keychains wie untrusted Branches benötigt oder wenn die Startlatenz den gesamten erwarteten Queue-Gewinn aufzehrt.

Ein vollständig selbst beschaffter Mac-Pool gibt Ihnen maximale physische Kontrolle, bindet aber Kapital, benötigt Ersatz- und Wartungsplanung und bleibt bei Lastspitzen unflexibel. Ein kurzfristig zugemieteter Remote-Mac kann schneller zusätzliche Kapazität liefern, bringt jedoch Abhängigkeiten bei Netzwerkzugriff, Host-Rückgabe, Logübertragung und organisatorischer Freigabe mit. Wenn Sie neben der festen Basis temporäre, real erreichbare Macs für einen kontrollierten Test benötigen, können Sie die MACNOX-Remote-Mac-Bestellung als eine mögliche Beschaffungsroute prüfen; Produktionssignierung sollte dabei erst nach Ihrer eigenen Sicherheits- und Wiederanlaufabnahme folgen.

Für die meisten Teams lautet die belastbare Zielarchitektur daher: fester oder vorgewärmter Pool für Signierung und niedrige Latenz, elastischer Scale-Set-Pool für wiederaufbaubare Mac-CI-Last. Starten Sie mit einem begrenzten PR-Pilot, messen Sie jede Lebenszyklusphase und behalten Sie eine funktionierende Rückfallebene, bevor Sie weitere Repositories anschließen.

SECTION 10FAQ

SECTION 11Weiterlesen

• Produktionsfreigabe und Abnahmeliste für Xcode-CI auf dem Mac
• Verwaltete oder selbst gehostete Mac-CI für plattformübergreifende Projekte