GitHub Actions Hosted Runners vs Self-Hosted Runners: Speed, Minutes, and the Machine You Now Babysit

Every team that uses GitHub Actions long enough has the same conversation. Builds are slow. The monthly minutes are running out, or the bill for them showed up. Somebody points out that there is a perfectly good machine sitting idle, and GitHub lets you register your own runner in about five minutes. Why pay for slow cloud VMs when you could run jobs on hardware you already own?

Sometimes that is exactly the right call. Sometimes it trades a predictable line item for a pet server, a security hole, and a Friday afternoon debugging why a build passes in CI but only on Tuesdays. I have moved pipelines in both directions, and the decision is less about raw speed than people think. This is a practical comparison of GitHub-hosted runners and self-hosted runners for GitHub Actions: where each wins, what each really costs, and the failure modes that do not show up in a quick benchmark.

What you get with GitHub-hosted runners

A GitHub-hosted runner is a fresh virtual machine that GitHub spins up for each job and throws away afterward. You pick an image with runs-on: ubuntu-latest, windows-latest, or macos-latest, and the machine arrives with a large set of preinstalled tools: multiple language runtimes, Docker, common CLIs, and browsers for testing.

The important properties:

• Clean every time. No leftover files, no stale caches, no processes from the last job. A build that passes on a hosted runner will pass on the next one too, barring flaky tests.
• Zero maintenance. GitHub patches the images, updates the tools, and keeps the fleet running. You never SSH into anything.
• Isolation. Each job runs in its own VM. That is what makes hosted runners safe for public repositories that accept pull requests from strangers.
• Free for public repos on standard runners, and a monthly allowance of included minutes for private repos that depends on your plan.

The trade-offs are just as clear. Standard runners are modest machines, especially for private repositories. Every job starts cold, so dependency installs, Docker layer builds, and compilation caches must be restored from GitHub’s cache service or rebuilt. There is a cap on job duration. The runners cannot reach your private network without a VPN or tunnel step. And once you exceed your included minutes, you pay per minute, with Windows and macOS minutes billed at a multiple of Linux minutes. macOS is the painful one.

GitHub also sells larger hosted runners with more CPU, more memory, ARM, and GPU options on paid plans. They cost more per minute but often finish jobs so much faster that the total bill barely changes. Before you self-host purely for speed, it is worth pricing a bigger hosted runner for your slowest job.

What you get with self-hosted runners

A self-hosted runner is GitHub’s open-source runner application installed on a machine you control: a physical server, a VM, a cloud instance, or a container in Kubernetes. It connects outbound to GitHub, waits for jobs that match its labels, and runs them. You target it in a workflow with labels like runs-on: [self-hosted, linux, x64].

What that gets you:

• Any hardware you like. Sixteen cores, 64 GB of RAM, a GPU, an ARM board, a Mac mini for iOS builds. You are limited only by what you own or rent.
• Warm caches. Docker layers, package manager caches, and build artifacts can stay on local disk between jobs. For many projects this is the single biggest speedup, larger than CPU count.
• Network access. The runner sits wherever you put it, so it can reach internal package registries, staging databases, or deployment targets on a private network without exposing them to the internet.
• No per-minute bill from GitHub for the compute itself, and much longer job time limits.

And what it costs you: everything GitHub was doing for you. Patching the OS, installing and updating toolchains, disk cleanup, monitoring, keeping the runner application current, and securing a machine that executes whatever code lands in a workflow file.

Speed: where self-hosted wins, and where it does not

Self-hosted runners are usually faster, but not always for the reason people expect.

The biggest time sink on hosted runners is rarely compilation itself. It is setup: downloading dependencies, restoring caches, pulling base images, and building Docker layers from scratch. A persistent self-hosted runner with a warm disk skips most of that. I have seen a Node monorepo go from eleven minutes to under three just by keeping node_modules caches and Docker layers on local NVMe, on a machine with fewer cores than the hosted runner it replaced.

Where self-hosted does not help much: jobs that are embarrassingly parallel across a matrix. Hosted runners scale out instantly. Twenty matrix jobs on GitHub’s fleet start roughly together. Twenty matrix jobs on your one self-hosted box queue up behind each other unless you run many runner instances or an autoscaler. Throughput and latency are different problems; one big machine improves latency for a single build but can make a busy team’s queue worse.

There is also a middle path worth knowing about. Several third-party providers sell managed runners that drop into GitHub Actions by changing the runs-on label, often on faster hardware and at lower per-minute prices than GitHub’s own. They keep the clean, disposable model and remove the maintenance. If your motivation is speed and price rather than private network access or special hardware, compare those before building your own fleet.

Cost: minutes versus machines

The hosted-runner bill is easy to reason about: minutes used, times the rate for each operating system, minus your plan’s included allowance. The self-hosted bill is the machine, plus power or cloud instance fees, plus the time to run it.

A rough way to compare:

1. Pull a month of Actions usage from your billing page. Note minutes by OS.
2. Estimate how many of those minutes are setup and cache restore versus real work. That portion shrinks dramatically on a warm self-hosted runner.
3. Price a machine that could handle your peak concurrency, not your average.
4. Add maintenance: realistically a few hours a month for patching, toolchain updates, disk cleanup, and the occasional broken job, more at first.

For small teams on Linux, hosted runners often win once maintenance time is counted honestly. The math flips quickly for heavy macOS usage, where minute multipliers make a used Mac mini pay for itself fast, and for large teams whose builds run all day.

One pricing note that has shifted recently: GitHub has announced and then revisited a small per-minute platform charge for self-hosted runner usage on private repositories. Whether and how it applies depends on timing and plan, so check the current Actions billing documentation before assuming self-hosted minutes are entirely free.

Security: the part that should slow you down

This is the section people skip, and it is the one that matters most.

A runner executes whatever the workflow tells it to. On a hosted runner, that code runs in a disposable VM that GitHub destroys afterward. On a persistent self-hosted runner, it runs on your machine, with whatever network access, credentials, and files that machine has, and anything it leaves behind is still there for the next job.

GitHub’s own documentation recommends against using self-hosted runners with public repositories. The reason is simple: if a workflow runs on pull requests from forks, anyone on the internet can open a pull request that edits the workflow or the build scripts and gets code execution on your runner. Settings that require approval for first-time contributors help, but the safe default is clear: public repositories should use hosted runners, full stop.

For private repositories, the risk is smaller but not zero:

• Persistence between jobs. A compromised dependency in one job can leave a process or modified file that affects the next job, possibly from a different repository if the runner is shared at the organization level.
• Network reach. A runner on your internal network is a foothold on your internal network. Put it in a segment that can reach only what builds need.
• Secrets on disk. Credentials written during a job, cached tokens, and Docker login state can outlive the job unless you clean up.

The strongest mitigation is running ephemeral runners: register a runner with the --ephemeral flag so it accepts exactly one job and then deregisters, and recreate it from a clean image each time. Actions Runner Controller does this on Kubernetes, and there are simpler scripts and tools that do it with containers or VMs. Ephemeral runners give back most of the hosted model’s safety, but they also give back some of the cold-start cost, since caches no longer persist on the runner itself. Many teams settle on ephemeral runners with a shared cache volume or a local registry mirror, which keeps most of the speed without keeping job state.

Reliability: the pet server problem

Hosted runners fail in boring, shared ways: a GitHub incident, a queue delay, an image update that changes a tool version. You read the status page, and you wait.

Self-hosted runners fail in personal ways. The disk fills up with Docker images. A system update changes the default Python. The runner service stopped after a reboot and nobody noticed until a release was blocked. The runner application falls far enough behind that GitHub stops sending it jobs. The machine’s power supply dies over a holiday weekend.

The fix for most of these is to treat runners as cattle rather than pets: build them from a script or image, keep toolchain versions pinned in that script, schedule disk cleanup, monitor that the runner is online, and keep at least two so one failure does not stop every pipeline. That is all very doable. It is also a small infrastructure project that someone has to own.

A pragmatic pattern is to keep a hosted fallback. Label self-hosted runners for the heavy jobs that benefit, and leave everything else on hosted runners. If your self-hosted fleet goes down, changing one label gets builds moving again.

When to choose which

Stay on GitHub-hosted runners if:

• The repository is public or accepts outside contributions.
• Your usage fits within included minutes, or the overage is small relative to anyone’s hourly rate.
• You rely on large matrices that benefit from instant scale-out.
• Nobody on the team wants to own another server.

Move to self-hosted runners if:

• Builds are dominated by setup time that a warm cache would remove.
• You need hardware GitHub does not offer at a sensible price: GPUs, lots of memory, specific ARM boards, or Macs for heavy iOS work.
• Jobs must reach private resources that should never be exposed publicly.
• Your minute bill is large and steady, and someone is willing to maintain runners properly.

Consider a managed third-party runner or a larger hosted runner if you mostly want speed and lower cost, but not the maintenance or security work.

My default

For a small team with private repositories, I start on GitHub-hosted runners, tune caching, and only then look at the bill. If one or two jobs dominate the time, I try a larger hosted runner or a managed provider for just those jobs. Self-hosted runners come in when there is a concrete reason: special hardware, private network access, or a steady bill large enough to justify owning the machine. When they do, they run ephemeral, on a restricted network segment, built from a script, with a hosted fallback one label away.

Self-hosted runners are a great tool. They are also a server that runs arbitrary code on command. Choose them because the numbers and requirements say so, not because an idle machine was sitting in the corner looking cheap.