What Is a CI Runner Image (or AMI)?
A runner image is the prebuilt template a runner boots from - an OS plus a curated set of tools and SDKs already installed, so jobs do not have to install them from scratch every time.
Whether it is called an image, an AMI (on AWS), or a VM template, it is the same idea: a snapshot of a ready-to-work machine. The contents of that image largely determine how fast and how consistent your CI is.
What is in the image
A runner image bakes in the operating system, common language runtimes and SDKs, build tools, and the runner agent itself. When a runner launches, it boots this image and is immediately ready to pick up a job - no lengthy provisioning of the base toolchain per run.
Why pre-baking matters
- Speed: tools are present at boot, so jobs skip base-tool installs.
- Consistency: every runner starts from the identical, known baseline.
- Reproducibility: pinning an image version pins the toolchain for all jobs.
AMI specifically
On AWS, the image is an AMI (Amazon Machine Image) - the disk template an EC2 instance launches from. A self-hosted or managed runner fleet typically builds a custom AMI with exactly the tools its jobs need, so each instance comes up pre-loaded rather than installing everything at boot.
The trade-offs
A richer image boots ready for more jobs but is larger and must be rebuilt and re-published whenever the baked tools change. A leaner image is smaller and easier to maintain but forces jobs to install more at runtime. The balance is including what most jobs need while leaving rare, heavy tools to per-job install or caching.
Key takeaways
- A runner image is the prebuilt template a runner boots from.
- On AWS that template is an AMI an EC2 instance launches from.
- Pre-baking tools gives speed, consistency, and reproducibility.
- Richer images boot ready but cost size and rebuild churn - balance them.