What Is a GitHub-Hosted Runner? Managed Compute for Actions
A GitHub-hosted runner is a clean virtual machine GitHub spins up for each job, runs your workflow on, and throws away - zero setup, billed per minute.
GitHub-hosted runners are the default when you write runs-on: ubuntu-latest. GitHub owns the fleet, keeps the images patched, and bills you by the minute. Convenient - but the per-minute rate is where many CI bills come from.
How they work
For each job, GitHub provisions a fresh VM from a maintained image, runs your workflow, then destroys the VM. Every job gets a clean, ephemeral environment with no leftover state, so builds are reproducible by default.
What the images include
GitHub maintains Ubuntu, Windows, and macOS images preloaded with common languages, build tools, and SDKs. That broad preinstall is convenient but bloats the image, and the standard sizes are modest (commonly 2 vCPU / 7 GB on Linux) unless you pay for larger runners.
The cost model
You pay per runner-minute, with a free monthly allowance on private repos. Windows and especially macOS minutes cost a large multiple of Linux. Heavy CI usage on hosted runners is where surprise bills come from.
The trade-offs
- Pro: zero ops, clean ephemeral environment, broad image support.
- Con: per-minute pricing adds up fast at scale.
- Con: fixed sizes unless you pay for larger runners.
- Con: occasional fleet-wide incidents you cannot mitigate.
The managed alternative
Managed runners like Latchkey give you the same zero-ops, ephemeral experience but typically around 69% cheaper than GitHub-hosted, served from warm pools to remove cold starts and with self-healing for transient failures.
Key takeaways
- GitHub-hosted runners are fresh, ephemeral VMs GitHub provisions per job.
- They are zero-setup but billed per minute, which scales costly.
- Standard sizes are modest; larger runners cost more.
- Managed runners offer the same convenience at lower cost.