Wie konfiguriert man GitHub Actions macOS Runner Groups? Unternehmensleitfaden 2026

Ein Workflow landet auf einem unerwünschten macOS Runner oder ein Repository erhält mehr Zugriff als vorgesehen.

Schnellste Lösung: Teilen Sie Runner Groups zuerst nach Vertrauensgrenzen auf, richten Sie danach den Repository-Zugriff und das Workflow-Routing ein. Deaktivieren Sie Standard-Runner-Labels erst, wenn repräsentative Abläufe erfolgreich geprüft wurden. Benötigen Sie Netzwerkkonfiguration, behandeln Sie die Runner Group nicht als Netzwerkschutz: Prüfen Sie stattdessen, ob der vorhandene Runner-Typ Ihre Anforderungen überhaupt abdeckt.

Dieser Leitfaden richtet sich an GitHub-Organisations- und Enterprise-Administratoren, die Runner Groups und Repository-Zugriffe verwalten.
CI-Plattformingenieure finden eine Ablaufreihenfolge für macOS-Workflow-Routing und Abnahmetests.
Technische und Sicherheitsverantwortliche können damit prüfen, ob die Runner-Zuweisung zu den Vertrauensgrenzen des Teams passt.

Zuletzt aktualisiert am 04.11.2026. Die Angaben zu Plänen, Zugriff, Routing und Netzwerkgrenzen wurden anhand des GitHub-Changelogs zu Runner Groups und der verlinkten GitHub-Dokumentation geprüft. Die verfügbaren Optionen und die Verwaltungsoberfläche können sich ändern; maßgeblich sind die Einstellungen Ihres Kontos und die aktuellen offiziellen Angaben.

Vor der Konfiguration: Runner-Typ und Kontoumfang prüfen

Beginnen Sie nicht mit dem Anlegen einer Gruppe, sondern mit einer Bestandsaufnahme. GitHub-hosted macOS runners und selbst gehostete Runner sind unterschiedliche Ausführungsmodelle. Eine Anleitung für selbst gehostete Runner lässt sich nicht automatisch auf von GitHub gehostete macOS Runner übertragen. Prüfen Sie deshalb zuerst, welcher Runner-Typ Ihre Workflows tatsächlich ausführt und welche Verwaltungsoptionen in Ihrer Organisation angezeigt werden.

GitHub zufolge ist die Verwaltung von macOS Runnern über Runner Groups für Team- und Enterprise-Pläne verfügbar. Behandeln Sie diese Angabe als dokumentierten Funktionsumfang zum Prüfdatum und kontrollieren Sie zusätzlich die Einstellungen Ihres eigenen Kontos: Organisationsstruktur, Plan, Berechtigungen der administrierenden Person und die in der Oberfläche angebotenen Optionen können für die Umsetzung entscheidend sein. Die offizielle Ankündigung zur Gruppenverwaltung von GitHub-hosted Runnern beschreibt den bestätigten Umfang.

Klären Sie außerdem, welches Problem Sie lösen möchten. Runner Groups helfen dabei, den Zugriff und die Nutzung der zugeordneten Runner zu steuern. Sie sind nicht gleichbedeutend mit einer eigenen Netzwerkzone. Wenn Ihr Ziel eine ausgehende Verbindung zu internen Systemen, eine feste Netzwerkkonfiguration oder eine bestimmte Netzwerkisolation ist, notieren Sie diese Anforderung getrennt und vergleichen Sie sie mit den dokumentierten Fähigkeiten des verwendeten Runner-Typs.

Halten Sie die Ergebnisse als Ausgangszustand fest: betroffene Repositories, verwendete Runner-Labels, verantwortliche Teams und Workflows mit Zugangsdaten. Diese Bestandsaufnahme macht später sichtbar, ob eine Änderung tatsächlich alle relevanten Ausführungspfade erfasst.

Zugriffsgrenzen: Welche Repositories dürfen eine Runner Group verwenden?

Die Frage, wie sich eine Runner Group auf bestimmte Repositories beschränken lässt, beantworten Sie in den Gruppeneinstellungen und durch einen anschließenden Negativtest. GitHub dokumentiert Einstellungen für den Zugriff auf Runner Groups; die konkreten Auswahlmöglichkeiten hängen von Konto und Verwaltungsbereich ab. Richten Sie den Zugriff nicht nach Bequemlichkeit für das ganze Unternehmen ein, wenn die Gruppe nur von einem Teil der Repositories benötigt wird. Prüfen Sie die offizielle Dokumentation zur Zugriffskontrolle für Runner Groups.

Leiten Sie die Gruppengrenzen aus drei Faktoren ab: Repository-Zugehörigkeit, Zuständigkeit des Teams und Vertrauensniveau des Workflows. Ein gemeinsames Team kann etwa eine Gruppe für gewöhnliche Build- und Testabläufe nutzen, während Veröffentlichungsabläufe mit Zugangsdaten eine gesonderte Prüfung und gegebenenfalls einen engeren Berechtigungsumfang benötigen. Machen Sie dabei keine pauschale Annahme, dass Workflows aus öffentlichen Repositories, externe Beiträge und vertrauliche Veröffentlichungsjobs gefahrlos dieselbe Zugriffsfläche teilen können.

Ein praktikabler Eintrag für Ihr Betriebsprotokoll enthält den Gruppennamen, den Zweck, die verantwortliche Person oder das Team, die erlaubten Repositories und die geprüften Workflow-Arten. Dokumentieren Sie auch, wer Änderungen an dieser Zuordnung freigibt. So können Sie eine spätere Berechtigungsänderung mit der ursprünglichen Absicht abgleichen, statt nur festzustellen, dass ein Job noch startet.

Die Zugriffskontrolle sollte aus erlaubten und ausdrücklich nicht erlaubten Fällen bestehen. Wählen Sie mindestens ein repräsentatives Repository, das die Gruppe nutzen darf, und eines, das sie nicht nutzen darf. Ein erfolgreicher Lauf im erlaubten Repository belegt nicht, dass die Beschränkung wirksam ist. Erst das erwartete Ablehnen oder Nicht-Zuweisen eines nicht autorisierten Workflows prüft die andere Seite der Regel.

Gruppenanlage: Berechtigungen kontrolliert umsetzen

Legen Sie die Gruppe über die Verwaltungsoberfläche Ihrer Organisation an oder folgen Sie der zum Zeitpunkt der Änderung aktuellen offiziellen Anleitung. Übertragen Sie keine Beschriftungen aus einer älteren Anleitung ungeprüft: Entscheidend ist, ob die Optionen in Ihrem Konto tatsächlich verfügbar sind und ob Sie gerade die richtige Runner-Kategorie konfigurieren. Die Dokumentation zu Verwaltung und Einstellungen größerer Runner bietet dafür den offiziellen Bezugspunkt.

Arbeiten Sie die Änderung in einer kontrollierten Reihenfolge ab:

1. Bestand sichern: Notieren Sie vorhandene Runner Groups, deren Zuordnungen und die macOS-Labels, auf die Workflows derzeit verweisen. Halten Sie bestehende Standardpfade fest, damit Sie sie nach der Änderung wiedererkennen.
2. Zweck und Verantwortlichkeit festlegen: Beschreiben Sie, welche Workloads in die neue Gruppe gehören, welche Repositories sie benötigen und wer Zugriffsänderungen genehmigt.
3. Gruppe erstellen: Verwenden Sie einen Namen, der Zweck oder Zuständigkeit erkennen lässt. Prüfen Sie dabei, ob die Gruppe zum richtigen Runner-Typ gehört und im korrekten Organisations- oder Enterprise-Kontext angelegt wird.
4. Zugriff zuweisen: Konfigurieren Sie nur die Repositories beziehungsweise den zulässigen Umfang, die Ihre Richtlinie vorsieht. Die genaue Granularität richtet sich nach den Optionen, die GitHub für Ihr Konto bereitstellt.
5. Bestehende Zuordnungen prüfen: Kontrollieren Sie die Standardgruppe sowie bereits vorhandene Runner und Zugriffsregeln. Eine neue Gruppe begrenzt keinen Workflow, der über einen anderen noch aktiven Pfad weiterhin einen Runner anfordern kann.
6. Erlaubnis und Ablehnung testen: Starten Sie einen risikoarmen Job in einem freigegebenen Repository und prüfen Sie anschließend einen nicht freigegebenen Fall. Dokumentieren Sie das Ergebnis als organisationsinterne Abnahme, nicht als allgemeine Aussage über die Funktion.
7. Änderung freigeben und protokollieren: Vermerken Sie die betroffenen Workflows, die Testläufe, die verantwortliche Person und das Rückfallverfahren, bevor Sie die Nutzung breiter ausrollen.

Für öffentliche Repositories und externe Beiträge sollten Sie die Vertrauensannahmen zusätzlich prüfen. Eine Runner-Zuweisung beantwortet nicht automatisch, ob ein Workflow vertrauenswürdigen Code ausführt oder welche Geheimnisse ihm zur Verfügung stehen. Prüfen Sie diese Fragen anhand Ihrer Workflow-Ereignisse, Berechtigungen und Freigaberegeln. Bewerten Sie auch die Datenschutzanforderungen Ihrer Umgebung; die Datenschutzhinweise von VPSMerge sind dafür ein möglicher Bezugspunkt, ersetzen jedoch keine interne Sicherheitsprüfung.

Workflow-Routing: Wie lassen sich macOS-Abläufe auf eine Gruppe lenken?

Für die Zuweisung im Workflow kombinieren Sie die Runner Group mit einem passenden Label, sofern die offizielle Syntax und Ihr Runner-Angebot diese Angabe verlangen. Das Gruppenrouting bestimmt, aus welcher Gruppe ein Job einen Runner anfordern darf; ein Label allein ist nicht dasselbe wie eine Berechtigung für ein Repository. Verwenden Sie die offizielle GitHub-Referenz zur Workflow-Syntax und kontrollieren Sie die tatsächlich verwendeten Gruppennamen und Labels.

Ein schematisches Beispiel für einen Job sieht so aus:

jobs:
  macos-build:
    runs-on:
      group: macos-builders
      labels: macos-15
    steps:
      - uses: actions/checkout@v4
      - run: xcodebuild -version

Das Beispiel ist kein Versprechen, dass die angezeigte Gruppe oder das Label in Ihrer Organisation existiert. Ersetzen Sie beide durch die in Ihrem Konto verfügbaren Werte und prüfen Sie die dokumentierte Syntax vor der Übernahme. Insbesondere sollten Sie keinen Gruppennamen aus einem Beispiel kopieren, ohne ihn zuvor in den Runner-Einstellungen anzulegen.

Beginnen Sie mit einem risikoarmen Build, der keine Veröffentlichung auslöst und keine produktiven Zugangsdaten benötigt. Prüfen Sie im Laufprotokoll, ob der Job der vorgesehenen Gruppe zugeordnet wurde und ob die erwartete Runner-Umgebung verfügbar ist. Ein erfolgreicher Build allein reicht nicht: Kontrollieren Sie zugleich, dass ein nicht freigegebenes Repository die Gruppe nicht nutzen kann.

Diese Prüfung deckt den Unterschied zwischen Runner Groups und reiner Label-Auswahl auf. Labels beschreiben, welche Runner-Eigenschaften ein Job anfordert; die Gruppenzuordnung und die Zugriffsregeln bestimmen, ob der Workflow den Runner aus dieser Gruppe verwenden darf. Verlassen Sie sich daher nicht auf den Namen eines Labels als Ersatz für eine getestete Repository-Berechtigung.

Abnahme und Standard-Labels: Was ist vor einer Änderung zu prüfen?

Ändern oder deaktivieren Sie Standard-Runner-Labels nicht als ersten Schritt. Prüfen Sie zunächst alle Repositories und Workflows, die auf die bisherige Zuweisung angewiesen sein könnten. Die Einstellungen zum Einschränken oder Deaktivieren von GitHub Actions sind in der offiziellen Dokumentation zu Organisationsrichtlinien beschrieben. Prüfen Sie dort, ob die gewünschte Änderung Ihrem Vorhaben entspricht; eine Richtlinie für Actions insgesamt ist nicht automatisch dasselbe wie eine Einschränkung einzelner macOS-Runner-Pfade.

Nutzen Sie diese Entscheidungsbedingungen für den nächsten Schritt:

• Wenn die Kontoeinstellungen die benötigte Runner Group anbieten und die erlaubten sowie nicht erlaubten Repository-Fälle erfolgreich geprüft sind, dann können Sie die Gruppe kontrolliert für weitere passende Workflows freigeben.
• Wenn repräsentative Workflows noch Standard-Runner-Labels verwenden, dann migrieren und testen Sie diese zuerst; andernfalls riskieren Sie unerwartete Warteschlangen oder fehlgeschlagene Jobs nach einer Änderung.
• Wenn ein Job nur mit einem bestimmten Label erfolgreich läuft, dann prüfen Sie die Verfügbarkeit und Zuordnung dieses Labels, bevor Sie Standardpfade einschränken.
• Wenn die Zielanforderung Netzwerkzugriff oder Netzwerkisolation ist, dann betrachten Sie die Runner Group nicht als Lösung; prüfen Sie die Netzwerkmöglichkeiten des konkreten Runner-Typs und wählen Sie bei Bedarf eine andere Ausführungsumgebung.
• Wenn die Konfiguration noch nicht durch eine verantwortliche Person abgenommen wurde, dann belassen Sie den bisherigen Rückfallpfad und verschieben Sie die Einschränkung, bis Testergebnis und Wiederherstellungsschritt dokumentiert sind.

Bei Parallelitätsgrenzen gehen Sie ebenso vorsichtig vor. GitHub dokumentiert gruppenbezogene Steuerungsmöglichkeiten, aber daraus lässt sich keine für Ihr Team passende Kapazitätszahl ableiten. Ermitteln Sie zunächst aus Ihren eigenen Arbeitsabläufen, welche Jobs gleichzeitig laufen müssen, wann Wartezeiten auftreten und welche Folgen eine Begrenzung für Veröffentlichungen oder Testfenster hat. Übernehmen Sie keine Kapazitäts- oder Kostenannahme aus einem fremden Beispiel.

Eine belastbare Abnahme umfasst mindestens einen erfolgreichen Job im vorgesehenen Repository, einen überprüften Zugriffsausschluss und eine Kontrolle des Laufprotokolls. Ergänzen Sie Tests für Veröffentlichungsworkflows und Abläufe mit Zugangsdaten, wenn diese von der Änderung betroffen sind. Halten Sie außerdem fest, wie Sie im Fehlerfall zur vorherigen Zuordnung zurückkehren. Diese Ergebnisse sind Ihre Team-Abnahme, keine allgemeine Garantie für andere Konten oder Organisationsstrukturen.

Netzwerkgrenzen und Betriebsentscheidung

Die häufige Fehlannahme lautet, dass eine Runner Group Netzwerkzugriffe einschränkt oder eine isolierte Netzwerkumgebung bereitstellt. Das ist nicht der dokumentierte Zweck: Die offizielle Ankündigung weist darauf hin, dass macOS Runner derzeit keine Netzwerkkonfiguration unterstützen. Beziehen Sie diese Grenze ausdrücklich in Ihre Planung ein und prüfen Sie sie bei Änderungen erneut, statt aus der Gruppenzugehörigkeit auf eine Netzwerkabsicherung zu schließen. Die GitHub-Ankündigung zu Runner Groups ist die maßgebliche Quelle für diesen Stand.

Für ein konkretes Team lässt sich die Konfigurationsentscheidung damit auf drei unterschiedliche Fragen aufteilen: Wer darf den Runner anfordern? Welcher Workflow wird an welche Gruppe geroutet? Welche Netzwerk- und Ausführungsbedingungen muss der Runner erfüllen? Runner Groups und Workflow-Routing beantworten die ersten beiden Fragen. Die dritte müssen Sie anhand der Fähigkeiten des tatsächlichen Runner-Typs bewerten.

Das ist besonders wichtig, wenn ein Build interne Dienste erreichen muss oder wenn Veröffentlichungsschritte auf ein bestimmtes Netz angewiesen sind. Prüfen Sie in diesem Fall nicht nur, ob der Workflow startet, sondern auch, welche Ressourcen er während des Laufs erreicht und welche Geheimnisse verfügbar sind. Wenn GitHub-hosted macOS runners die benötigte Netzwerksteuerung nicht abbilden, sollten Sie die Anforderung vor einer Migration präzisieren und eine geeignete Alternative gesondert testen. Eine selbst gehostete Lösung bringt wiederum eigene Betriebs-, Wartungs- und Sicherheitsaufgaben mit sich; Runner Groups ersetzen diese Abwägung nicht.

Für den laufenden Betrieb gehört jede Änderung an Zugriff, Routing oder Parallelitätssteuerung in einen nachvollziehbaren Änderungsprozess. Erfassen Sie Anlass, betroffene Repositories, geplante Tests, zuständige Personen und Rückfallweg. Bei Organisationen mit mehreren Teams hilft eine regelmäßige Überprüfung der Gruppenzwecke und Zugriffslisten, verwaiste Berechtigungen oder unklare Zuständigkeiten sichtbar zu machen. Die Prüfung sollte an tatsächlichen Arbeitsabläufen ausgerichtet sein, nicht an der bloßen Zahl vorhandener Gruppen.

Wenn die Prüfung zeigt, dass GitHub-hosted macOS runners Ihre benötigte Ausführungsumgebung nicht abdecken, vergleichen Sie die Alternativen anhand der konkreten Anforderungen: Netzwerkzugriff, Kontrolle über das System, Betriebsaufwand und Nutzungsmuster. Ein eigener Mac kann für dauerhaft ausgelastete Workloads oder erforderliche physische Schnittstellen passender sein, verursacht jedoch Anschaffungs- und Wartungsaufwand. Ein entfernter Mac von VPSMerge kann eine zu prüfende Option sein, wenn Sie eine zeitlich begrenzte macOS-Umgebung benötigen; stellen Sie dabei keine automatische Integration mit GitHub Actions voraus, sondern verifizieren Sie den gewünschten Ablauf selbst. Details zu Zugang und Nutzung finden Sie in der VPSMerge-Hilfe; bei einer konkreten Anforderung können Sie diese mit dem VPSMerge-Team besprechen.

Die Entscheidung für Runner Groups ist damit vor allem eine Frage sauberer Zugriffsgrenzen und überprüfbarer Workflow-Zuweisungen. Richten Sie erst die Berechtigungen ein, testen Sie erlaubte und abgewiesene Fälle und ändern Sie Standard-Labels nur nach einer erfolgreichen Abnahme. Für Netzwerksteuerung oder besondere Betriebsanforderungen ist eine separate Prüfung des Ausführungsmodells erforderlich.