What Is a CI Runner? Managed vs Self-Hosted Explained
A runner is simply the computer that runs your CI jobs. The kind you choose drives your pipeline’s speed, reliability, and cost.
Continuous integration needs somewhere to actually execute the work - checkout, build, test, deploy. That machine is the "runner". It picks up a queued job, runs each step, reports status back, and (usually) is torn down afterward.
Hosted runners
Your CI provider supplies ephemeral VMs on demand. They are easy and require zero maintenance, but you pay per minute, have fixed machine sizes, and start cold each time. Heavy or specialized builds can be slow or expensive.
Self-hosted runners
You run the runner agent on your own machines. You control the size, tools, and caching, and can be cheaper at scale - but you own patching, scaling, cleanup, and the reliability problems (disk fills up, runners go stale) that come with long-lived infrastructure.
Managed runners
A managed runner platform gives you self-hosted-style control and economics without operating the fleet yourself. The provider handles provisioning, scaling, caching, and cleanup. The best ones add reliability features on top - for example, automatically recovering from transient and resource failures so flaky jobs do not fail your build.
Where cost comes from
- Minutes billed while jobs run (and queue, on some setups).
- Cold starts and slow dependency installs that inflate every job.
- Re-runs caused by transient failures - paying twice for the same job.
- Oversized runners used "just in case".
Key takeaways
- A runner is the machine that executes CI jobs.
- Hosted = easy but per-minute and fixed-size; self-hosted = control but you operate it.
- Managed runners give control + economics without the ops burden.
- Re-runs from transient failures are a hidden, avoidable cost.