Choosing the Right Runner: Hosted vs Self-Hosted vs Managed
The runner you choose decides your CI bill, your maintenance burden, and your queue times.
Your workflow YAML is only half the story; where it runs is the other half. GitHub-hosted, self-hosted, and managed runners sit at different points on the cost/control/effort spectrum. This lesson compares them so you can pick deliberately instead of defaulting.
GitHub-hosted runners
GitHub provisions a fresh VM per job: zero maintenance and instant availability. The trade-offs are price (per-minute billing that adds up at scale) and limited control over machine size and the software image. They are the right default for small teams and low CI volume.
Self-hosted runners
- Cheapest per-minute compute if you already run infrastructure and have spare capacity.
- Full control over machine size, hardware, and pre-installed software.
- You own all the operations: patching, scaling, autoscaling, security isolation, and cleanup.
- Real risk if misconfigured: stale state between jobs and security exposure from untrusted PRs.
Managed runners
Managed runners are a middle path: a provider runs the fleet for you, so you keep the zero-ops experience of hosted runners while paying much less per minute. Latchkey managed runners are roughly 69% cheaper than GitHub-hosted runners with no operational overhead: you change runs-on and keep ephemeral, isolated jobs without managing any infrastructure yourself.
How to choose
- Low volume, want zero ops: GitHub-hosted is fine.
- High volume, have an ops team and spare infra: self-hosted can be cheapest if you can absorb the maintenance.
- High volume, want hosted-style simplicity at lower cost: managed runners like Latchkey.
Key takeaways
- GitHub-hosted means zero ops but the highest per-minute price; best for low CI volume.
- Self-hosted is cheapest compute but you own all the operations and security risk.
- Managed runners like Latchkey give hosted-style simplicity at roughly 69% lower cost with no ops.