Dedicated GitLab CI/CD Runners

// what you get

Runners without the ops

RocketRunner gives your GitLab project or group its own dedicated CI/CD runner on an isolated cloud VM. It is provisioned automatically, registered with GitLab automatically, and billed only for the time it exists. No servers to babysit, no runner config to maintain, no noisy neighbours.

Delete the runner whenever you like. The VM is destroyed and billing stops the same minute. There is no notice period, no minimum term, and nothing left running that you have to remember to go and switch off later.

// the decision

Shared, self-hosted, or dedicated

There are three ways to get CI compute, and the honest summary is that all three work. Shared runners really are zero setup and genuinely fine for a solo project. Self-hosting really is the cheapest line item if you already have a spare machine and do not count your own hours. What separates them is not capability, it is which costs are visible at the moment you choose.

// what dedicated means

One tenant, one machine, one cache

Dedicated is used loosely enough to be worth pinning down. Here it means a virtual machine that exists for your runner and nothing else. Not a container on a pooled host, not a slice of a shared box, not a queue position on a fleet. One VM, one runner, one tenant.

The practical difference shows up in three places. The first is queueing: on GitLab's shared fleet your job waits behind everyone else's, and the wait is invisible until you are watching a deployment. A dedicated runner has one queue and you are the only one in it, so pipeline duration stops depending on what the rest of the world is building this afternoon.

The second is caching. Shared runners start every job cold, which is why so much CI time goes on downloading dependencies you already downloaded yesterday. A dedicated runner keeps its Docker layers and build cache on local disk between jobs. On a repository with a heavy dependency tree that difference is usually larger than any change you could make to the pipeline itself.

The third is what an auditor or a client security reviewer can be told. On a shared runner you cannot say who else used the machine, what ran on it before your job, or where it physically sat. On a dedicated VM you can name the region, state that no other tenant touched it, and show that it was destroyed when you deleted it.

// how it works

Three steps, about 3 to 4 minutes

// running your own gitlab?

Works with self-managed instances too

If you run your own GitLab rather than using GitLab.com, the starting point is different: a self-managed instance ships with no runners at all, so CI does nothing until you supply compute yourself. RocketRunner registers a dedicated runner against your own instance, with the OAuth application living on your GitLab where you can revoke it at any time.

Your instance does need to be reachable over public https, which rules out air-gapped and VPN-only installations.

// where it runs

Pick a region, keep CI near your team

EU

Falkenstein · Nuremberg · Helsinki

US

Ashburn · Hillsboro

// pricing

Billed by the minute, capped monthly

// faq

Frequently asked questions