GitLab Dedicated stops asking you to run the runners

The first time I inherited a self-hosted GitLab runner fleet, I spent a whole afternoon reading Terraform trying to figure out who owned the AMI. Nobody did. Somebody had built it in 2022, somebody else had bumped the runner binary during a hotfix, and every few weeks a pipeline would fail because the instance type had drifted out of the auto-scaling group's spot-availability window. Nothing was broken. Nothing was ownable, either.

That is the itch GitLab is scratching with hosted runners for GitLab Dedicated. On the single-tenant, managed GitLab tier, you no longer have to provision, patch, build and scale your own runner fleet. GitLab pitches it around agentic workflows driving pipeline volume up, but honestly, it is the same tax every team has been paying for years, just louder now.

What actually changed

Dedicated is GitLab's single-tenant managed tier, the option regulated teams reach for when they need one instance, one data boundary, and someone else's hands on the control plane. Runners were the odd one out. You bought a managed GitLab and then went off to run the compute yourself, which meant an entirely separate cloud account, image pipeline and on-call rota just for the box that ran your jobs.

Hosted runners close that gap. GitLab now handles the runner fleet on the same trust boundary as the instance. The announcement I have does not commit to a public runner-size matrix, GPU or ARM availability, or a pricing shape, so I am not going to invent one for you. The load-bearing claim, and the one that matters for the on-call rotation, is that the runners are somebody else's problem now.

Why the runner tax was so heavy in the first place

Runners are the least glamorous piece of a CI platform and the piece that fails loudest. They are long-lived, stateful, hold secrets, and get patched every time an upstream image ships a CVE. Autoscaling groups need budgets, spot preemption needs retries, disks fill up in ways your dashboards do not predict, and the runner binary itself moves faster than most teams' internal AMI cadence.

Layer on the new pattern of agent-driven jobs (an LLM opening a handful of PRs at 2am, each triggering a full matrix build) and the peak-to-median ratio on your fleet is worse than it has ever been. Static capacity is expensive. Elastic capacity is a full-time job. Neither is the work your team was hired to do, and neither shows up on a roadmap slide as a feature.

How the other vendors carve up the same problem

Every hosted CI has to draw a line between hosted compute and bring-your-own compute, and the line lands somewhere different in each product. GitHub Actions offers hosted runners across Linux, Windows and macOS, larger runners for CPU or RAM-hungry jobs, and self-hosted plus Actions Runner Controller for teams that need to sit inside a VPC. CircleCI exposes tiered resource classes for hosted jobs and a self-hosted runner as an escape hatch for the edge cases. Buildkite goes the other way and treats bring-your-own agents as the core model. You own the compute, they own orchestration, and there is no hosted-runner story on offer. Jenkins stays fully self-hosted, with controllers, agents, plugins and patches all yours to keep alive. Buddy (buddy.works) runs hosted pipelines by default and lets you point at your own Kubernetes targets when a job needs to land inside your network, which is worth a look if your team is small and would rather not be in the runner-ops business at all.

If your compliance story genuinely requires that no build byte ever leaves a VPC you control, Buildkite or self-hosted Jenkins is still the better fit than any hosted-runner offering. A single-tenant hosted runner is a real compromise, not an equivalent to running the metal yourself, and it is honest to say so.

What I am watching next

Two things. First, how far the Dedicated runner matrix stretches over time, because agentic workflows are already asking for ARM, GPU and Windows in the same repo. Second, whether "single-tenant" holds all the way down the stack, or whether the runner pool ends up sharing something under the hood that a security review team will want to ask about. Give me a week with the runbook and I will have opinions.