GitHub Actions has evolved into a comprehensive continuous integration and continuous deployment platform, enabling developers to automate software workflows directly from their repositories. The platform supports a wide array of operations, ranging from building containers and deploying web services to automating community management tasks like welcoming new users to open-source projects. By integrating with GitHub Packages, the ecosystem simplifies package management, offering fast distribution via a global CDN, automatic dependency resolution, and version updates using the inherent GITHUB_TOKEN. The versatility of the platform is evident in its language support, which includes Node.js, Python, Java, Ruby, PHP, Go, Rust, and .NET, allowing teams to build, test, and deploy applications in their preferred environment.
The execution environment for these workflows is provided by runners, which can be either GitHub-hosted or self-hosted. GitHub-hosted runners provide a standardized experience across Linux, macOS, Windows, ARM, GPU, and containerized environments. These runners allow for matrix builds, a feature that saves significant development time by simultaneously testing code across multiple operating systems and runtime versions. The infrastructure for Windows and Ubuntu runners is hosted on Azure, sharing the same IP address ranges as Azure datacenters, while macOS runners are distinctively hosted in GitHub's own macOS cloud. For organizations requiring more granular control, customization, or specific hardware configurations, self-hosted runners offer a viable alternative, particularly when utilizing physical hardware like the Mac mini.
macOS Runner Image Lifecycle and Availability
The availability of macOS runner images follows a structured lifecycle that impacts how developers configure their workflow files. As of February 26, 2026, the macOS 26 runner image is generally available for GitHub Actions. Previously in public preview, these runners now provide a fully supported environment for building and testing applications with the latest macOS and Xcode tooling. The macOS 26 runners are optimized for modern hardware, running natively on Apple Silicon (arm64) while also maintaining support for Intel (x64) architectures.
To utilize these environments, developers must specify the correct labels in their workflow files. The macos-26 label designates the standard macOS runner for arm64 architecture. For Intel-based workflows, the macos-26-intel label is used. Organizations requiring more computational resources can opt for larger instances, such as macos-26-large, which provides an extra-large runner for x64 architecture, or macos-26-xlarge, which offers an extra-large runner for arm64. Understanding these labels is critical for ensuring compatibility and performance in CI/CD pipelines.
This general availability follows a longer transition period for previous versions. GitHub Actions supported macOS 15 in preview mode starting in September 2024, with general availability for all customers commencing on April 10, 2025. Azure DevOps followed a similar trajectory, supporting macOS 15 in preview mode from March 18, 2025. A significant infrastructure shift occurred regarding the macos-latest label. Starting August 4, 2025, and completing by August 30, 2025, macOS 15 was scheduled to become the default version for the macos-latest label in both GitHub Actions and Azure DevOps. This transition affected a broad range of runner images, including Ubuntu 22.04 and 24.04, macOS 13, macOS 13 Arm64, macOS 14, macOS 14 Arm64, macOS 15, macOS 15 Arm64, Windows Server 2019, Windows Server 2022, and Windows Server 2025.
Network Configuration and Firewall Requirements
When deploying GitHub-hosted runners, network configuration is a critical consideration, particularly for organizations with strict security policies. The IP address ranges used by GitHub Actions runners are not static in a way that simplifies firewall allowlisting. Because the infrastructure spans numerous IP ranges, GitHub recommends against using these ranges as allowlists for internal resources. Instead, organizations are advised to use larger runners with static IP ranges or to deploy self-hosted runners for better network control.
The list of IP addresses associated with GitHub Actions can be retrieved via the GitHub REST API, specifically through the actions key in the response of the GET /meta endpoint. This list is updated once a week to reflect changes in the infrastructure. For macOS runners, the traffic flows through GitHub's own macOS cloud, distinct from the Azure-hosted Windows and Ubuntu environments.
A GitHub-hosted runner must establish connections to specific GitHub-owned endpoints to perform essential communication operations. Additionally, workflows may require access to external networks specified within the actions themselves. To ensure proper communication, firewalls and network configurations must allow traffic to these endpoints. A common technical challenge arises with CNAME records; some domains used by GitHub are configured using CNAME records, and certain firewalls require rules to be added recursively for all CNAME targets to ensure unblocked connectivity.
Self-Hosted Runner Implementation on macOS
For teams requiring specific hardware acceleration, persistent storage, or isolated network environments, setting up a self-hosted runner on a Mac mini provides increased control over the CI/CD setup. This approach contrasts with the pay-as-you-go model of online runners by leveraging existing physical hardware. The setup process requires a Scaleway account with appropriate IAM permissions, a Mac mini, and a GitHub repository with administrator rights. Additionally, a package manager, preferably Homebrew, should be installed on the machine.
The foundation of a secure self-hosted runner setup is the creation of a dedicated user account to run the runner service. This isolation prevents the runner from operating with full administrative privileges unless necessary. The following terminal commands create a user named gh-runner and configure its essential properties within the macOS directory service:
bash
sudo dscl . -create /Users/gh-runner
sudo dscl . -create /Users/gh-runner UserShell /bin/bash
sudo dscl . -create /Users/gh-runner RealName "GitHub runner"
sudo dscl . -create /Users/gh-runner UniqueID "1001"
sudo dscl . -create /Users/gh-runner PrimaryGroupID 20
sudo dscl . -create /Users/gh-runner NFSHomeDirectory /Users/gh-runner
Once the user structure is defined, a password must be set. Replace password with a secure credential of your choice:
bash
sudo dscl . -passwd /Users/gh-runner password
To grant the runner necessary permissions to install software and manage system resources, the user must be added to the admin group:
bash
sudo dscl . -append /Groups/admin GroupMembership gh-runner
After configuring the user account, switch to the gh-runner context to continue the setup:
bash
su gh-runner
With the user account active, ensure that essential tools are installed. Git is required for repository operations, and Rosetta 2 is necessary if the Mac mini is running on Apple Silicon but needs to execute Intel-based binaries. Homebrew can be used to manage these installations:
bash
git --version
brew install git
softwareupdate --install-rosetta
Configuring and Connecting the Runner
The final stage of the implementation involves registering the self-hosted runner with the GitHub repository. Navigate to the GitHub repository settings, select "Actions" under "Code and automation," and then click on "Runners." The interface will display a list of currently configured runners. To add the new Mac mini, click "New self-hosted runner."
The configuration page will prompt for the operating system and architecture. For a Mac mini with Apple Silicon, select "macOS" as the runner image and "ARM64" as the architecture. GitHub will then provide a series of shell commands to authenticate the machine, download the runner runtime, and configure the connection. Executing these commands binds the local hardware to the GitHub Actions infrastructure, enabling it to receive and execute workflow jobs.
This setup bridges the gap between the standardized, cloud-based environments offered by GitHub-hosted runners and the specific needs of specialized development workflows. Whether utilizing the newly available macOS 26 images for native arm64 performance or maintaining self-hosted Mac minis for custom tooling, the platform offers flexible pathways for modern software delivery.
Conclusion
The GitHub Actions ecosystem provides a robust foundation for automating software development workflows, with significant recent advancements in macOS support. The general availability of macOS 26 runners marks a shift toward fully supported, native Apple Silicon environments, offering developers optimized performance for modern Xcode tooling. Simultaneously, the platform maintains backward compatibility and flexibility through Intel-based runners and various size options.
For organizations with complex network requirements or specific hardware dependencies, self-hosted runners remain a critical component of the CI/CD strategy. The ability to deploy runners on physical Mac minis allows for deep customization, though it requires careful management of user permissions, network firewall rules, and CNAME configurations. As the macos-latest label transitions to newer OS versions, understanding the lifecycle of runner images and the networking implications of both hosted and self-hosted options is essential for maintaining resilient and secure development pipelines.