Guide to GitHub Actions Runners: Hosted, Self-Hosted, and Third-Party Options

There are three main runner models behind that label: GitHub-hosted runners, self-hosted runners on your own infrastructure, and third-party managed runners that drop into the same workflow. Teams often ask how these options differ, so this post breaks down the tradeoffs.

TL;DR

• Three options behind runs-on: GitHub-hosted (commodity hardware, zero ops, a black box when it fails), self-hosted (your hardware, your on-call), and third-party managed (drop-in fleets, often 2x faster or more).
• Hosted to third-party is a label change, not a full migration. Self-hosting is the opposite.
• The speed-ups come from both hardware and caching. How you configure GitHub Actions caching and where the cache lives both matter.
• GitHub’s proposed self-hosted runner fee (announced December 2025) is still postponed and not in effect as of June 2026, whatever some comparison pages claim.

The three options at a glance

Swipe to see more →

Option 1: GitHub-hosted runners

GitHub provides a fresh environment for each job. Standard Linux runners have 2 vCPUs for private repositories and 4 vCPUs for public repositories; a 1-vCPU Linux option is also available. Larger runners, including x64 sizes up to 96 vCPUs and GPU configurations, are available on Team and Enterprise Cloud.

Runner performance differs even at the same size. In RunsOn’s November 5, 2026 benchmark, Avrea led the four-vCPU x64 combined build comparison at 6m58s, versus GitHub’s 18m18s. Both runners have 16 GB of RAM. The ranking sums median Rust, TypeScript and Docker build-step times with build caches disabled; queueing and runner overhead are separate. See the full provider results.

For serial compute, RunsOn’s CPU benchmark reports 4,503 PassMark single-thread points for Avrea and 2,306 for GitHub at 2 vCPU and 8 GB RAM, each the median of five runs. The GitHub entry is a 2-core larger runner with the same CPU and memory allocation as its standard private-repository runner. RunsOn also sells runners.

More vCPUs help work that can run in parallel, but core count alone does not predict serial performance: GitHub’s tested runner sizes use different processors. Caching is a separate choice. GitHub provides 10 GB of cache storage per repository at no charge, and eligible accounts can raise the limit with paid storage. Workflows can reuse dependencies through actions/cache and Docker layers through BuildKit cache exports; a fresh runner does not mean rebuilding every layer.

GitHub shows job and step durations, searchable logs, and aggregate usage and performance metrics. Per-step CPU and memory measurements need additional instrumentation or a runner provider that collects them. Our observability guide covers those differences.

Pricing: standard GitHub-hosted runners are free for public repositories. GitHub plans include $12 to $300 per month for eligible compute, shared by private and internal repository runners and cloud sandboxes. Team and Enterprise Cloud can also use it for eligible larger runners. Larger runners remain charged in public repositories. Beyond included usage, standard 2-core Linux x64 costs $0.006/min and the 1-core option costs $0.002/min. Larger-runner rates vary by configuration; the 5-core M2 Pro macOS runner costs $0.102/min. See GitHub’s runner rates and included usage.

Right call when: builds are light, volume is low, or you would rather not own any infrastructure. For most public repos it is the correct default.

Option 2: Self-hosted runners

You register your own machines and GitHub schedules jobs onto them. Going self-hosted is what you do when you need something the hosted fleet can’t give you: specific hardware (GPUs, big disks, more cores), access to a private network, or data that can’t leave your environment.

On paper it looks cheap: better hardware and more control for what seems like the cost of the compute alone. The real cost is mostly operational. You own provisioning, image building, caching, autoscaling, patching, and the page at 2am when the fleet wedges. The default runner is also persistent, so state leaks between jobs and you inherit a class of flaky failures unless you build ephemeral runners yourself. GitHub’s own hosted-versus-self-hosted writeup is a good place to reason through the real total cost of ownership: the infrastructure, staffing, and support that the per-minute compute price hides. It is a useful read, though like this post it is of course not purely objective. They are in the business of selling you build minutes, after all.

There is also a security cost that is easy to underestimate. That same non-ephemeral default means a single compromised job, from a malicious dependency or a poisoned action, can backdoor the runner and reach into the jobs that run after it. GitHub puts it plainly: self-hosted runners “do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow” (GitHub secure-use docs). And because the runner usually sits inside your network, that foothold has line of sight to internal services, secrets, and the cloud metadata endpoint, which is why GitHub’s guidance is to put runners behind a zero-trust, defense-in-depth setup. It is not theoretical: attackers have used self-hosted runners as backdoors in the wild (Sysdig). Public repos are even riskier, which is why GitHub says not to put self-hosted runners on them at all, but the exposure does not vanish on private ones.

Tools can reduce the operational burden: Actions Runner Controller (ARC) for autoscaling on Kubernetes, RunsOn for ephemeral runners in your own AWS account, Actuated for bring-your-own-hardware microVMs. They help, but you are still running infrastructure.

About the fee: in December 2025 GitHub announced a $0.002/min charge on self-hosted minutes in private repos, set for March 1, 2026, then postponed it indefinitely after the backlash (paying GitHub to orchestrate hardware you already own did not land well). It has not taken effect as of June 2026. Comparison pages still citing it as live are wrong.

Right call when: you need the hardware or the network access, the data-residency requirement is hard, and you have a platform team with the cycles to own it.

Option 3: Third-party managed runners

This is the middle path: faster runners without owning the fleet. You point runs-on at a managed provider and keep the rest of your workflow intact. The provider owns the runner fleet, caching layer, images, scaling, and maintenance.

The difference from self-hosting is not just hardware speed. Self-hosted can be just as fast on a cold build if you rent the same class of hardware. The harder part is everything around it: fast cache restores, sane eviction, Docker layer reuse, package proxies, image updates, autoscaling, and keeping the fleet healthy as workloads change.

That is the real case for a managed provider: you get the runner fleet, caching work, and maintenance without turning CI infrastructure into an internal product. At Avrea, this is the work we focus on. Making the GitHub Actions cache up to 6x faster was one example, and we wrote up how we made the cache faster.

This is now a real category, not just a cheaper GitHub runner market. There are multiple options with a slightly different focus.

Swipe to see more →

BuildJet, a well-known runner provider until recently, shut down its GitHub Actions service in 2026, with runners offline as of March 31, so it is not included above.

For pricing, caching and benchmark results by provider, see our GitHub Actions runner comparisons.

How to choose

Start with the constraint, not just the feature list.

You’re just getting started, you need CI to work and your builds are light. Stay on GitHub-hosted. Even with the quick migration, it might not be worth adding another vendor.

You need specific hardware, GPUs, or private-network access, and you have a platform team that can afford to own CI infrastructure. Self-host, and use ARC or RunsOn so you are not building the orchestration from scratch.

Your builds are slow and you don’t want a big project to fix it. Use a third-party managed runner. This is the sweet spot for teams in the 50 to 500 engineer range, where CI runs hundreds of times a day and ten wasted minutes per run is a tax on everyone.

One trend worth naming: as teams adopt AI coding tools, commit and PR volume climbs and CI is increasingly what can’t keep up. The faster you generate code, the more the runner becomes the bottleneck. But the runner is only the first one. Scaling CI is a moving target: speed up the hardware and jobs start queueing on concurrency limits; raise those and the cache thrashes against its configured storage limit; fix the cache and the flaky tests that were noise at ten PRs a day are constant at a hundred. Every jump in volume surfaces the next bottleneck, and the work is never finished.

How to switch without rewriting workflows

Hosted to third-party is a label swap. Install the provider’s GitHub App, change the label, done:

runs-on: avrea-ubuntu-latest   # was: ubuntu-latest

The only place you touch more than one line is matrix builds or reusable workflows that hard-code labels. Everything else (actions, secrets, triggers) stays put.

The useful move is to duplicate the workflow and run both in parallel for a day. You want real numbers on your own builds, and the first runs on a new provider are cold-cache, so they won’t reflect steady state. Compare warm.

Self-hosting is a different category of work. No label stands up a fleet, so budget for the build and the ongoing operations, not a migration afternoon.

Frequently asked questions

What is a GitHub Actions runner? The machine that executes a workflow job. GitHub-hosted runners are managed by GitHub and destroyed after each job. Self-hosted runners are machines you register and maintain yourself.

What is the difference between GitHub-hosted and self-hosted runners? GitHub-hosted: GitHub owns the hardware, zero setup, per-minute billing. Self-hosted: you own the hardware and all the operational work, no per-minute GitHub charge today, full control over the environment.

Is there a fee for self-hosted GitHub Actions runners? Not currently. GitHub announced a $0.002/min charge on self-hosted minutes in private repos in December 2025, planned for March 1, 2026, then postponed it indefinitely after community pushback. As of June 2026 it is not in effect. Some comparison pages still list it as active. It isn’t.

Are third-party GitHub Actions runners safe? You are trusting a third party with your code and secrets, so vet them. Security-first providers should isolate each job in a clean ephemeral VM and publish clear security/compliance details.

What is the fastest GitHub Actions runner? It depends on your workload, so benchmark on your own build.

Do I have to rewrite my workflows to switch runners? No, moving from hosted to a third-party provider is a runs-on label change. Self-hosting is more involved because you also have to stand up and maintain the runners.

Can I run macOS or ARM builds? Yes. GitHub offers both, with macOS as its priciest tier. Several third-party providers offer Apple Silicon and ARM Linux too. Avrea runs both on M5 Max with Xcode caching.

The runs-on line is one of the easiest levers you have on CI speed, and most teams never pull it. If your builds are slow, that is the first place to look, long before you start splitting test suites.