Runners for Self-Hosted GitLab

// the missing piece

Self-managed GitLab ships with no runners

You installed GitLab, the CI/CD section is right there in the sidebar, and your first pipeline sat pending until it timed out. Nothing is broken. A self-managed instance gives you the whole CI/CD system and none of the machines that execute it.

GitLab's shared runners belong to GitLab.com. They are a hosted service, not part of the software you installed, and they do not come across when you run your own instance. That is why the runners page on a fresh install is empty, and why every pipeline you write stays queued until you supply compute yourself.

So somewhere between installing GitLab and shipping anything through it, there is a job nobody told you about: find a machine, install GitLab Runner on it, register it against your instance, choose an executor, and then keep that machine alive and patched for as long as you use CI. RocketRunner does that part for you, against your instance, while everything else stays where you put it.

// why it's empty

Two decisions that arrived as one

You run your own GitLab for a reason. A client contract, an auditor's question about where source lives, a policy about company code on someone else's SaaS. Whatever it was, it was almost certainly not a wish to maintain build machines. That part came attached.

It is worth separating them, because they are genuinely different questions. Where the repository lives is what compliance cares about: source, full history, issues, merge requests, access control, backups. That is the system of record, and it is what a data residency clause is written against.

Where builds run is infrastructure. A runner clones a repo, executes a job, reports back, and holds nothing permanently. Most teams answer both questions at once, keep both, and then spend their Tuesdays on the second one. Keeping the instance in-house and renting the compute is a supported combination, not a compromise.

// your options

Install it yourself, build a fleet, or rent one

Every self-hosting team solves this one of three ways. All three work. They differ in how much of your attention they keep asking for after the first pipeline goes green.

Installing one runner on a spare server is genuinely the cheapest option on day one, and for a single project that never changes it may stay that way. The cost shows up later, in upgrades you postpone, disks that fill with old build caches, and the one machine everybody has forgotten how to rebuild.

Building a fleet is the right answer at real scale, and if you already run Kubernetes you probably should. It is a platform project, though, with a platform project's maintenance. Renting sits in between: the isolation of your own machine, none of the lifecycle.

// how it works

Connected to your instance, not ours

The connection runs the same way it does for GitLab.com, except the authorization happens on your server. You stay the identity provider throughout.

The OAuth application lives on your GitLab. You created it, you can see it in your admin area, and you can revoke it there without asking us or waiting for a support ticket. If you would rather not create an application at all, a personal access token works too.

From there the runner behaves like any other runner registered against your instance. It shows up on your runners page, respects your tags, and runs the jobs you point at it. Delete it from RocketRunner and the VM is destroyed and billing stops the same minute.

// when this doesn't fit

What your instance needs, and when to keep self-hosting

Your GitLab has to be reachable from the runner over the public internet, on https, with a valid certificate. That is not a preference, it is how the connection works: the runner polls your instance for jobs and we call your instance's API to register it. Instance URLs that resolve to private or internal addresses are rejected.

That covers most self-managed instances at companies and agencies, which sit on a real domain behind a real certificate. It does not cover an air-gapped instance, a VPN-only instance, or one bound to a private network. If that is you, keep running runners inside your perimeter. No hosted runner service can help, and any that claims otherwise is worth a second look.

The other honest point: a runner clones your source in order to build it. That is true of every runner ever created, including the one you would install yourself. What differs is the machine. A shared runner is multi-tenant, on hardware you did not choose, after work you cannot see. A dedicated runner is a single-tenant VM in a region you picked, used by nobody else, and destroyed on deletion. That is a posture you can describe to a client security review.

// the case this fits best

One runner per client, destroyed when the contract ends

Agencies and consultancies hit this hardest, because the problem repeats per client. Run work for eight clients, several on their own GitLab instances, and self-assembly means eight runner fleets, eight sets of credentials, eight machines to patch, and an uncomfortable question every time an engagement ends about what is still sitting on that box.

One isolated runner per client, billed separately and destroyed at the end of the contract, is a much cleaner story for you and for your client's security review. That kind of isolation is difficult to retrofit and easy to get subtly wrong, which is exactly the sort of thing worth not building yourself.

// pricing

Billed by the minute, capped monthly

Nothing here is tied to your GitLab licence or your seat count, because your instance stays entirely yours. You are paying for a machine and the work of keeping it alive.

// faq

Frequently asked questions