You get GitLab Runner on Ubuntu 24.04 LTS (long-term support), installed, enabled and ready to register with your GitLab. Docker is set up for the Docker executor, so once you register with a runner token from GitLab.com or your self-managed GitLab, the VM runs your CI/CD (continuous integration and delivery) jobs without any manual install.

Who it's for

Teams on GitLab.com or self-managed GitLab that want runners in their own Azure subscription
Pipelines that need private network access, a VM size you choose, or tools you install yourself
Platform teams that want a repeatable, patched runner image instead of hand-built hosts

What's included

GitLab Runner 19.4.1 from GitLab's own package repository, pinned to that release (the build fails if any other version is installed), as an enabled system service that starts on every boot
Docker from Ubuntu's package archive, with the runner's service account in the docker group, ready for the Docker executor (each job runs in a fresh container)
The runner's service account has no sudo (administrator) rights
UFW (Ubuntu's host firewall) on, allowing only SSH in: the runner connects outbound to GitLab and needs no open ports

After deployment

No password is created. The runner authenticates outbound with a runner authentication token: create a runner in your GitLab project, group or Admin area and copy its token (it starts with glrt-).
SSH in and run GitLab Runner's register command with sudo, giving your GitLab URL, that token and the docker executor. sudo cat /etc/motd shows the exact command, and so does our setup guide.
The service is already running, so once registered the runner appears in GitLab and picks up jobs. The older registration-token flow is deprecated by GitLab; use the authentication token.
Or register without signing in to the VM: add the VM tag GitlabToken when you deploy (plus GitlabUrl for a self-managed GitLab; it defaults to GitLab.com). First boot registers the runner with that token and waits for your GitLab to confirm it; if registration fails, it says so in the login message and tries again at the next boot. Remove the GitlabToken tag afterwards, because anyone with Reader access to the VM can read its tags.
Allow inbound SSH (22) only from your own addresses; the runner itself needs no inbound ports.

Why this image

Install, service, Docker and permissions done for you, so registering with your token is the only step left
Ubuntu security updates applied at build time; no credentials or machine keys baked into the image
Each image build is deployed to a test VM and checked: service enabled, Docker running, and the register command accepting the authentication-token option
Get started with the step-by-step guide at www.dcassociatesgroup.com/support (GitLab Runner page)

How it runs on Azure

A Generation 2 VM image that supports Trusted Launch (Azure's Secure Boot and virtual TPM security-chip protection). It runs in your own subscription and VNet (virtual network), so jobs can reach private resources there; recommended sizes start at Standard_D2as_v5. Charges are billed through your Azure subscription; see Plans + Pricing.

GitLab Runner on Ubuntu 24.04 LTS

durch Derek Coleman & Associates Corporation