GitHub Actions Mac Runner fest oder elastisch? Lösung 2026

Am 05.09.2026 ist der offizielle Runner Scale Set Client weiterhin als „Public Preview“ gekennzeichnet. Daraus folgt eine klare Arbeitsentscheidung: Bei stabiler Last, wenigen Repositories und teuren Toolchain-Starts bleibt ein fester Mac Runner die einfachere Wahl. Bei planbaren Veröffentlichungsspitzen, vielen Repositories oder strengeren Isolationsanforderungen sollte ein temporärer Runner-Pool die Last aufnehmen. Für die meisten Teams ist ein fester Grundbestand plus elastische Spitzenkapazität sinnvoller als eine vollständige Umstellung.

Diese Woche empfehlen wir: Ermitteln Sie zunächst aus den Workflow-Daten die tägliche Grundlast, die längste Warteschlange und die tatsächliche Bereitstellungszeit eines zusätzlichen Mac Hosts. Markieren Sie danach Signierungsjobs separat. Erst wenn diese drei Werte belastbar sind, entscheiden Sie über feste Runner, ephemeral runner oder ein Doppelmodell.

Diese Analyse richtet sich an mobile Entwicklungsteams, die Warteschlangen bei Veröffentlichungen verkürzen und zugleich dauerhaft ungenutzte Mac Kapazität vermeiden möchten. Sie ist außerdem für DevOps- und Plattformteams relevant, die Registrierung, Routing, Isolation und Rückgabe entwerfen. Sicherheits- und Release-Verantwortliche erhalten Kriterien dafür, ob Schlüsselbunde, Zertifikate und private Abhängigkeiten auf temporären Hosts vertretbar sind.

Die Entscheidung beginnt mit dem Lastprofil, nicht mit der Teamgröße

Ein häufiger Fehlstart besteht darin, die Zahl der Entwickler als Kapazitätsmaß zu verwenden. Für GitHub Actions Mac Runner ist jedoch entscheidender, wie viele Builds gleichzeitig auf den Host treffen, wie lange sie warten und welche Aufgaben nur auf einem bestimmten Xcode- oder Apple-Silicon-Setup laufen.

Ein Team mit vielen Entwicklern kann eine kleine, gleichmäßige Grundlast erzeugen. Ein kleineres Team kann durch einen gebündelten Release-Prozess eine kurze, aber kritische Spitze auslösen. Deshalb sollten Sie für einen repräsentativen Zeitraum mindestens diese Workflow-Eigenschaften auswerten:

• Wartezeit zwischen Job-Bereitschaft und tatsächlichem Start;
• belegte Zeit des Runners;
• Abbruch- und Wiederholungsgründe;
• Xcode-Version, Zielplattform und Signierungsbedarf;
• Anteil der Jobs mit großen Cache- oder Toolchain-Initialisierungen;
• Zeit zwischen dem Skalierungssignal und einem registrierten Mac Runner.

Die ersten beiden Werte zeigen, ob überhaupt ein Kapazitätsproblem besteht. Die Fehlergründe verhindern, dass ein langsamer oder falsch gerouteter Job fälschlich als Mangel an Runnern interpretiert wird. Die letzten drei Werte entscheiden, ob elastische Kapazität rechtzeitig verfügbar sein kann.

Die offiziellen Hinweise zu selbst gehosteten Runnern betonen, dass die Verantwortung für Betrieb, Sicherheit und Wartung beim Betreiber liegt. Das betrifft nicht nur die Registrierung, sondern auch Updates, Netzwerkzugriff, Logs und die Kontrolle der ausgeführten Workflows. Die Referenz für selbst gehostete Runner sollte deshalb als Betriebsgrundlage und nicht nur als Installationsanleitung gelesen werden.

Achtung: Ein kurzer Release-Stau ist noch kein Beweis dafür, dass ein weiterer dauerhafter Mac benötigt wird. Prüfen Sie zuerst, ob die Spitze vorhersehbar ist und ob ein zusätzlicher Host schneller bereitsteht, als die Warteschlange ohnehin abgebaut wäre.

Feste Knoten bleiben bei teurer Toolchain-Vorbereitung im Vorteil

Ein fester Mac Runner ist besonders dann plausibel, wenn die Aufgabenquelle überschaubar ist, die Workflows regelmäßig laufen und Xcode, Zertifikate sowie Abhängigkeiten nicht bei jedem Auftrag neu vorbereitet werden sollen. Das ist kein Argument für einen unkontrollierten „Shared Host“, sondern für einen dauerhaft gepflegten Knoten mit enger Zugriffsgrenze.

Die Vorteile liegen in der betrieblichen Einfachheit:

1. Die benötigte Xcode-Version und zusätzliche Werkzeuge bleiben zwischen den Jobs verfügbar.
2. Fehler lassen sich auf einem bekannten Host leichter reproduzieren.
3. Interne Abhängigkeiten und Netzwerkpfade müssen nicht für jeden Auftrag neu ausgehandelt werden.
4. Ein Notfall-Release kann auch dann anlaufen, wenn die elastische Steuerung ausfällt.
5. Die Plattformmannschaft muss nicht mehrere Bereitstellungswege gleichzeitig debuggen.

Diese Vorteile kippen jedoch, wenn mehrere unabhängige Repositories denselben Host verwenden. Arbeitsverzeichnisse, temporäre Dateien, lokale Caches und Anmeldedaten können nach einem Job verbleiben. Auch ein sauber beendeter Workflow garantiert nicht automatisch, dass sämtliche Host-Zustände entfernt wurden.

Für feste Knoten sollten Sie deshalb Repository-Zugriff und Routing ausdrücklich begrenzen. Runner Groups eignen sich, um festzulegen, welche Repositories einen Runner verwenden dürfen; die Dokumentation zu Runner Group-Zugriffen beschreibt diese Berechtigungsebene. Ergänzend müssen Labels präzise genug sein, damit beispielsweise ein Signierungsjob nicht versehentlich auf einem allgemeinen Test-Runner landet. Die GitHub-Anleitung zu Runner-Labels ist dafür die maßgebliche Referenz.

Ein fester Runner braucht außerdem einen Wartungsplan, einen erreichbaren Ersatzweg und eine Regel für verdächtige Zustände. Wenn ein Host nach einem fehlgeschlagenen Job nicht eindeutig sauber ist, sollte er aus dem Routing genommen werden, bis die Prüfung abgeschlossen ist.

Release-Spitzen rechtfertigen nicht automatisch dauerhafte Kapazität

Veröffentlichungen, große Merges und gemeinsame Testfenster erzeugen oft eine deutlich höhere Last als der normale Entwicklungsbetrieb. Der wirtschaftliche Fehler besteht darin, diese Spitze als neue tägliche Grundlast zu behandeln. Der technische Fehler besteht darin, eine elastische Kapazität zu versprechen, ohne ihre Lieferkette zu messen.

Vergleichen Sie drei Modelle:

Für eine belastbare Entscheidung genügt kein theoretisches Autoscaling-Diagramm. Messen Sie mit einem ungefährlichen Testworkflow:

1. Erzeugen Sie eine kontrollierte Warteschlange mit mehreren nicht signierenden Testjobs.
2. Erfassen Sie den Zeitpunkt des Skalierungssignals.
3. Protokollieren Sie, wann ein Mac Host verfügbar und wann der Runner registriert ist.
4. Prüfen Sie, ob der Job auf dem erwarteten Label startet.
5. Halten Sie fest, wann der Runner abgemeldet und der Host tatsächlich zurückgesetzt wurde.

Die relevante Größe ist nicht nur die Zahl der Runner, sondern die Zeit bis zur nutzbaren Ausführung. Ein Pool, der erst nach Ende der Veröffentlichungsspitze bereitsteht, löst das Problem nicht. Umgekehrt kann ein vorgewärmter Pool unnötige Kosten und zusätzliche Angriffsfläche erzeugen, wenn die Spitze selten auftritt.

Wenn der normale Betrieb mit einem festen Grundbestand funktioniert, sollte dieser Bestand die wichtigsten Builds und mindestens den Notfallpfad tragen. Der elastische Teil ist dann für zusätzliche Testjobs, parallele Artefakterstellung oder eine zeitlich begrenzte Release-Welle zuständig.

Gemeinsame Mac Kapazität verlangt eine Trennung nach Vertrauen und Aufgabe

Bei mehreren Repositories ist die Frage „fest oder elastisch?“ unvollständig. Zuerst muss geklärt werden, welche Aufgaben überhaupt denselben Host berühren dürfen. Ein öffentlicher Pull Request, ein internes Testprojekt und ein signierter Produktionsrelease gehören nicht automatisch in dieselbe Runner Group.

Wir empfehlen eine Aufteilung entlang von vier Eigenschaften:

• Vertrauensstufe des Repositorys und der auslösenden Änderung;
• benötigte Xcode- und SDK-Version;
• Zugriff auf interne Paketquellen oder private Netzwerke;
• Zugriff auf Schlüsselbund, Zertifikate oder Veröffentlichungsprofile.

Danach werden Runner Groups und Labels so kombiniert, dass der Workflow seine Absicht eindeutig ausdrückt. Ein allgemeines Label wie macos ist für eine Organisation mit mehreren Xcode-Versionen zu grob. Aussagekräftigere interne Bezeichnungen könnten etwa ios-test-arm64 oder release-signing-isolated sein; die Namen sind nur Platzhalter und sollten keine geheimen Infrastrukturinformationen enthalten.

Ein ephemeral runner verringert die Lebensdauer der Runner-Registrierung, aber nicht automatisch die Lebensdauer des zugrunde liegenden Mac Hosts. Das ist die wichtigste Abgrenzung dieses Beitrags. Nach der Abmeldung können auf dem Host weiterhin Arbeitsverzeichnisse, Caches, Schlüsselbundreste, Shell-Historien oder lokale Protokolle existieren. Die Bereinigung muss daher auf Host-Ebene nachgewiesen werden.

Für die Abnahme eines gemeinsam genutzten Pools gehören mindestens diese Nachweise in die Dokumentation:

• Der Job wird nur aus den erlaubten Repositories angenommen.
• Das erwartete Label führt nicht auf einen höher privilegierten Pool.
• Arbeitsverzeichnisse werden nach dem Auftrag entfernt.
• Temporäre Zugangsdaten werden widerrufen oder überschrieben.
• Externe Logs bleiben verfügbar, wenn der Host ausfällt.
• Ein beschädigter Host wird automatisch oder manuell aus dem Routing genommen.

Die Sicherheitsleitlinie für selbst gehostete Runner ist besonders bei Workflows aus Forks, bei erweiterten Berechtigungen und bei vertraulichen Variablen relevant. Sie ersetzt keine eigene Bedrohungsanalyse, liefert aber die notwendige Grundlage für die Entscheidung, welche Jobs überhaupt auf einer gemeinsam verwalteten Maschine laufen dürfen.

Signierung bleibt ein eigener Betriebsbereich

Normale Kompilierung und Tests lassen sich meist leichter elastisch ausführen als Veröffentlichungsjobs. Sobald ein Workflow auf Schlüsselbunde, Zertifikate, interne Paketquellen oder ein privates Netzwerk zugreift, steigen die Anforderungen an Wiederholbarkeit und Rücknahme deutlich.

Ein fester Signierungs-Runner ist vertretbar, wenn:

• die Zahl der zugelassenen Repositories klein ist;
• die Zugriffsrechte des Workflows eng begrenzt sind;
• der Host überwacht und regelmäßig kontrolliert wird;
• ein Ersatz- oder Wiederherstellungsverfahren existiert;
• die Signierungsaufgabe nicht zusammen mit untrusted Code ausgeführt wird.

Ein temporärer Signierungs-Runner ist nur dann sinnvoll, wenn die gesamte Kette automatisiert und nachweisbar ist. Dazu gehören die Ausgabe kurzlebiger Zugangsdaten, die kontrollierte Installation in einem isolierten Schlüsselbund, der Zugriff auf private Abhängigkeiten, der Widerruf nach dem Job und die sichere Rückgabe des Hosts. Ein bloßes Abmelden des Runners reicht nicht.

In der Praxis ist eine Aufteilung meist robuster: Der feste, stark eingeschränkte Pool übernimmt Signierung und kritische Veröffentlichungen; ein elastischer Pool verarbeitet gewöhnliche Builds, Tests und nicht privilegierte Artefakte. So wird die teure Sicherheitsdomäne nicht unnötig auf jeden Pull Request ausgeweitet.

Runner Scale Set Client ist Steuerung, nicht Mac-Bereitstellung

Der Runner Scale Set Client ist für Teams interessant, die GitHub Actions mit einer eigenen elastischen Infrastruktur verbinden möchten. Laut dem offiziellen Repository des Clients dient er der Kommunikation mit der Runner-Scale-Set-API und der Erzeugung temporärer Runner-Konfigurationen. Der Mac Host selbst wird dadurch nicht automatisch gekauft, gestartet, konfiguriert, bereinigt oder zurückgegeben.

Das unterscheidet diesen Ansatz deutlich von einem Kubernetes-orientierten Modell. Der offizielle Überblick zum Actions Runner Controller beschreibt Runner Pods und Kubernetes-Ressourcen. Diese Mechanik darf nicht direkt auf physische oder virtuelle Mac Hosts übertragen werden. Ein realer Mac braucht eine eigene Lieferkette für Stromzustand, Betriebssystem, Netzwerk, Remotezugriff, Image- oder Konfigurationspflege und sichere Rücknahme.

Die minimale technische Prüfkette besteht aus fünf Stationen:

1. GitHub Actions erzeugt ein belastbares Warteschlangen- oder Skalierungssignal.
2. Die eigene Infrastruktur stellt einen geeigneten Mac Host bereit.
3. Der Host erhält eine temporäre Konfiguration und registriert genau einen Runner.
4. Der Workflow läuft auf dem vorgesehenen Label und schreibt externe Logs.
5. Nach dem Job werden Runner und Host getrennt behandelt: Registrierung entfernen, Daten bereinigen, Host stilllegen oder zurückgeben.

Der fünfte Schritt ist die häufigste Lücke. Eine erfolgreiche Runner-Abmeldung beweist nicht, dass die Maschine sauber ist. Bei einem Fehler in der Bereitstellung, einem abgebrochenen Job oder einem Updateproblem muss die Plattform erkennen, ob ein Host wiederverwendbar, zu isolieren oder vollständig zu ersetzen ist.

Fünf Entscheidungsschwellen für die Auswahl

Verwenden Sie die folgenden Bedingungen als operative Entscheidungsliste:

• Wenn die tägliche Last stabil ist, wenige Repositories beteiligt sind und Xcode- sowie Cache-Zustände lange erhalten bleiben müssen, wählen Sie feste Runner. Sonst prüfen Sie ein elastisches Element.
• Wenn Veröffentlichungsspitzen planbar sind und die gemessene Host-Lieferzeit deutlich innerhalb des akzeptablen Wartens liegt, wählen Sie einen temporären Spitzenpool. Sonst behalten Sie mehr feste Reserve.
• Wenn Repositories unterschiedliche Vertrauensstufen oder private Netzwerkpfade haben, teilen Sie die Pools nach Runner Groups und Labels. Sonst bleibt ein gemeinsamer Pool nur bei nachgewiesener Bereinigung vertretbar.
• Wenn Signierung eine wiederholbare Geheimnisinjektion und einen geprüften Widerruf besitzt, kann sie temporär ausgeführt werden. Sonst bleibt sie auf einem festen, stark eingeschränkten Runner.
• Wenn ein Ausfall des Scale-Set-Clients oder der Mac-Bereitstellung die nächste Veröffentlichung blockieren würde, halten Sie einen festen Grundbestand als Fallback. Sonst ist eine vollständige elastische Umstellung erst nach einer realen Störungsübung vertretbar.

Bewerten Sie die Optionen nicht nur nach Kosten. Unsere qualitative Bewertung ergibt für typische Plattformteams: fester Grundbestand 4 von 5 Punkten bei Verfügbarkeit und Wiederholbarkeit, temporärer Pool 4 von 5 Punkten bei Isolation und Lastspitzen, vollständige Elastik jedoch nur 2 von 5 Punkten bei der betrieblichen Einfachheit, solange die Host-Lieferkette noch nicht erprobt ist. Diese Punktzahlen sind ein Entscheidungsmodell, keine Performance-Messung.

Erfahrungshinweis: Testen Sie die Rückgabe nicht erst nach dem ersten Sicherheitsvorfall. Ein absichtlich abgebrochener Testjob mit anschließender Host-Prüfung zeigt schneller, ob „ephemeral“ in Ihrer Umgebung wirklich bis zur Maschine durchgesetzt wird.

Ausfälle brauchen einen festen Rückfallweg

Elastische Systeme versagen an mehreren Stellen: Das Skalierungssignal kann ausbleiben, der Mac Host kann nicht starten, die Runner-Registrierung kann hängen oder ein Update kann den Runner unbrauchbar machen. Für jeden dieser Fälle sollte ein Workflow nicht endlos warten.

Legen Sie deshalb vor dem Rollout fest:

• nach welcher Wartezeit ein Job als blockiert gilt;
• wann weitere Skalierung pausiert wird;
• welcher feste Runner kritische Veröffentlichungen übernimmt;
• wer eine manuelle Bereitstellung starten darf;
• wie fehlende externe Logs nachgetragen werden;
• wann ein beschädigter Host ersetzt statt repariert wird.

Die offizielle Anleitung zur Überwachung und Fehlersuche unterstützt die Diagnose von Runner-Zustand und Workflow-Problemen. Für die eigene Plattform müssen Sie zusätzlich die Host-Lieferung und die Rückgabe protokollieren. Die Dokumentation zum Hinzufügen selbst gehosteter Runner ist dabei nur der Registrierungsteil, nicht der vollständige Lebenszyklus.

Eine belastbare Betriebsübung sollte mindestens einen fehlgeschlagenen Start, einen abgebrochenen Job, einen fehlenden Logkanal und einen nicht erreichbaren temporären Host simulieren. Erst wenn der feste Grundbestand in diesen Fällen eine Veröffentlichung ermöglicht, ist das Doppelmodell ausreichend abgesichert.

Häufige Fragen zur elastischen Mac Runner-Skalierung

Kann ein selbst gehosteter Mac Runner in GitHub Actions automatisch mitwachsen?

Ja, eine automatische Skalierung ist möglich, aber nicht allein durch GitHub Actions. Der Runner Scale Set Client liefert die Anbindung an die Scale-Set-API und temporäre Runner-Konfigurationen. Ihr eigenes System muss weiterhin reale Mac Hosts bereitstellen, starten, registrieren, überwachen und nach dem Job zuverlässig zurückbauen. Ohne diese Infrastruktur entsteht kein belastbarer Autoscaling-Betrieb.

Sind feste Mac Runner oder temporäre Runner besser für Xcode CI?

Feste Runner passen besser zu wenigen, stabilen Workflows mit hohem Xcode- und Cache-Anteil oder komplexem Signierungszustand. Temporäre Runner sind vorzuziehen, wenn viele Repositories geteilt werden, Builds stark schwanken oder eine saubere Trennung pro Auftrag erforderlich ist. Für die meisten Teams ist ein fester Grundbestand mit einem temporären Spitzenpool der kontrollierbarste Kompromiss.

Unterstützt der Runner Scale Set Client macOS Hosts?

Der offizielle Client kann laut Repository auch für benutzerdefinierte elastische Runner-Lösungen mit macOS eingesetzt werden und vermittelt API-Signale sowie temporäre Konfigurationen. Er erstellt jedoch keinen Mac Host automatisch und ersetzt keine Bereitstellungs- oder Löschlogik. Außerdem ist der Stand am 05.09.2026 weiterhin als Public Preview gekennzeichnet.

Wie verhindere ich nach der Mac Runner-Skalierung eine Verschmutzung zwischen Repositories?

Trennen Sie Runner Groups und Labels nach Vertrauensstufe, Xcode-Version und Aufgabentyp. Ein ephemeral runner wird zwar nach dem Auftrag abgemeldet, aber das beweist nicht, dass Arbeitsverzeichnis, Schlüsselbund, Caches oder lokale Zugangsdaten vom Host entfernt wurden. Für sensible Builds brauchen Sie daher Host-Rotation oder eine nachweisbare Bereinigung mit extern gespeicherten Logs.

Sollten wir für Xcode-Veröffentlichungen feste Knoten erweitern oder Macs nur zeitweise mieten?

Wenn die Veröffentlichungsspitzen selten und planbar sind, ist ein zeitweise zugeschalteter Mac Pool meist vernünftiger als dauerhaft zusätzliche Kapazität. Der feste Grundbestand sollte kritische Freigaben und Notfälle tragen können. Vor der Entscheidung müssen Sie jedoch prüfen, ob Bereitstellung, Netzwerkzugang, Zertifikatsinjektion und Runner-Registrierung innerhalb des zulässigen Wartens funktionieren.

Wenn heute ein Teil der Builds auf dauerhaft reservierten Macs läuft, während die Release-Spitzen trotzdem warten, bezahlen Sie wahrscheinlich für die falsche Kapazitätsform: feste Knoten bleiben außerhalb der Spitzen ungenutzt, teilen möglicherweise zu viele Arbeitszustände und machen Wartungsfenster schwerer planbar. Ein reines Cloud- oder VM-Modell kann dagegen bei Apple-Silicon-Anforderungen, macOS-spezifischen Werkzeugen und Signierungszugriffen zusätzliche Einschränkungen bringen. Für zeitlich begrenzte Lasten kann JexMac Mac-Rental deshalb die bessere Ergänzung sein: nicht als Ersatz für einen dauerhaft hohen Grundbedarf, sondern als realer Mac-Pool für einen kontrollierten CI-Probelauf oder eine vorhersehbare Veröffentlichungsspitze.

Beginnen Sie mit der Übersicht der Mac-Mietmodelle und markieren Sie in der Entscheidungsliste dieses Artikels, welche Aufgaben feste Verfügbarkeit benötigen und welche nur zeitweise Kapazität verlangen. Vor dem produktiven Einsatz sollten Sie anschließend einen echten, nicht privilegierten Workflow durch Bereitstellung, Registrierung, Ausführung, Abmeldung und Host-Bereinigung führen. Für die Einordnung eines dauerhaften Mac Servers kann außerdem die Analyse zu Mac mini als Serverlösung als Vergleichspunkt dienen.

FAQ