GitHub Actions macOS Runner: Kostenentscheidung 2026

Der wichtigste Fehler ist ein Vergleich von „Preis pro Minute“ mit „Preis pro Monat“. Beide Werte beschreiben unterschiedliche Kostenmodelle.

GitHub rechnet Hosted Runner nach der Ausführungszeit eines Jobs ab. Angefangene Minuten werden auf die nächste ganze Minute aufgerundet. Für einen normalen macOS Hosted Runner nennt die offizielle Preistabelle aktuell 0,062 US-Dollar pro Minute. Ein größerer Intel-macOS-Runner liegt bei 0,077 US-Dollar pro Minute, ein größerer arm64-macOS-Runner bei 0,102 US-Dollar pro Minute. Eingeschlossene Minuten können für größere Runner nicht verwendet werden. Die Werte sollten Sie vor jeder Budgetentscheidung erneut in der offiziellen Preisreferenz für Actions Runner prüfen.

Für einen Self-hosted Runner entsteht dagegen typischerweise eine zeitbasierte Fixkostenstruktur. Sie zahlen für die reservierte Maschine oder Mietperiode, auch wenn der Runner gerade keinen Job ausführt. Dazu kommen interne Arbeitskosten und ein Risikoaufschlag für Unterbrechungen.

Verwenden Sie für den Vergleich diesen Rahmen:

Hosted-Gesamtkosten =
abgerechnete Jobminuten
× gültiger macOS-Minutenpreis
+ Zusatzkosten für Speicher oder größere Runner
+ Kosten verspäteter Builds

Self-hosted-Gesamtkosten =
Miet- oder Hardwarekosten
+ Wartungsstunden
+ Monitoring und Wiederherstellung
+ Sicherheits- und Zertifikatsaufwand
+ Kosten ungenutzter Kapazität
+ Kosten von Ausfällen oder blockierten Releases

Die Eingabedaten dürfen nicht aus einer idealisierten Auslastung stammen. Exportieren Sie die Workflow-Läufe des letzten vollständigen Abrechnungszeitraums. Erfassen Sie mindestens:

• tatsächliche Ausführungszeit je macOS-Job,
• abgerechnete Minuten nach Rundung,
• Anzahl und Dauer paralleler Jobs,
• Zeit in der Warteschlange,
• Cache-Treffer und Cache-Fehler,
• fehlgeschlagene Wiederholungen,
• manuelle Eingriffe,
• geplante, aber nicht gestartete Builds.

Die offizielle GitHub-Dokumentation beschreibt Hosted Runner als bereitgestellte virtuelle Maschinen und weist darauf hin, dass private Repositorys die verfügbaren Minuten nutzen und danach nach den Runner-Tarifen abgerechnet werden. Die Referenz zu GitHub-hosted Runnern ist deshalb die bessere Grundlage als ein allgemeiner Rechner aus einem Blog.

Ein niedriger Minutenpreis löst kein Kapazitätsproblem. Ein fixer Remote Mac löst umgekehrt kein Auslastungsproblem.

Unterscheiden Sie mindestens drei reale Lastprofile:

1. Gelegentliche Veröffentlichung: wenige Release-Builds, unregelmäßige Pull Requests und lange Leerlaufzeiten.
2. Tägliche kontinuierliche Builds: regelmäßige Commits, wiederkehrende Tests und ein relativ vorhersehbarer Bedarf.
3. Parallele Multi-Branch-Last: mehrere Teams, mehrere Repositories oder Release-Fenster mit gleichzeitigem Bedarf.

Beim ersten Profil ist ein Hosted Runner meist wirtschaftlich und organisatorisch überlegen. Sie bezahlen nur die ausgeführten Jobs und müssen keine Maschine online halten. Ein Self-hosted Remote Mac würde während großer Teile der Mietperiode ungenutzt bleiben.

Beim zweiten Profil kann ein selbst verwalteter Knoten interessant werden. Das gilt besonders, wenn Xcode, CocoaPods, Swift Package Manager, DerivedData und private Pakete wiederholt benötigt werden. Die Maschine bleibt vorbereitet, statt bei jedem Job einen ähnlichen Zustand erneut aufzubauen.

Beim dritten Profil reicht ein einzelner Self-hosted Runner möglicherweise nicht aus. Dann entstehen Warteschlangen oder Sie benötigen zusätzliche Knoten. Ein Hosted Runner kann Jobs elastischer verteilen. Größere GitHub Runner werden als skalierbare Pools angeboten, nicht als einzelne dauerhaft reservierte Maschine. Details zu diesen Pools und ihren Einschränkungen finden Sie in der Dokumentation zu größeren Runnern.

Ermitteln Sie den Kostenumschlag nicht als allgemeine Minutenangabe. Berechnen Sie ihn mit Ihren Daten:

monatliche Hosted-Kosten
÷ monatlich belegte macOS-Minuten
=
effektiver Preis je belegter Minute

Vergleichen Sie diesen Wert mit:

monatliche Self-hosted-Kosten
÷ tatsächlich ausgeführte Minuten
=
Preis je tatsächlich genutzter Minute

Die zweite Zahl verschlechtert sich bei geringer Auslastung sofort. Die erste kann durch Wiederholungen, Wartezeiten oder langsamere Initialisierung steigen. Deshalb müssen Sie zusätzlich die Kosten je erfolgreichem Release betrachten.

Ein Hosted Runner startet mit einer temporären Umgebung. Das verbessert die Trennung zwischen Jobs, erhöht aber den Bedarf an Installations- und Wiederherstellungsschritten. Ein Self-hosted Remote Mac kann Xcode, Ruby, Bundler, Swift Package Manager und weitere Werkzeuge dauerhaft bereithalten.

Das ist ein Vorteil, aber kein kostenloser Vorteil. Ein dauerhaft veränderter Rechner kann alte Abhängigkeiten, beschädigte DerivedData, veraltete Zertifikate oder unklare Umgebungsvariablen enthalten. Der Build läuft dann möglicherweise schneller, ist aber schlechter reproduzierbar.

Messen Sie Cache-Effekte nicht mit unterschiedlichen Projekten oder verschiedenen Xcode-Versionen. Verwenden Sie für den Vergleich:

• denselben Commit,
• dieselbe macOS-Version,
• dieselbe Xcode-Version,
• dieselbe Dependency-Auflösung,
• dieselben Build-Flags,
• dieselbe Cache-Strategie,
• mindestens einen kalten und einen warmen Lauf.

Trennen Sie danach drei Zeiten:

Gesamtzeit =
Runner-Wartezeit
+ Umgebungsvorbereitung
+ eigentliche Xcode-Buildzeit
+ Archivierung und Upload

Nur die dritte Zeit zeigt die reine Compilerleistung. Wenn ein Self-hosted Runner schneller ist, weil er bereits ein großes Cache-Verzeichnis besitzt, muss dieser Vorteil als Cache-Effekt dokumentiert werden. Sonst verwechseln Sie Chip-, Speicher- und Cache-Unterschiede.

Bei einem Remote Mac sollte außerdem regelmäßig ein sauberer Referenzlauf stattfinden. Entfernen Sie dafür kontrolliert abgeleitete Builddaten und installieren Sie Abhängigkeiten neu. Wenn der Build nur im warmen Zustand zuverlässig funktioniert, haben Sie keine belastbare CI-Umgebung, sondern einen zustandsbehafteten Entwicklungsrechner.

Die technische Kontrolle wird wichtiger, sobald der Workflow mehr als Kompilieren und Unit-Tests erledigt.

Apple weist für Xcode 26 auf eine Kompatibilität mit macOS Sequoia 15.6 oder neuer hin. Die aktuelle Apple-Übersicht zu Xcode-Systemanforderungen zeigt zusätzlich, dass Xcode-Versionen an bestimmte macOS-Versionen und SDK-Stände gebunden sind. Ein festes Xcode- und macOS-Paar ist daher kein Komfortmerkmal, sondern kann eine Releasevoraussetzung sein.

Bewerten Sie diese Punkte einzeln:

• Muss eine bestimmte Xcode-Version über mehrere Wochen unverändert verfügbar sein?
• Liegen private Swift Packages oder Binärabhängigkeiten hinter einer internen Zugriffskontrolle?
• Benötigt der Workflow einen dauerhaft vorbereiteten Schlüsselbund?
• Muss ein Zertifikat nur in einem eng kontrollierten Knoten vorhanden sein?
• Gibt es Netzwerkregeln, die dynamische Runner-Adressen ausschließen?
• Wird ein bestimmter Hardware-Identifikator für Entwicklung oder Tests benötigt?

Hosted Runner können je nach Typ und Konfiguration auf zusätzliche Netzwerke zugreifen. Eine pauschale Aussage „Hosted Runner kommen nie ins interne Netz“ wäre falsch. Bei macOS größeren Runnern bestehen jedoch konkrete Einschränkungen. GitHub dokumentiert unter anderem, dass Azure Private Networking und statische IP-Adressen für macOS größere Runner nicht allgemein verfügbar sind. Für arm64-macOS-Runner gibt es außerdem keine statische UUID/UDID. Diese Bedingungen stehen in der Referenz zu größeren macOS Runnern.

Ein selbst verwalteter Remote Mac kann hier mehr Kontrolle bieten. Er kann in eine definierte Netzwerkzone eingeordnet werden, und Sie können den Zugriff auf private Paketquellen oder interne APIs nach Ihren Regeln begrenzen. Dafür liegt der Schlüsselbund nicht mehr nur in einer kurzlebigen Jobumgebung. Er bleibt auf einem Knoten, der dauerhaft geschützt, überwacht und regelmäßig bereinigt werden muss.

Für Signierung sollten Sie deshalb nicht nur die Geschwindigkeit messen. Prüfen Sie auch:

• Zugriff nur für freigegebene Workflow-Dateien,
• geschützte Environments mit manueller Freigabe,
• minimale Rechte für Zertifikate und Tokens,
• getrennte Runner-Gruppen für Pull Requests und Releases,
• dokumentierte Löschung nach einem fehlgeschlagenen Signiervorgang.

Ein Self-hosted Runner ist kein automatisch isolierter Rechner. GitHub warnt ausdrücklich davor, Self-hosted Runner für öffentliche Repositorys einzusetzen. Fremder Code aus Pull Requests kann die Umgebung verändern und unter Umständen Zugriff auf Secrets, Tokens oder gespeicherte Daten erhalten. Die offizielle Anleitung zur sicheren Nutzung von GitHub Actions beschreibt dieses Risiko ausführlich.

Für öffentliche Projekte sollten Sie deshalb den allgemeinen Build, Linting und Pull-Request-Tests auf Hosted Runnern belassen. Wenn ein privater Release-Runner nötig ist, begrenzen Sie seine Sichtbarkeit über Runner-Gruppen, Repository-Zuordnung und Workflow-Regeln.

Ein sauberer Aufbau sieht so aus:

• Hosted: Pull-Request-Prüfung, Linting, Unit-Tests ohne Signatur.
• Self-hosted: Archivierung, Signierung, interne APIs und festgelegte Xcode-Version.
• Artefaktübergabe: Der Testjob erzeugt ein klar benanntes Artefakt.
• Releasejob: Der Self-hosted Runner lädt nur dieses Artefakt und signiert es.
• Zugriffsgrenze: Kein öffentlicher Pull Request darf den Signaturknoten erreichen.

Damit wird der Self-hosted Runner nicht zum allgemeinen Ersatz für alle Jobs. Er übernimmt nur die Aufgaben, deren Kontrollbedarf die zusätzliche Betriebsverantwortung rechtfertigt.

Ein Runner mit dem Status „Online“ ist noch kein produktionsbereiter Runner. GitHub verlangt für Self-hosted Runner eine funktionierende Kommunikation mit GitHub. Die Runner-Software kann Aktualisierungen automatisch durchführen, trotzdem bleiben Betriebssystem, Xcode, Zertifikate, Speicherplatz und Wiederherstellung Ihre Verantwortung. Die Referenz zu Self-hosted Runnern beschreibt Kommunikationsanforderungen und Softwareaktualisierungen.

Planen Sie mindestens diese Wartungsfälle ein:

1. Neustart: Der Mac startet neu und meldet sich automatisch wieder als Runner an.
2. Netzunterbrechung: Ein kurzzeitiger Ausfall beendet keinen wichtigen Releaseprozess oder wird sauber erneut gestartet.
3. Jobabbruch: Ein abgebrochener Build hinterlässt keine gefährlichen Schlüsselbund- oder Prozessreste.
4. Knotenwiederherstellung: Eine beschädigte Umgebung kann aus einer dokumentierten Basis wieder aufgebaut werden.
5. Speicherbereinigung: Xcode-Caches, Archive und Paketdaten werden nach Regeln entfernt.
6. Versionswechsel: Ein Xcode-Update wird zuerst mit einem Referenzprojekt geprüft.

Bewerten Sie jede Störung nach Ausfallzeit und manueller Arbeitszeit. Ein günstiger Mietknoten verliert seinen Preisvorteil, wenn ein Plattformverantwortlicher regelmäßig außerhalb geplanter Arbeitszeiten eingreifen muss.

Kontrollliste für den Abnahmetest

• [ ] Ein Build läuft nach einem Neustart ohne manuelle Anmeldung.
• [ ] Ein unterbrochener Job wird erkannt und nachvollziehbar erneut gestartet.
• [ ] Der Runner bleibt nach einer Netzwerkunterbrechung sichtbar und erreichbar.
• [ ] Das letzte bekannte Xcode- und macOS-Paar ist dokumentiert.
• [ ] Schlüsselbund, Zertifikate und Tokens sind nicht für Testjobs verfügbar.
• [ ] Cache-Löschung und Speichergrenzen sind automatisiert.
• [ ] Ein Knoten kann ohne manuelle Einzelreparaturen neu aufgebaut werden.
• [ ] Die Workflow-Logs zeigen eindeutig, welcher Runner verwendet wurde.

Die folgende Tabelle ist kein Preisangebot. Sie zeigt, welche Variablen Sie aus Ihrem letzten Abrechnungszeitraum einsetzen müssen.

Verwenden Sie keine allgemeine Prozentannahme für die Auslastung. Setzen Sie stattdessen die tatsächliche belegte Zeit ein. Wenn ein Knoten nur während eines täglichen Releasefensters gebraucht wird, ist eine feste Monatsmiete schwerer zu rechtfertigen als bei kontinuierlichen Builds und reproduzierbarem Cache.

Nutzen Sie diese Entscheidungslogik nach dem Datenexport:

• Wenn Ihre macOS-Jobs selten laufen, dann wählen Sie zunächst Hosted Runner. Sonst prüfen Sie die belegte Zeit und die Warteschlange.
• Wenn öffentliche Pull Requests den Runner erreichen könnten, dann lassen Sie diese Jobs auf Hosted Runnern. Sonst können Sie einen geschützten Self-hosted Bereich prüfen.
• Wenn ein festes Xcode-macOS-Paar für Archivierung oder Signierung erforderlich ist, dann testen Sie einen Self-hosted Remote Mac. Sonst bleibt Hosted für allgemeine Builds die einfachere Option.
• Wenn der Cache einen nachweisbaren Anteil der Gesamtzeit spart und der Zustand kontrolliert zurückgesetzt werden kann, dann zählt dieser Vorteil in die Rechnung. Sonst behandeln Sie den Cache als Reproduzierbarkeitsrisiko.
• Wenn interne APIs, private Paketquellen oder feste Schlüsselbundregeln notwendig sind, dann bewerten Sie die zusätzliche Kontrolle eines eigenen Knotens. Sonst behaupten Sie nicht, Hosted sei automatisch ungeeignet.
• Wenn mehrere Jobs regelmäßig gleichzeitig warten, dann vergleichen Sie Pool-Skalierung mit mehreren Self-hosted Knoten. Sonst reicht möglicherweise ein einzelner Knoten.
• Wenn die Wartungszeit nicht gemessen wird, dann treffen Sie noch keine Kaufentscheidung. Erfassen Sie zuerst Arbeitszeit und Wiederherstellung.

Die sinnvollste Migration beginnt nicht mit allen Workflows. Wählen Sie eine Pipeline mit realem Nutzen und klarer Abgrenzung:

1. Exportieren Sie die Workflow-Daten eines vollständigen Abrechnungszeitraums.
2. Wählen Sie eine Signier- oder Archivierungspipeline mit stabiler Xcode-Anforderung.
3. Lassen Sie dieselbe Testmenge auf Hosted und Self-hosted laufen.
4. Verwenden Sie identische Commits, Buildflags und Artefaktgrößen.
5. Protokollieren Sie Kosten, Warteschlange, Ausführungszeit und Fehlerrate.
6. Messen Sie Cache-Treffer getrennt von Compilerzeit.
7. Führen Sie Neustart-, Netzwerk- und Wiederherstellungstests durch.
8. Rechnen Sie die manuelle Arbeitszeit mit einem internen Stundensatz ein.
9. Verschieben Sie nur Jobs, deren Kontrollgewinn die Zusatzkosten rechtfertigt.
10. Überprüfen Sie die Entscheidung nach dem nächsten vollständigen Abrechnungszeitraum.

Für eine erste Umsetzung können Sie Ihre bestehenden runs-on-Ziele aufteilen. Hosted Jobs verwenden beispielsweise ein GitHub-macOS-Label. Self-hosted Jobs sollten mit mehreren Labels wie self-hosted, macos und einer eigenen Xcode-Kennung angesprochen werden. GitHub führt Jobs nur auf Runnern aus, die alle angegebenen Labels erfüllen; die Regeln erklärt die Dokumentation zur Runner-Auswahl.

Wenn Sie die Testphase nicht auf einer eigenen Hardwarebasis durchführen möchten, können Sie die Remote-Mac-Optionen von CALMVPS als zeitlich begrenzte Umgebung prüfen. Entscheidend bleibt, dass Sie dieselbe Pipeline, dieselben Testdaten und dieselben Wiederherstellungsszenarien verwenden.

Wann ist ein GitHub Actions macOS Runner als Self-hosted-Variante günstiger?

Ein Self-hosted Runner kann wirtschaftlicher werden, wenn Builds regelmäßig laufen, die Maschine über längere Zeit ausgelastet ist und eine feste Xcode- sowie Cache-Umgebung Wiederholungen spart. Rechnen Sie jedoch nicht nur die Mietperiode ein. Wartungsstunden, Ausfälle, Neustarts, Speicherbereinigung und Sicherheitskontrollen gehören in dieselbe Rechnung.

Welche Buildmenge rechtfertigt einen eigenen macOS Runner?

Eine allgemeingültige Minutenmarke gibt es nicht. Entscheidend sind Ihre tatsächlich belegten Stunden, die Wartezeit in der Warteschlange und der Anteil wiederverwendbarer Umgebung. Exportieren Sie die Daten eines vollständigen Abrechnungszeitraums und vergleichen Sie sie mit der geplanten Mietdauer, dem Wartungsaufwand und den Kosten eines fehlgeschlagenen oder verspäteten Releases.

Welche versteckten Kosten entstehen bei einem Remote Mac als Runner?

Neben dem Mietpreis zählen Xcode- und macOS-Updates, Runner-Aktualisierungen, Zertifikatsverwaltung, Schlüsselbundschutz, Monitoring, Neustarttests, Speicherbereinigung und die Wiederherstellung nach einem Fehler. Zusätzlich können Wartezeiten entstehen, wenn nur ein Runner vorhanden ist. Ohne dokumentierte Betriebszeit und manuelle Arbeitszeit bleibt jeder Vergleich unvollständig.

Können Hosted und Self-hosted Runner in einem Workflow kombiniert werden?

Ja. Sie können Jobs desselben Workflows über unterschiedliche runs-on-Ziele verteilen. Typisch ist ein Hosted Runner für Linting, Unit-Tests und Pull-Request-Prüfungen sowie ein Self-hosted Remote Mac für Signierung, Archivierung oder interne Abhängigkeiten. Übergaben sollten über Artefakte erfolgen, damit der Workflow nicht vom lokalen Zustand eines Jobs abhängt.

Wenn Sie bisher nur GitHub-Minuten betrachten, bleiben die wichtigsten Nachteile Ihrer aktuellen Lösung unsichtbar: Wartezeiten bei parallelen Builds, wiederholte Xcode-Initialisierung und fehlende Kontrolle über Signierung oder interne Netzwerkpfade. Ein dauerhaft eigener Mac bringt dagegen neue Aufgaben wie Updates, Schlüsselbundschutz und Wiederherstellung. Für eine zeitlich begrenzte Validierung kann ein gemieteter Remote Mac von CALMVPS deshalb der sauberere Zwischenschritt sein: Sie testen eine echte Xcode-CI-Pipeline über eine Mietperiode, vergleichen reale Kosten und Wartungszeit und entscheiden erst danach über eine größere Migration. Einen passenden CALMVPS-Tarif für Remote-Mac-Umgebungen können Sie dabei als Testgrundlage prüfen.