Self-Hosted vs GitHub-Hosted Runners: The Real Cost Comparison
Hosted runners are a per-minute bill with zero ops. Self-hosted runners trade that bill for cloud compute plus the time you spend operating them - and the second cost is easy to undercount.
The "which is cheaper" question has no fixed answer; it depends on volume, machine size, and how much engineering time the fleet consumes. Here is how to compare them without fooling yourself.
How hosted runners bill
GitHub-hosted runners charge per minute of job time, rounded up, with a multiplier for larger or non-Linux machines. The price is predictable and includes maintenance, but it scales linearly with usage and you cannot tune the machine.
What self-hosted actually costs
- Cloud compute for the instances (often cheaper per minute than hosted).
- Idle time if runners sit waiting for jobs.
- Engineering time to patch, scale, and clean up the fleet.
- Reliability incidents: stale runners, full disks, orphaned jobs.
The crossover point
At low volume, hosted wins on simplicity. At high volume or with heavy/specialized builds, self-hosted compute can be far cheaper per minute - but only if utilization is high and ops overhead stays low. Managed runner platforms aim to capture the compute savings without the ops cost.
How to compare honestly
Put a dollar figure on engineering hours, not just instance bills. A self-hosted fleet that saves on compute but costs an engineer a day a week is not actually cheaper. Re-runs from transient failures also inflate both sides - count them.
Key takeaways
- Hosted = predictable per-minute price, zero ops, no tuning.
- Self-hosted = cheaper compute but you pay in idle time and ops.
- The crossover favors self-hosted at high volume with high utilization.
- Always price engineering time and re-runs, not just the instance bill.