GitHub-Hosted vs Self-Hosted Runners: Cost & Ops
GitHub-hosted runners are zero-setup but pricey; self-hosted runners are cheap compute but you own all the ops.
Every GitHub Actions job runs on a runner. GitHub-hosted runners are managed and billed at a premium per minute; self-hosted runners use your own machines at raw compute cost but with full maintenance burden. Here is the trade - and the third option.
| GitHub-hosted | Self-hosted | Managed (Latchkey) | |
|---|---|---|---|
| Per-minute cost | Highest | Lowest compute + ops time | Low (~70% under hosted) |
| You maintain infra | No | Yes - scaling, patching, cleanup | No |
| Cold start / queue | Can queue | Fast if kept warm | Warm pools (no queue) |
| Caching | Basic | DIY | Built-in |
| Flaky-failure recovery | No | No | Self-healing auto-retry |
| Best for | Low volume | Full control, large scale | Low cost + low ops |
GitHub-hosted
Zero setup, billed per minute at a premium, with occasional queueing under load. Great for small or occasional pipelines; expensive at scale.
Self-hosted
Cheapest raw compute and full control, but you own scaling, patching, disk-full and stale-runner cleanup, and the reliability headaches of long-lived infrastructure.
The managed middle ground
Managed runners like Latchkey give self-hosted economics - roughly 70% cheaper per minute than GitHub-hosted - with zero ops, warm pools so jobs never queue, and self-healing that auto-retries transient failures.
The verdict
Use GitHub-hosted for low volume and self-hosted only if you want total control with a team to run it. For most teams, managed runners deliver low cost and low ops together - start free and benchmark against your builds.