Von GitHub Actions zu selbstgehosteten Mac-Knoten: Wie viel Effizienz gewinnt man? (2026 Praxisvergleich)

Quick Answer: Wie viel Effizienz?

Kurz gesagt: Der Hauptgewinn ist Warten, nicht „schnellerer Compiler“. Eigene Knoten nehmen den knappen macOS-Pool aus der Shared Queue — plus persistierte DerivedData entstehen die Groessenordnungen oben.

Erst messen, dann über „wie viel“ sprechen

Viele Teams sagen nach der Migration „kaum schneller“, weil sie nur Job duration in GitHub Actions sehen und queue time sowie Slack-Wartezeit ignorieren. Zwei Wochen vor und nach der Migration — mindestens vier Kennzahlen:

• Queue-Wartezeit: Sekunden von job queued bis job started, P50 / P95
• PR-Feedback-Loop: Letzter Push bis alle required checks gruen
• Release-Fenster-Durchsatz: Erfolgreiche TestFlight-Uploads in festem 4-Stunden-Fenster
• Passive Warte-Personenstunden: Umfrage oder PR-Zeitstempel

Export: GitHub API run_started_at minus created_at; oder Workflow-Step, der Queue-Sekunden ins Artifact schreibt. Ohne Baseline ist ROI gegenueber dem Management schwer belegbar.

Drei Team-Vergleiche: vorher vs. nachher

Alle drei Datensaetze aus echten Migrationen (anonymisiert), gleiches Repo, gleiche Xcode-Hauptversion, je zwei Wochen Werktage.

Fall A: 12-koepfiges iOS-Team, eine App + Extensions

Vorher alles auf macos-14; nachher 2× M4 16 GB Cloud Mac als Self-hosted Runner, DerivedData auf lokalem NVMe. Ca. 18 PRs/Tag.

Tech Lead wortwoertlich: „Frueher Push um 17 Uhr, Merge-Freigabe um halb sieben — jetzt kurz Wasser holen, PR ist gruen.“

Fall B: 28 Personen KMP + Android-Hauptrepo, Mac nur fuer iOS-Shell

Vorher macOS- und Android-Jobs im gleichen Release-Fenster; nachher 1× dauerhafter M4 Pro plus 2× Burst-Cloud-Macs in Release-Wochen (siehe Release-Burst-Playbook).

Fall C: 8 Personen Indie, 2 Releases/Monat

Gegenbeispiel: kaum Verbesserung — wenige PRs, keine Queue, dafuer Keychain-Pflege auf eigener Maschine. Archive nur 10,2 → 9,4 Min. (−8 %), Queue war ohnehin ~0. „Wie viel“ haengt stark von der Last ab.

Woher der Gewinn kommt: Queue, Cache, Parallelitaet

Gesamtwartezeit zerlegen — das hilft auch nicht-technischen Stakeholdern:

PR-Gesamtzeit ≈ Queue + Umgebung + Build/Test + Upload

1. Queue (groesster Block): GitHubs macOS-Pool ist geteilt; in Release- oder Xcode-Upgrade-Wochen P95 30+ Min. ist normal. Eigener Knoten = dedizierter Executor, Queue faellt fast weg.

2. Cold Start und Cache: Hosted Jobs werden zerstoert — DerivedData, Pods, SwiftPM jedes Mal neu. Persistente Volumes auf eigenen Maschinen: zweiter Build oft ~20 % schneller; Details in Self-hosted Runner Cache & Disk FAQ.

3. Parallelitaet: 2–3 Macs fuer Matrix-Jobs — Release-Nacht nicht mehr „eine Kette“. Pro Host Verzeichnis-Isolation, sonst frisst Flakiness den Gewinn.

Zweiwöchiger Migrationspfad: erst vergleichen, dann Traffic

Freitagabend alles umstellen — ungerne. Reproduzierbarer Ablauf:

• Tag 1–2: Zwei Wochen Queue/duration aus Actions exportieren; 1× Cloud Mac (~5 Min.), Runner, runs-on: [self-hosted, macos, canary] nur manuell
• Tag 3–5: ~/ci/DerivedData und SwiftPM persistieren; gleicher main-Commit A/B je 5×, P50 notieren
• Tag 6–8: Release/nightly 50 % auf self-hosted Label; hosted als Fallback
• Tag 9–10: PR required checks voll auf self-hosted; Disk 80 %-Schwelle und Artifact-Cleanup-Cron
• Tag 11–14: Vergleichstabelle, ROI an Management; entscheiden: 1× dauerhaft oder Burst mieten

Orchestrierung bleibt GitHub Actions — YAML, Permissions, Environment Protection unveraendert, nur runs-on. Gleiche Idee wie Enterprise Mac CI Ressourcenpool: Orchestrierung und Ausfuehrung trennen.

Minimale Workflow-Aenderung

jobs:
  ios-build:
    # Vorher: runs-on: macos-14
  ios-build:
    runs-on: [self-hosted, macos, ios-pool]
    steps:
      - uses: actions/checkout@v4
      - name: Log queue metrics
        run: echo "QUEUE_SEC=${QUEUE_SEC:-0}" >> $GITHUB_STEP_SUMMARY

Noch unsicher wegen Hardware? M4 Cloud Mac tageweise mieten fuer zwei Wochen Vergleich — oft guenstiger als eine Stunde Wartezeit fuers ganze Team.

ROI-Grobrechnung: Deckt Effizienz die Maschine?

Mit Fall A (Stundensatz blended $55, nur Illustration):

• 12 Personen × 3,7 Std. weniger Warten/Woche ≈ 44 Personenstunden/Monat ≈ $2.420/Monat aequivalenter Output
• 2× M4 16 GB Cloud Mac ≈ $206/Monat ($103/Maschine × 2, laut Preisseite)
• Plattform-Ops nebenbei ≈ 4–8 Personenstunden/Monat (Disk, Zertifikate, Runner-Upgrade)

Netto oft positiv — kleine Teams mit wenig Builds (Fall C) rechnet es sich evtl. nicht. Eigene Queue P95 einsetzen:

Monatsgewinn ≈ Entwickler × weniger Warte-Std./Woche × 4 × Stundensatz − Maschinenmiete − Ops-Std. × Stundensatz

In Release-Wochen dritte Maschine als Burst, in Flachphase zurueckgeben. Langfrist TCO Kauf vs. Miete: Mac mini kaufen oder Cloud Mac mieten.

Wann lieber nicht migrieren

In diesen Faellen rate ich erst abwarten oder nur eine Woche validieren:

• <30 macOS Jobs/Monat und Queue P95 dauerhaft <5 Min. — niedrige Decke (Fall C)
• Niemand pflegt Runner on-call — volle Disk nervt mehr als Queue
• Compliance: Maschine muss in eigener VPC — Netzwerk und Secrets zuerst
• Erwartung „ohne GitHub Actions“ — Orchestrierung, Audit, Permissions bleiben wertvoll

Migration ist Mittel; Ziel ist . Schafft der Zweiwochen-Vergleich keine >30 % PR-Feedback-Verbesserung, zuerst Workflow optimieren (Jobs splitten, Archive seltener) — nicht drei Macs kaufen.