Resources

Engineering at
Manage Runners

How we build Manage Runners, and practical guides to operating GitLab runners on Hetzner.

Two nights of burst runners next to one 12-slot runner: on the first night bursts are deleted and bought again around 23:00 and midnight; on the second, with lighter load at that time, there is no rebuy then, and the first-wave queue is 134 job-minutes instead of 301.

Burst runners for our Renovate nights

A case study from our own self-hosted GitLab: why Renovate only merges at night, how that turns CI into bursts, what Manage Runners burst runners did with them on the first night, and the two settings we changed for the second.

Read Article

Diagram: one GitLab runner with an anchor server and two burst servers in your Hetzner project, all registered as runner managers with the same token; Manage Runners decides from the free job slots they report and creates or deletes burst servers through the Hetzner API.

Engineering 14 Min Read

How autoscaling works for GitLab runners on Hetzner

An engineering look at how Manage Runners autoscales a GitLab runner: burst runners that share its token, decisions from free job slots, scale-in at the end of a paid Hetzner hour, graceful draining, and the guards that keep the number of servers bounded.

Read Article

Servers created before this change keep Docker Engine 28, whose last Engine release was in November 2025, and the dind default image docker:28-cli until they are replaced; new and recreated servers get Docker Engine 29 with docker:29-cli and reject clients below API 1.40.

Engineering 6 Min Read

Runners move to Docker 29: what changes for your CI jobs

New Manage Runners servers now get Docker Engine 29, and the dind executor's default image is docker:29-cli. What changes, which jobs can break because of Docker 29's minimum API version, and how to check yours.

Read Article

Diagram: runner servers in your Hetzner project, the Manage Runners control plane that manages them through the Hetzner API, and your GitLab, which the servers register with and take jobs from; the control plane calls GitLab only with the runner token.

Engineering 14 Min Read

How Manage Runners works: GitLab runners on replaceable Hetzner servers

An engineering look at how Manage Runners runs GitLab runners in your own Hetzner Cloud project: the runner lifecycle, why some changes replace the server, why pausing deletes it, and how locks and idempotency keys keep operations consistent.

Read Article

Engineering atManage Runners

Burst runners for our Renovate nights

How autoscaling works for GitLab runners on Hetzner

Runners move to Docker 29: what changes for your CI jobs

How Manage Runners works: GitLab runners on replaceable Hetzner servers

Engineering at
Manage Runners