GitHub Actions Runner Scale Set Client: Mac-Skalierung 2026 beurteilen

Der Mac Runner bleibt in der Warteschlange, obwohl der Scale Set Client bereits ein Signal verarbeitet? Dann fehlt meist nicht die Skalierungslogik, sondern die automatische Lieferung eines echten Mac-Knotens.

Schnellste Lösung für diese Woche: Setzen Sie den GitHub Actions Runner Scale Set Client nur dann als Pilot ein, wenn Sie Mac-Knoten automatisch anfordern, vorbereiten, registrieren, zurückgeben und extern protokollieren können. Fehlt diese Kette, behalten Sie einen festen Runner-Pool und ergänzen ihn höchstens um einen manuell erweiterbaren Vorwärmepool.

Für wen diese Entscheidung gedacht ist

Dieser Leitfaden richtet sich an DevOps-Ingenieure, die mehrere GitHub Actions Mac Runner betreiben und ihre Kapazität an die Build-Warteschlange anpassen möchten.

Ebenso relevant ist der Vergleich für mobile Plattformteams, die Codesignierung isolieren müssen, sowie für CI-Verantwortliche, die feste Remote-Mac-Knoten, einen Vorwärmepool und aufgabenbezogene Knoten gegeneinander abwägen.

Stand der Prüfung: zuletzt aktualisiert am 06.09.2026. Die Aussagen zum Client, zu selbst gehosteten Runnern, JIT-Konfigurationen und REST-Schnittstellen wurden anhand der in diesem Artikel verlinkten offiziellen Dokumentation und des offiziellen Repository-Status geprüft.

Zeitplan und Entscheidungspunkt

Planen Sie die Einführung nicht als Installationsprojekt, sondern als Beweiskette. Der folgende Ablauf verhindert, dass ein erfolgreicher Runner-Registrierungstest fälschlich als produktionsfähige Elastizität gilt.

In der ersten Woche sollten Sie einen nicht signierenden Test-Workflow verwenden. Danach folgt ein Wiederaufbau eines verworfenen Knotens. Erst wenn beide Durchläufe nachvollziehbar sind, ist eine Entscheidung zwischen Pilot, Parallelbetrieb und Aufschub sinnvoll.

Runner Scale Set Client für Mac: Zuständigkeiten

Der Runner Scale Set Client ist kein fertiger Mac-Verleih und kein automatischer Image-Dienst. Das offizielle Repository beschreibt ihn als Baustein, der Signale des Scale Sets, die Skalierungssteuerung und die JIT-Konfiguration in einen eigenen Bereitstellungsablauf einordnet. Der Status des offiziellen Repositorys ist weiterhin Public Preview; künftige Schnittstellen oder Beispiele dürfen deshalb nicht als stabile Zusage behandelt werden. Zum offiziellen Repository des Runner Scale Set Client

Für Ihre Architektur bedeutet das eine klare Trennung:

• Der Client erkennt beziehungsweise verarbeitet den Bedarf an Runner-Kapazität.
• Ihre Plattform entscheidet, welcher Mac-Knoten angefordert wird.
• Ihr Bereitstellungsdienst installiert oder prüft die Arbeitsumgebung.
• Ihr Rückgabeprozess beendet die Registrierung und bereinigt den Knoten.
• Ihr Logging-System bewahrt Fehler und Zustände außerhalb des Knotens auf.

Die offiziellen Workflow-Hinweise zeigen, dass der Client eine eigene Implementierung der Knotenversorgung voraussetzt. Ablaufbeschreibung des offiziellen Clients Das ist der wichtigste Unterschied zu einer fertigen CI-Flotte: Ein Signal zum Hochskalieren ist noch kein verfügbarer Mac.

Ohne Kubernetes ist dieser Ansatz grundsätzlich möglich. Kubernetes kann eine mögliche Orchestrierung sein, ist aber nicht der eigentliche Nachweis. Eine interne Dienstschicht, eine Mac-Verwaltung oder ein Anbieter mit steuerbarer Maschinen-API kann dieselbe Rolle übernehmen. Entscheidend ist, dass der Übergang von „Warteschlange wächst“ zu „isolierter Mac ist ausführbar“ automatisch und überprüfbar erfolgt.

Wenn Sie aktuell nur einen festen Mac per SSH oder VNC verwalten, ist das kein Gegenargument gegen einen Pilotversuch. Es bedeutet aber, dass Sie den Pilot zunächst auf die Lieferkette konzentrieren sollten, nicht auf maximale Parallelität. Für eine vorhandene feste Flotte können Sie ergänzend den Leitfaden zur GitHub-Actions-Mac-Runner-Abnahme als interne Checkliste verwenden.

Lebenszyklus: fest, vorgewärmt oder temporär

Die Wahl des Runner-Lebenszyklus bestimmt die tatsächliche Isolation stärker als die Skalierungsoberfläche. Ein dauerhaft online betriebener Runner reduziert die Wartezeit für den nächsten Auftrag und kann Caches behalten. Dafür bleiben Arbeitsverzeichnisse, lokale Konfigurationen und möglicherweise verworfene Artefakte länger auf demselben System.

Ein temporärer Mac Runner wird dagegen nach einer Aufgabe abgemeldet oder vollständig verworfen. Das begrenzt die Wiederverwendung eines Arbeitsbereichs, verlangt aber eine verlässliche Wiederherstellung der Entwicklungsumgebung. Ein Vorwärmepool liegt dazwischen: Einige Knoten stehen bereit, zusätzliche Knoten werden erst bei Bedarf geliefert.

Die offiziellen Empfehlungen zu temporären selbst gehosteten Runnern sind deshalb relevant, weil die Isolation nicht mit dem Wort „JIT“ automatisch erledigt ist. GitHub-Dokumentation zum Lebenszyklus selbst gehosteter Runner

Für normale Entwicklungs-Builds kann ein kontrollierter Pilot mit vorgewärmten oder temporären Knoten sinnvoll sein. Signierung und Veröffentlichung sollten Sie dagegen in einen separaten Pool legen. Ein Runner, der einen Auftrag annehmen kann, ist noch kein Runner, dem Sie automatisch Produktionsschlüssel anvertrauen sollten.

JIT bedeutet in diesem Zusammenhang „Just in Time“: Die Konfiguration wird für einen begrenzten Lebenszyklus ausgestellt und verwendet. Sie ersetzt weder die Löschung von Zertifikaten noch die Bereinigung des Dateisystems. Die offiziellen Sicherheitshinweise verlangen eine sorgfältige Behandlung selbst gehosteter Runner, besonders wenn nicht vertrauenswürdige Beiträge oder öffentliche Projekte beteiligt sind. Offizielle Hinweise zur sicheren Nutzung selbst gehosteter Runner

Achtung: Speichern Sie Organisation, Repository, App-ID, Token, Knotennamen und Pfade in Beispielen nur als Platzhalter. In Logs gehören keine echten Zugangsdaten, Signierwerte oder vollständigen JIT-Antworten.

Warteschlange und Kaltstart

Ein einziger Messwert wie „Workflow-Dauer“ reicht für die Entscheidung nicht aus. Zerlegen Sie jeden Testlauf in vier Abschnitte:

1. Warteschlangenzeit: Der Auftrag wartet auf einen passenden Mac Runner.
2. Lieferzeit: Ein Knoten wird angefordert und erreichbar.
3. Umgebungszeit: Xcode, Simulator-Runtime, Abhängigkeiten und Projektzugriff werden vorbereitet.
4. Registrierungszeit: Der JIT Runner meldet sich an und nimmt den Auftrag an.

Diese Trennung zeigt, ob eine Skalierung tatsächlich hilft. Wenn die Warteschlange kurz, die Mac-Lieferung aber unzuverlässig ist, brauchen Sie keine aggressivere Skalierungsregel. Wenn die Lieferung funktioniert, aber die Xcode-Umgebung jedes Mal manuell repariert werden muss, liegt das Problem bei der Reproduzierbarkeit.

Vergleichen Sie mindestens diese drei Betriebsweisen:

• Nur JIT: Maximale Bereitschaft zur Bereinigung, aber jeder Auftrag hängt von einer vollständigen Lieferung und Initialisierung ab.
• Kleiner Vorwärmepool: Ein Teil der Kapazität ist verfügbar, während zusätzliche Knoten bedarfsabhängig entstehen.
• Fester Pool: Geringere Systemkomplexität, dafür weniger Anpassung an Spitzen und möglicherweise mehr Leerlauf.

Verwenden Sie keine allgemeine Schwelle für „zu lange“ Wartezeit. Ihre Xcode-Version, Projektgröße, Caches, Mietdauer und Knotenzustellung bestimmen den sinnvollen Vergleich. Dokumentieren Sie pro Testlauf die vier Zeitabschnitte und ergänzen Sie Rückgabe- sowie Wiederaufbaufehler. Für die Kapazitätsplanung können Sie die Anleitung zur Abschätzung von Mac-CI-Knoten als nächsten internen Themenpfad heranziehen; die dortige Entscheidung muss jedoch mit Ihren eigenen Warteschlangenaufzeichnungen belegt werden.

Reproduzierbarkeit der Mac-Umgebung

Ein erfolgreicher JIT-Registrierungsvorgang beweist nicht, dass der Mac einen echten Xcode-Build ausführen kann. Vor dem Scale-Set-Pilot müssen Sie festlegen, welche Bestandteile deklarativ wiederhergestellt werden:

• Xcode-Version und ausgewählte Toolchain
• benötigte Simulator-Runtimes
• Paketmanager und Projektabhängigkeiten
• Build- und Zwischenartefakte
• Cache-Schlüssel und Cache-Ablauf
• Zertifikate, Profile und Zugriff auf das Signiersystem
• grafische Sitzung, falls ein Test diese voraussetzt

Führen Sie drei getrennte Nachweise aus. Starten Sie einen Build auf einem vollständig neuen Knoten. Wiederholen Sie ihn auf einem Knoten mit bewusst dokumentiertem Cache. Verwerfen Sie den Knoten anschließend und bauen Sie die Umgebung erneut auf. Die Ergebnisse müssen erklären, welche Teile aus dem Cache stammen und welche Schritte zwingend neu ausgeführt wurden.

Achten Sie besonders auf den Unterschied zwischen „Runner ist online“ und „Projekt ist baubereit“. Der Scale Set Client erstellt kein macOS-Image, installiert keine Simulator-Runtime und löst keine grafische Sitzung. Ebenso wird die Codesignierung nicht sicher, nur weil die Registrierung kurzlebig ist.

Wenn die Umgebung heute nur durch manuelle Terminalschritte funktioniert, ist ein fester Runner mit dokumentiertem Wartungsprozess zunächst ehrlicher als eine vermeintlich elastische Flotte. Ein Vorwärmepool kann als Zwischenlösung dienen, solange jeder Knoten regelmäßig verworfen und reproduzierbar neu erstellt wird.

Berechtigungen, Logs und Vertrauenszonen

Für die Authentifizierung sollten Sie die kleinste passende Berechtigung wählen und die Rotation einer klar benannten Rolle zuweisen. Vergleichen Sie eine GitHub-App mit einem persönlichen Zugriffstoken nicht nur nach der erfolgreichen Registrierung, sondern nach Reichweite, Ablauf, Rotation und Ausfallwirkung. Die offizielle REST-Dokumentation beschreibt die Organisationsebene für JIT-Konfigurationen und die zugehörigen Parameter. Dokumentation zur Erzeugung von JIT-Runner-Konfigurationen

Verwenden Sie in Ihrer Betriebsdokumentation ausschließlich Platzhalter wie <ORGANISATION>, <REPOSITORY>, <APP_ID> und <TOKEN>. Ein echtes Token darf weder in einer Beispielausgabe noch in einem Prozessargument oder Diagnosearchiv erscheinen. Prüfen Sie außerdem, ob Ihr Logsystem sensible Antwortfelder maskiert. Referenz zu Parametern und Antworten der JIT-Schnittstelle

Logs müssen außerhalb des Mac-Knotens erhalten bleiben. Übertragen Sie mindestens:

• Zeitpunkt und Grund der Knotenanforderung
• Liefer- und Initialisierungsfehler
• Runner-Registrierung und Rückgabe
• Zuordnung zum Workflow-Lauf
• Ergebnis der Bereinigung
• Wiederaufbau- und Rollback-Status

Teilen Sie Ihre CI-Zonen nach Risiko. Öffentliche Projekte und nicht vertrauenswürdige Pull Requests gehören nicht in denselben Pool wie Signierung und Veröffentlichung. Auch ein temporärer Runner kann während seiner Aufgabe Zugriff auf Geheimnisse erhalten. Der Rückbau senkt das verbleibende Risiko, ersetzt aber keine Berechtigungsbegrenzung und keine Prüfung der Workflow-Herkunft.

Gesamtaufwand statt Laufzeitpreis

Eine elastische Architektur ist nicht automatisch günstiger oder einfacher. Rechnen Sie mindestens diese Kostenarten zusammen:

Vergleichen Sie nicht nur die aktive Buildzeit. Berücksichtigen Sie Mietzyklen, ungenutzte Vorwärmkapazität, Xcode-Initialisierung, fehlgeschlagene Lieferungen, Logspeicherung, Wiederaufbau und die Zeit der verantwortlichen Plattformteams. Ein günstiger Knoten kann durch manuelle Reparaturen zum teureren System werden.

Für einen realistischen Vergleich stellen Sie jedem Modell dieselben Fragen:

1. Wie viele Aufträge warten tatsächlich auf einen Mac?
2. Wie häufig scheitert die Knotenlieferung?
3. Wie oft muss die Umgebung manuell korrigiert werden?
4. Wie lange bleibt ein Vorwärmknoten ungenutzt?
5. Kann ein fehlgeschlagener Build nach dem Knotenverlust rekonstruiert werden?
6. Wie viel Betriebszeit benötigt die Plattformpflege?

Die Entscheidung lässt sich damit in drei Betriebsstufen übersetzen:

• Pilot: Ihre Plattform kann Mac-Knoten automatisch liefern, initialisieren, registrieren, zurückgeben und extern protokollieren.
• Doppelbetrieb: Die Warteschlange schwankt, aber mindestens ein Teil der Automatisierung fehlt. Ein fester Pool bleibt aktiv, während der Vorwärmepool kontrolliert getestet wird.
• Aufschub: Die Aufgaben sind stabil, die Runner-Anzahl ist klein oder die Umgebung lässt sich nicht reproduzierbar herstellen. Dann bringt der Scale Set Client zunächst mehr Betriebsfläche als Nutzen.

FAQ zur technischen Auswahl

macOS-Unterstützung und Zuständigkeit

Der Runner Scale Set Client kann für selbst gehostete macOS Runner verwendet werden, sofern Ihre eigene Versorgungsschicht die entsprechenden Knoten bereitstellt. Das ist eine wichtige Abgrenzung zu einer fertigen Mac-Plattform: Die offizielle Unterstützung des Client-Ablaufs bedeutet nicht, dass Ihre Organisation automatisch einen funktionierenden Mac erhält.

Automatische Erweiterung nach Warteschlange

Ein Signal aus der GitHub-Actions-Warteschlange muss mit einer konkreten Knotenanforderung verbunden werden. Danach folgen Erreichbarkeit, Umgebungsaufbau, JIT-Registrierung und Aufgabenzuordnung. Wenn einer dieser Schritte manuell bleibt, sollten Sie die Lösung als festen Pool mit begrenzter Automatisierung bezeichnen, nicht als vollständig elastische Mac-Flotte.

Temporärer oder dauerhafter Mac Runner

Dauerhafte Runner sind für kontrollierte Entwicklungsaufgaben bequem, weil sie sofort verfügbar sind und Caches behalten können. Temporäre Runner schaffen eine stärkere Trennung zwischen Aufgaben, verlangen aber eine belastbare Umgebungserstellung. Für Codesignierung und Veröffentlichung ist ein separater, kurzlebiger Pool die sicherere Architektur als ein gemeinsam genutzter Dauerläufer.

Betrieb ohne Kubernetes

Kubernetes ist keine Voraussetzung für das Grundprinzip. Der Client kann mit einer anderen Bereitstellungslogik verbunden werden, solange diese Mac-Systeme anfordert und ihren Zustand verfolgt. Ohne Kubernetes müssen Sie die fehlenden Orchestrierungsfunktionen selbst abdecken: Warteschlangenabgleich, Fehlerbehandlung, Rückgabe, Wiederholung, Protokollierung und Bereinigung.

Xcode-Caches und Codesignierung im JIT-Lebenszyklus

Ein Cache darf den vollständigen Aufbau nicht ersetzen. Legen Sie Xcode und Abhängigkeiten reproduzierbar fest und prüfen Sie einen Neuaufbau nach dem Verwerfen des Knotens. Signiermaterial sollte nur für die dafür vorgesehenen Aufgaben bereitgestellt werden. JIT begrenzt die Lebensdauer der Konfiguration, schützt aber nicht vor falsch freigegebenen Geheimnissen oder unbereinigten Logs.

Nächster Test und geeignete Mac-Versorgung

Wenn Ihre heutige Lösung aus einem festen Remote-Mac-Pool besteht, erhalten Sie Stabilität, bezahlen aber auch für bereitgehaltene Kapazität und müssen gemeinsam genutzte Arbeitsbereiche konsequent pflegen. Eine selbst verwaltete, lokale Mac-Flotte bindet außerdem Kapital, Wartungszeit und physische Geräte an Ihre CI-Spitzen. Eine vollständig neue Knotenbereitstellung kann diese Probleme reduzieren, erhöht jedoch die Anforderungen an Wiederherstellung, Monitoring und Umgebungsdefinition.

Für einen Pilotbetrieb ist deshalb eine unabhängig rekonstruierbare Mac-Instanz sinnvoll. VMSPIN kann Ihnen dafür einen echten Remote-Mac-Knoten als Testumgebung bereitstellen, ohne dass Sie sofort eigene Hardware beschaffen müssen. Prüfen Sie die verfügbaren Mac-Mietoptionen bei VMSPIN zunächst gegen Ihre Anforderungen an Zugriffsrechte, Laufzeit und Automatisierung.

Starten Sie mit einem nicht veröffentlichenden Workflow und testen Sie in dieser Reihenfolge:

1. Mac-Knoten anfordern und eindeutige Kennung protokollieren.
2. Xcode-Umgebung und Abhängigkeiten automatisiert herstellen.
3. JIT Runner registrieren und einen isolierten Build ausführen.
4. Logs außerhalb des Knotens speichern und geheime Felder maskieren.
5. Runner abmelden, Knoten zurückgeben oder verwerfen.
6. Einen neuen Knoten erzeugen und denselben Build erneut ausführen.
7. Warteschlange, Lieferzeit, Initialisierung und Wiederaufbau getrennt bewerten.

Verschieben Sie Signierung und Veröffentlichung erst dann in diesen Ablauf, wenn die Trennung der Vertrauenszonen und die Logaufbewahrung nachweisbar funktionieren. Der GitHub Actions Runner Scale Set Client ist damit ein sinnvoller Steuerungsbaustein für ein bereits automatisiertes Mac-Lebenszyklusmodell, aber kein Ersatz für dieses Modell.