GitHub Actions Runner on Ubuntu 24.04 by cloudimg

GitHub Actions Runner is the official self hosted runner agent from GitHub. It lets you execute your GitHub Actions workflows on machines you control instead of on GitHub hosted runners, which is what you need when a job must reach a private network, use hardware or software GitHub does not offer, run inside your own compliance boundary, or simply run for longer or more often than hosted minutes allow. This image delivers the runner fully installed and dependency resolved on Ubuntu 24.04 LTS, so a working build machine is ready within minutes of launch.

The runner works by opening an outbound long poll connection to GitHub and waiting to be handed a job. That design has a useful consequence for your network: the runner never listens for inbound CI traffic, so this image opens no inbound port other than SSH for your own management. There is nothing to expose to the internet and nothing to put behind a load balancer.

Application stack: the official runner agent runs under a dedicated non root service account that has no password and no sudo rights, because a runner executes whatever code your workflows contain. A systemd unit is installed and ready, and the pre installed toolchain covers what real workflows actually need: git for checkout, Docker for container jobs and service containers, a C and C++ build toolchain with make, Python with pip and venv, plus jq, rsync, zip and unzip. Everything included is listed explicitly in the deployment guide, because a build image that quietly accumulates packages is a liability rather than a convenience.

No credentials by design: this image ships with no GitHub token and no runner registration of any kind, and that is a deliberate security decision rather than an omission. A runner registration token is short lived and specific to your repository or organisation, and the credentials it is exchanged for grant the holder the ability to pick up your jobs. An image that carried either would let anyone launching it join your continuous integration. So the runner service is installed but intentionally left disabled, and it is gated so that it cannot start until you have registered it. On first boot the instance generates a unique runner name for itself and writes the registration instructions to a root only file, so several of these images can join one organisation without colliding.

Getting started takes one command. Generate a registration token in your repository or organisation settings, run the configuration command shown in the instructions file on the VM, then enable the service. Your runner appears in your GitHub settings and starts accepting jobs. cloudimg engineers can help you plan runner groups and labels, scale to a fleet, harden the execution environment, wire up caching and container jobs, and keep the runner version current after purchase.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.