Custom GitLab runners without running the fleet

A custom GitLab runner pays off once your pipeline spends more time compiling than waiting. If you build C++, Rust, Android apps or a game engine on GitLab CI, the default hosted runner is a small Linux VM, and each step up in size burns compute minutes faster. cirunner.dev gives you a managed GitLab runner with more cores and memory, x86 or ARM, and a GPU if you need one. You keep GitLab, your .gitlab-ci.yml and your CI/CD variables. We run the machines.

Where GitLab.com hosted runners stop fitting

GitLab-hosted runners on GitLab.com bill compute minutes, and the Free tier includes 400 a month. The default Linux machine type is small. Free namespaces can move up one size; the large and extra-large types need Premium or Ultimate, and GitLab applies a higher cost factor to them, so a bigger machine eats your quota at a multiple of the base rate. Arm64 hosted runners exist with fewer sizes.

A two-minute website build never notices any of this. Your team notices when a clean build of a C++ monorepo takes 40 minutes, when the linker runs out of memory, when Gradle starts cold on each job, or when tests need a GPU. You start splitting jobs to fit the machine, when you wanted a machine that fits the job.

What a GitLab self-hosted runner involves

GitLab documents its runner in detail, and the work adds up:

• Install the gitlab-runner binary, create the runner record in GitLab and register the machine with a runner authentication token (glrt-). GitLab turned the legacy registration tokens off by default in 17.0.
• Pick an executor. Docker on one VM gets you started. GitLab runner autoscaling means the docker-autoscaler or instance executor with a fleeting plugin and a cloud instance group, or the Kubernetes executor through the Helm chart and a cluster autoscaler.
• Build and patch the VM image, tune concurrent and limit in config.toml, set up a distributed cache in S3 or GCS, and keep the runner version current.
• Debug the autoscaler when jobs sit in the queue on a Friday evening.

Our GitLab CI custom runners guide walks through each of these steps if you prefer to run the fleet yourself.

How a managed GitLab runner from cirunner.dev works

1. In GitLab, create a project runner (Settings > CI/CD > Runners) or a group runner (Build > Runners). Select Run untagged jobs and copy the glrt- token GitLab shows.
2. Paste the token into cirunner.dev and pick the machine: cores, memory, x86 or ARM, a GPU if you need one, and a base image.
3. In the project's Settings > CI/CD > Runners, turn off instance runners. For a group runner, you can turn them off for the whole group instead.

Your pipeline does not change. GitLab sends untagged jobs to any runner that accepts them, and once the instance runners are off, ours is the only one left.

Want only the heavy jobs on the bigger machine? Give the runner a tag such as cirunner, leave Run untagged jobs off and keep instance runners on. Then add tags: [cirunner] to the compile jobs. Lint and small tests stay on GitLab's hosted runners.

Each job gets a fresh VM: we start it, run that one job on it and destroy it afterwards. A build cache persists between jobs, so you keep warm dependencies and compiler caches without inheriting leftover state from the previous job. You pay per compute minute while jobs run and nothing while the queue is empty. Jobs on project and group runners do not count against your GitLab.com compute minutes, and that includes ours.

GitLab.com hosted runners vs. your own fleet vs. cirunner.dev

	GitLab-hosted runners	Your own runner fleet	cirunner.dev
Machine size	Fixed machine types, larger ones on Premium and Ultimate	Whatever you provision	Bigger machines than hosted runners, picked per runner
Billing	Compute minutes with a cost factor per size	Cloud bill plus your team's hours	Per compute minute while jobs run
Isolation	Fresh VM per job	Depends on your executor and max_use_count	Fresh VM per job, destroyed afterwards
Autoscaling	GitLab handles it	You run docker-autoscaler or Kubernetes	We scale with your queue
Build cache	Restored over the network on each job	You configure and pay for it	Persists between jobs
Upkeep	None	Images, upgrades, on-call	None on your side

Who bigger GitLab CI runners are for

A good fit if:

• Your jobs compile C, C++, Rust, Android/Gradle, a game engine or CUDA code, and they get faster with more cores and memory.
• You hit out-of-memory kills, timeouts or long queues on hosted runners.
• Your team has no one with time to own a runner fleet.

Not a fit if:

• Your pipeline finishes in a few minutes on the default hosted runner. Keep using it.
• You already run a fleet that works and have people to maintain it.

FAQ

Is there a managed GitLab runner service?

Yes. cirunner.dev runs custom GitLab runners for you on GitLab CI. The service is in early access and we onboard teams in small batches. Join the early access list and tell us what you build.

How do I set up GitLab runner autoscaling?

On your own infrastructure, use the docker-autoscaler executor with a fleeting plugin and an AWS Auto Scaling group, Google Cloud managed instance group or Azure VM scale set. Set max_use_count = 1 for one job per VM. On Kubernetes, use the Helm chart with a cluster autoscaler. The setup guide has working configs. With cirunner.dev, scaling with the queue is our job.

Do GitLab custom runners use compute minutes?

No. Only jobs on GitLab-hosted instance runners count toward the compute minutes quota on GitLab.com. Jobs on your project or group runners, including ones we run for you, keep running after the quota is used up.

Do I have to change .gitlab-ci.yml to use custom runners?

No. Register the project or group runner with Run untagged jobs selected and turn off instance runners in Settings > CI/CD > Runners. GitLab then sends every job to your runner. You only edit .gitlab-ci.yml if you want tags to route some jobs elsewhere. GitHub Actions differs here: you change runs-on in each workflow. CircleCI needs a resource_class in the config.

Can I mix hosted runners and a bigger runner in one pipeline?

Yes. Tags decide per job. Give your cirunner.dev runner a tag and leave Run untagged jobs off, so untagged lint and small test jobs stay on hosted runners. Tag the compile and integration jobs. Use the configurator to size the machine.