How to Configure GitHub Actions macOS Runner Groups? 2026 Enterprise Guide

GitHub’s June 25, 2026 announcement says macOS runners can be added to Runner Groups, with the feature available on Team and Enterprise plans; it also states that macOS runners do not support network configuration (official changelog). Configure group access first, route workflows second, and consider restricting standard runner labels only after representative pipelines pass validation. If you need network isolation, do not treat a Runner Group as the solution.

Who should read this: GitHub organization or enterprise administrators managing runner access and policy.
CI platform engineers routing macOS workflows to approved groups.
Technical and security leads checking whether runner access matches team trust boundaries.

Last updated November 4, 2026. Feature availability and behavior were checked against GitHub’s Runner Group access guidance, workflow syntax reference, larger runner management guide, organization Actions policy documentation, and the changelog linked above. Your account’s controls and interface remain the final check.

Check eligibility and identify the actual control you need

Start by confirming that the feature and controls are available in your organization or enterprise account. GitHub’s announcement identifies Team and Enterprise as the applicable plans, but your current settings and the official documentation should determine what you can configure in your environment. Do not base a rollout on an old screenshot or an assumption that every organization has identical controls.

Also identify which runner type you are managing. This guide covers GitHub-hosted macOS runners. Self-hosted runners have a different management model; their setup instructions do not automatically apply to GitHub-hosted macOS runners. If your existing documentation mixes both types, separate it before making policy changes.

Then state the requirement in operational terms:

• Repository access: which repositories may send jobs to this runner group?
• Workflow routing: which jobs should request the group?
• Concurrency management: do you need a group-level limit, and what does GitHub currently let your account set?
• Network configuration: does the job require a particular route, address range, or network boundary?

These are separate controls. In particular, a runner group is not network isolation. GitHub’s announcement explicitly says macOS runners do not support network configuration. If network behavior is a firm requirement, record it as an unresolved capability gap rather than trying to compensate with a group name or repository permission.

For broader policy context, review your organization’s GitHub Actions restrictions. Those settings can affect whether workflows run at all; they are not a substitute for choosing the right runner group.

Define trust boundaries before creating a group

A group should represent a policy boundary that administrators can explain and review—not just a convenient label. Start with a short record for each proposed group: its purpose, owner, permitted repositories, intended workflow types, and the reason those repositories belong together.

Consider whether the following workloads can genuinely share the same access scope:

• Routine builds from maintained internal repositories.
• Pull request workflows that may process changes from outside contributors.
• Release or signing workflows that can access sensitive credentials.
• Experimental jobs whose code and dependencies are less controlled.

Do not assume that these cases are safe to place in one group just because they all build for macOS. Repository authorization says which repositories may access the group; it does not establish that every workflow in an authorized repository has the same trust level. Review the trigger, code path, and secrets available to each workflow separately.

Scenario: A team has internal application builds and a release workflow in the same repository. The build job compiles test changes, while the release job can access deployment credentials. A single repository-level permission may be convenient, but it does not answer whether both workflows should share a runner route. Document the difference, then verify which controls are available for the specific workflows and events in your account.

The Runner Group access-control documentation is the authority for supported access options. Avoid promising a finer permission level than the account interface actually offers. Where the available group policy is broader than your trust boundary, split the workflow or reconsider the execution environment instead of treating the group as stronger isolation than it is.

Create the group and verify repository authorization

Use the current GitHub interface or documentation to create the group and configure its repository access. The exact settings can change, so follow the controls visible in your account rather than relying on a fixed menu path. The larger runner management guide provides the current management reference.

A careful rollout follows this sequence:

1. Record the baseline. List the repositories, workflows, runner types, and labels currently used by macOS jobs. Include shared or reusable workflows that may hide the runner selection outside the repository you first inspect.
2. Create a narrowly scoped group. Give it a name that communicates its purpose and owner. Apply the least broad repository access policy supported by your account.
3. Review existing runner assignments. Check which runners belong to the new group and whether existing groups or defaults still provide another route to execution resources.
4. Test an authorized repository. Use a low-risk job and verify that it can request the intended group.
5. Test an unauthorized repository. Confirm that a repository outside the approved scope cannot use the group. Record the observed result as an acceptance test, not as a general guarantee about other accounts.
6. Document the outcome. Keep the policy, test repository, workflow, observed result, owner, and rollback action in the change record.

The negative test matters. A job succeeding in the approved repository proves only that one route worked; it does not demonstrate that repositories outside the policy are denied. Also check whether a pre-existing group or runner assignment leaves an unintended path available.

Route macOS CI workflows and prove the route

Once authorization is in place, update a representative workflow to request the intended group. GitHub Actions uses runs-on to select a runner; consult the workflow syntax reference for the supported group and label syntax. The group name and any label must match the configured runner selection. Treat the snippet below as a shape to verify against current syntax and your account, not as a copy-and-paste guarantee:

jobs:
  macos-build:
    runs-on:
      group: macos-builders
      labels: macos-label
    steps:
      - run: echo "Run a low-risk validation job"

Replace the example group and label with values configured for your environment. If your account’s documented syntax or runner entry differs, follow that instead. Runner labels help select a compatible runner; group selection applies the access scope. A label alone should not be treated as proof that a job is constrained to the intended group.

Validate the route with a low-risk workflow in an authorized repository. Inspect the run details and confirm that the selected runner belongs to the intended group. Then test a repository outside the access scope and confirm that the route is rejected as expected. Keep the job simple enough that a build failure does not obscure whether routing worked.

For macOS CI workflow routing, check both positive and negative behavior:

• The allowed workflow can request the group.
• The run uses a runner associated with that group.
• A repository outside the group’s permitted scope cannot use it.
• A workflow with a mismatched group or label fails clearly rather than silently taking an unintended route.
• Release and external-contribution workflows follow the policy you documented, including their triggers and credential exposure.

Do not infer access control from a green check mark alone. A successful run may not answer which route was selected or whether a different workflow can reach the same resource.

Adjust standard labels and concurrency only after acceptance

Do not disable or limit standard GitHub-hosted runner labels as an early cleanup step. First inventory every workflow that uses them, including release jobs, scheduled tasks, reusable workflows, and repositories owned by other teams. A missed dependency can produce rejected jobs or queues after a policy change.

Use a staged change:

• Migrate a representative workflow and verify its route.
• Have each owning team confirm its relevant macOS workflows.
• Monitor for jobs that still request the standard labels.
• Record a rollback route and the person responsible for restoring it.
• Restrict the labels only when the inventory and acceptance evidence support the change.

Organization-level controls for limiting GitHub Actions can have broader effects than a single runner-group change. Review the official organization policy guidance before changing those controls.

Treat concurrency as a capacity and scheduling policy, not a security boundary. Check the current supported settings in the account and agree on a limit based on your own build demand. Do not copy a number from another organization or claim a fixed throughput without evidence from your workload. Record what should happen when the limit is reached, who can change it, and how you will detect jobs waiting longer than expected.

Use this decision path before tightening runner policy:

• If the group can be scoped to the intended repositories and the representative workflow reaches it, then proceed with a staged rollout.
• If an unauthorized repository can still reach the route, then stop and review existing groups, assignments, and organization policy before expanding the change.
• If the workflow needs network configuration, then do not rely on Runner Groups; assess a different execution environment that can meet the requirement.
• If the team cannot identify every dependency on standard labels, then keep the existing route available until the inventory and rollback plan are complete.
• If a group-level concurrency setting is proposed, then confirm the supported control and base the value on measured team demand rather than an assumed universal capacity.

Keep the operating record useful after launch

Runner policy changes are easier to maintain when the record explains why each boundary exists. Keep the group owner, authorized repositories, workflow purpose, route syntax, validation results, exceptions, and rollback steps together. Revisit the record when a repository changes ownership or when release workflows gain access to new credentials.

Also capture what the group does not provide. GitHub’s stated macOS network-configuration limitation is important to anyone reviewing the design later. A policy document that calls a group “isolated” can lead the next administrator to assume a network guarantee that the feature does not provide.

If your process requires internal guidance on handling sensitive information, connect the runner policy review to your existing data privacy practices. For questions about account operation or service details, use the VPSMerge help resources; do not assume that a remote Mac automatically integrates with GitHub Actions or replaces a particular runner feature.

Frequently asked questions

How can repository access be restricted?

Use the group’s supported repository access policy, then validate it with both an allowed repository and one outside the scope. Check the current access-control documentation and the account interface before rollout. The test confirms observed behavior for that account and configuration; retain the result in the change record rather than treating it as a universal permission guarantee.

How can a workflow be routed to a specific group?

Set the workflow’s runner selection to the intended group and any required matching label, following GitHub’s current syntax. Then inspect a low-risk run and confirm the runner belongs to that group. Group selection and label matching work together, but a label by itself is not evidence that the workflow used the intended access scope.

What should be checked before restricting standard runner labels?

Search across repositories for workflows that still request standard labels, including shared workflows and release automation. Migrate and validate representative jobs before restricting the route. Watch for rejected or queued jobs, keep a rollback action available, and assign an owner to the change. If the inventory is incomplete, delay the restriction.

Does a Runner Group isolate macOS runner network traffic?

No. GitHub’s June 2026 announcement states that macOS runners do not support network configuration. A group can help control which repositories access runners and how workflows are routed, but that is not a network isolation feature. If network configuration is a hard requirement, assess another execution environment rather than expanding the group policy.

If your acceptance checks reveal that GitHub-hosted macOS runners cannot meet a required network setup or execution model, compare the remaining options against the actual workload. A remote Mac may offer a different operating arrangement, but it does not automatically provide GitHub integration or solve network requirements; verify both before changing the design. VPSMerge rents access to real Mac hosts on weekly, monthly, or quarterly terms, which may suit temporary evaluation or a team that needs a separate macOS environment. It is less suitable when you require a particular physical interface or a long-running workload that makes ownership the better fit. Review the available remote Mac option against your requirements before deciding.

Frequently asked questions