What Is a Runner Image? The Template Behind Every Runner
A runner image is the preconfigured machine template a runner boots from - the operating system plus a curated set of languages, build tools, and SDKs ready to use.
Every runner starts from an image. What is baked into that image decides what tools are available without installing them, how fast the runner boots, and whether your jobs behave consistently across runs.
What an image contains
A base OS (commonly Ubuntu), language runtimes (Node, Python, Go, Java), package managers, build tools, container tooling, and cloud CLIs - preinstalled so your workflow does not have to install them every job.
Why the image matters
- Boot speed: a leaner image boots and cold-starts faster.
- Reproducibility: a fixed image means every job sees the same tools.
- Convenience: preinstalled tools save dependency-install time.
The bloat trade-off
GitHub-hosted images preinstall a huge amount to cover every user, which makes them large and slower to provision. A smaller, purpose-built image boots faster but may require you to install tools your jobs actually need.
GitHub-hosted parity
When you migrate runners, you want an image that matches the tools your workflows assume from GitHub-hosted images, so jobs do not break with "command not found". Parity is what makes a migration drop-in.
Images on managed runners
Latchkey runs GitHub-parity images so your existing workflows work unchanged, while keeping boot fast enough to serve from warm pools.
Key takeaways
- A runner image is the OS-plus-tools template a runner boots from.
- It controls boot speed, reproducibility, and available tooling.
- Hosted images are broad but bloated; purpose-built images are leaner.
- GitHub-parity images make runner migrations drop-in.