When to choose GitHub-Hosted runners or self-hosted runners with GitHub Actions

Runner options at a glance

GitHub Actions can be used for CI/CD as well as broader automation, but every workflow has to run somewhere. On GitHub Enterprise Cloud, that means choosing between GitHub-hosted runners and self-hosted runners. Both are built on the same open-source runner software and support macOS, Windows, and Linux, but the resemblance ends there. GitHub-hosted runners are managed virtual machines on GitHub’s infrastructure, with options for larger instances, custom images, static IP ranges, and Azure Virtual Network integration. Self-hosted runners run on infrastructure you own and operate, whether in your own data center or in a cloud account. You handle configuration, security, scaling, and maintenance, which opens the door to running on hardware or in environments that hosted runners can’t reach, such as GitHub Enterprise Server.

Management overhead vs. control

The plug-and-play nature of hosted runners is their main appeal. Pools of VMs are patched and secured by GitHub, and each job gets an ephemeral instance whose disk is reimaged after the run, so no state leaks between jobs. Images come pre-loaded with current versions of common development tools, GitHub CLI, and Docker. You can start writing workflows immediately.

Self-hosted runners give you full flexibility over the environment, but that flexibility comes with ownership of the details: images, caches, patches, network access, availability, and rate-limit monitoring. Keeping runners current also has a hard requirement: any runner more than 30 days behind the current release loses its connection to GitHub Enterprise Cloud. Teams need working knowledge of GitHub Actions architecture, image building, and infrastructure management to operate self-hosted runners reliably.

Scaling and availability

CI/CD workloads are sensitive to wait times, but scaling a highly available fleet on your own is difficult. Provisioning hardware takes time, and maintaining headroom across regions typically requires over-provisioning by 20-25% just to handle spikes and failures. GitHub-hosted runners are backed by Microsoft’s data center operations and a 99.9% availability SLA. Notably, teams that self-host to beat that SLA often find it’s not actually possible, since all runners depend on the same GitHub services and control plane.

Still, self-hosted runners are a reasonable fit when you have a fixed, predictable number of required instances, lack scale-on-demand needs, and are mostly running deployments into non-cloud targets. They are not ephemeral by default, so you’ll need a strategy to keep instances clean between runs, and you’ll lack automatic scaling unless you build or adopt a solution.

GitHub’s Actions Runner Controller (ARC) handles some of those needs by scaling runner pods on Kubernetes, but it brings its own limitations. ARC requires Kubernetes expertise, only supports Linux runners, and container-based workloads introduce troubleshooting complexity around resource contention. High availability is possible by running multiple clusters, but that adds operational burden. ARC cannot help with macOS or Windows workloads: macOS runners require Apple hardware, are limited to two VMs per machine, and can’t be containerized. Windows virtual machines are possible but need a custom orchestrator for scaling, and Windows containers have slow start times and may lack necessary development tools. In practice, GitHub recommends hosted runners whenever macOS or Windows support is required.

Security and compliance

CI/CD security matters because builds touch third-party code and often require access to production systems. GitHub-hosted runners follow a zero-trust, defense-in-depth model. VM isolation keeps builds separate from other runners and corporate resources, so reaching internal or cloud systems requires explicit privilege elevation, preferably using OIDC for short-lived credentials. Ephemeral instances eliminate post-job code persistence, disks are encrypted at rest, and all traffic is encrypted to GitHub. Deployments into Azure traverse Microsoft’s backbone rather than the public internet. The Department of Defense’s DevSecOps Reference Design specifically recommends hosted runners for workloads up to Impact Level 5 based on the reduced attack surface.

Self-hosted runners reverse that security posture. The organization must secure and update the network, images, containers, and caches, and keep a zero-trust design in place if runners have access to corporate resources. That level of network security expertise is a steep requirement. There are also practical prerequisites to avoid rate limiting as you scale: you’ll need to maintain and update both a tool cache and an Actions archive cache.

Troubleshooting and support

When jobs stall or fail, the speed of resolution depends on who owns the environment. GitHub-hosted runners include 24/7 support across time zones, with premium plans offering dedicated reliability engineers and 30-minute response targets for critical issues. GitHub handles runner-specific problems, including performance and queueing, so your team doesn’t need infrastructure expertise.

With self-hosted runners, first-level support is yours. Your team must troubleshoot performance, networking, and queueing problems when they arise. GitHub’s support can help only with the Actions service; issues involving your infrastructure, Kubernetes clusters, or custom orchestration are out of scope. If the problem is in your environment, you’ll be on your own to diagnose and fix it.

Cost picture

Hosted runners bill on a pay-as-you-go basis with no upfront commitment. Enterprise accounts get 50,000 free minutes per month on standard runners. Several built-in advantages reduce total spend: no network egress fees, unlimited Docker Hub image pulls through GitHub’s partnership with Docker, and no staffing costs for runner maintenance and security. Teams with Kubernetes or infrastructure-management offerings may find cost advantages in self-hosting due to right-sizing flexibility and existing expertise.

Self-hosted runners look cheaper on a per-minute basis but shift all infrastructure, storage, network, security, and support costs to the organization. Those costs frequently exceed the hosted alternative once the additional engineering time is counted.

Choosing a path

Self-hosted runners make sense in specific cases: when you’re running GitHub Enterprise Server, when your core business is infrastructure or Kubernetes management, or when compliance requirements exceed what GitHub Enterprise Cloud with data residency can meet. For specialized workloads, a hybrid approach—self-hosted runners only where necessary and hosted runners for everything else—is worth considering.

For most teams without those drivers, GitHub-hosted runners are the stronger fit. They remove infrastructure from the critical path, keep environments secure and current by default, and let engineers spend time on product work rather than runner upkeep.