# What Is a CI Runner? Managed vs Self-Hosted Explained

> A CI runner is the machine that executes your pipeline jobs. Learn how runners work, the difference between hosted, self-hosted, and managed runners, and where cost comes from.

Source: https://latchkey.dev/learn/ci-cd-concepts/what-is-a-ci-runner  
Updated: 2026-06-25

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".

## FAQ

### What is What is a CI Runner? managed vs Self-Hosted explained?

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.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt