GitHub moved custom images for GitHub-hosted Actions runners to general availability on March 26. Organizations can start from a GitHub-curated base image and preinstall the tools, dependencies, certificates, and configuration their workflows need. The GitHub changelog says images created during the public preview continue to work without a migration.
Build setup into the environment
A prepared image can move repeated bootstrap work out of every job. That is useful for large toolchains, internal certificate bundles, or tightly controlled compiler versions. It also gives a platform team one artifact to review and promote, rather than asking each repository to reproduce the same installation steps in YAML.
The tradeoff is lifecycle ownership. Preinstallation can make a job faster, but it can also hide stale dependencies if nobody rebuilds the image. Teams need a cadence for base-image refreshes, vulnerability response, and retirement of versions still referenced by workflows. GitHub’s announcement establishes availability; it does not make a custom image automatically current.
Treat images as release artifacts
Keep the image definition in version control and make its build reproducible. Produce an inventory of installed software, record the GitHub base image used, and publish immutable image versions before changing a shared alias. A small canary workflow should exercise checkout, network access, package restoration, signing, and any service containers that matter to the fleet.
Repositories should pin or deliberately follow an image channel according to their tolerance for change. Measure cold-start and total job time before assuming the image improves throughput, since queueing and cache behavior can dominate. Finally, document an escape route to a standard hosted image so an image-build or certificate problem does not stop every pipeline at once.
- Custom images for GitHub-hosted runners are now generally available
GitHub · Mar 26, 2026
See the original announcement for availability and release details.