DEV Community: Cyrille Sepele

We Cut Our GitLab Build Time by 59% With One Change

Cyrille Sepele — Sat, 16 May 2026 20:58:07 +0000

You know the feeling. You push a one-line fix, open the pipeline, and watch your runner spend two minutes downloading node_modules. Again. The same node_modules it downloaded ten minutes ago. On the last push. That was also a one-line fix.

Shared runners have the memory of a goldfish. And you're paying for it in build minutes.

The problem: shared runners forget everything

GitLab's shared runners are ephemeral by design. Each job gets a clean machine. Great for isolation. Terrible for your afternoon.

Every single job:

Docker pulls your base images from scratch
npm install / pip install / bundle install downloads every dependency again
Docker-in-Docker builds re-download every layer, every time
Your test suite can't reuse compilation artifacts from the previous run

"But there's the cache: keyword!" Sure. It uploads a tarball to object storage and downloads it on the next run. In practice:

Uploading and downloading a 500MB archive takes its own sweet time
Cache misses are silent and frequent (good luck debugging that)
Docker image layers? The cache: keyword can't help you there. You end up in a rabbit hole of registry-based workarounds and BuildKit inline caching

For small projects, whatever. For anything with real dependencies or Docker builds, you feel it on every push.

What happens when the cache actually sticks around

When your runner lives on a dedicated machine that doesn't self-destruct after each job, things get better fast:

Docker layer cache just works. Your FROM node:20 isn't pulled every run. Your RUN apt-get install layer is already built. Docker's native caching does what it was designed to do. No config, no tricks.

The /cache volume persists between jobs. GitLab runners support a local cache directory mounted as a Docker volume. On a shared runner, that volume dies with the VM. On a dedicated machine, it stays. Your cache: directive in .gitlab-ci.yml writes to local disk instead of round-tripping through S3.

Docker-in-Docker benefits the most. If you're building container images in CI, a persistent Docker daemon means every subsequent build reuses layers from previous builds. No registry hacks. No BuildKit configuration. Just Docker doing its thing.

None of this is magic. It's just what happens when your runner isn't destroyed after every job.

Proof: same job, same project, very different numbers

Here's our build app job:

Same job. Same codebase. 59% faster. And that's a warm cache. The first run is comparable to a shared runner. Every run after that benefits from Docker layers and dependencies already sitting on disk.

The queue time drop matters too. Shared runners serve everyone on GitLab.com, so your job waits in line behind strangers. A dedicated runner picks up your job immediately because it has nothing better to do.

Now multiply that by 50 pipeline runs a day.

"I'll just self-host a runner."

You can. And if you have a dedicated ops person, or you genuinely enjoy debugging Docker daemon crashes on a Saturday morning, go for it.

For everyone else:

Provisioning the server and keeping it updated
Installing and configuring Docker + GitLab Runner
Monitoring disk space (those Docker layers add up quietly)
Rotating tokens, managing SSH keys
Getting paged at 2 am because the runner went offline

The cache benefits of a persistent runner are real. The Sunday afternoon you lose figuring out why /var/lib/docker filled up the disk is also real.

What we built instead

This is why RocketRunner exists.

You get a dedicated VM. Real hardware, not a shared slice. Docker and the GitLab runner are installed and registered with your project automatically. Because it's your machine running your Docker daemon, all caching works natively.

You don't configure any of this. It's a side effect of having a runner that doesn't get thrown away after every job.

What this looks like in your `.gitlab-ci.yml`

Typical Node.js setup:

build:
  stage: build
  image: node:20
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
  script:
    - npm ci
    - npm run build

On a shared runner, npm ci downloads everything every time. The cache round-trip to S3 often takes longer than the install itself. Ironic.

On RocketRunner, that cache lives on a local volume. First run populates it. Second run reads from disk. Done.

For Docker builds, the gap gets embarrassing:

build-image:
  stage: build
  image: docker:24.0.5
  services:
    - docker:24.0.5-dind
  script:
    - docker build -t myapp:latest.

Shared runner: pulls docker:24.0.5, pulls every layer in your Dockerfile, every time. A 3-minute build that should take 20 seconds. You go make coffee. You come back. It's still pulling.

RocketRunner: Docker daemon is already running. Base images are cached. Unchanged layers are skipped. It finishes before you can alt-tab away.

When this matters (and when it doesn't)

Good fit:

Projects with Docker-in-Docker builds
Monorepos with large dependency trees
Teams running 20+ pipelines per day
Anything where npm install takes longer than your actual tests

Probably overkill:

Small projects with minimal dependencies
Pipelines that only run linters or simple scripts
Teams running fewer than a handful of pipelines per week

Try it

RocketRunner starts with a 48-hour free trial. Setup takes about 2 minutes. Connect your GitLab account, pick a server size, choose a region, and your runner is live.

Smallest plan runs at $0.018/hr with a $10.59/month cap. Most teams pay between $1-10/month.

If your pipelines spend more time downloading dependencies than running your actual code, a persistent cache might be all you need.

Cheap Dedicated CI/CD Runners for GitLab: Shared vs Self-Hosted vs Rented

Cyrille Sepele — Sat, 09 May 2026 21:01:17 +0000

If your GitLab pipelines are slow, flaky, or eating into your SaaS bill, you've probably looked at your runner setup. There are three ways to run GitLab CI jobs, and the cost difference between them is bigger than most people realise.

The shared runner problem

GitLab's shared runners are the path of least resistance. You don't set anything up, and they work. Until they don't.

The issues show up gradually:

Jobs queuing behind other users' workloads
Inconsistent build times
No control over the hardware
Shared filesystem state that causes flaky tests you can't reproduce locally
No pipeline caching — every job starts cold, every time
Limited CI minutes on the Free tier (400 min/month on GitLab.com)
Extra minutes cost $10 per 1,000 if you exceed your allowance

If you're running Docker-in-Docker or anything that needs real isolation, shared runners are a constant source of friction.

For a solo project or a weekend hack, shared runners are fine. For a team shipping to production, the unpredictability gets expensive fast.

Self-hosting: more control, more overhead

The obvious answer is to run your own runner on a VPS. Full control, no queuing, dedicated hardware. A Hetzner CX23 (4GB RAM) costs about €3.99/month on paper — hard to beat.

The catch is everything else:

Provision the server
Install Docker and the GitLab runner binary
Register it with your project or group (get the token, run the register command, handle the config)
Keep it updated
Monitor it
Remember to destroy it when you're done, or keep paying for it

The real cost of self-hosting isn't the €3.99/month server. It's the engineer who updates the runner binary when it falls behind, debugs the registration token when it expires, and gets paged when the disk fills up. If that's 30 minutes a month at a $50/hr developer rate, you've already spent more than the server costs.

For a team that already owns and operates infrastructure, this overhead is absorbed. For a solo developer, a startup, or anyone who just wants pipelines to work, it's babysitting you didn't sign up for.

Renting a dedicated runner by the hour

There's a third option that most people haven't considered: renting a dedicated runner, billed hourly, with zero setup.

The model works like this:

You sign in with GitLab
Pick a server size and region
The runner is provisioned and registered with your project automatically. No SSH, no config files
You pay only while the runner exists
Delete it, and billing stops immediately

RocketRunner does this. A Small runner (4GB RAM, 2 vCPUs) costs $0.018/hr, or about $10.59/month maximum if you run it 24/7. Most teams pay far less because they only run it when they need it.

The actual cost comparison

Option	Monthly cost	Setup time	Isolation
GitLab shared runners	Included (with limits)	0 min	None
Self-hosted on Hetzner CX23	~$4.71/month + engineering time	30–60 min	Full
Rented dedicated runner	$0.018/hr (~$1–10/month typical)	2 min	Full

The self-hosted option has the lowest server bill if you run jobs 24/7. But once you factor in the engineering time to set it up and keep it running, renting by the hour is cheaper for most teams.

When renting makes sense

You're a solo developer or small team that doesn't want to maintain infrastructure
You need full VM isolation (Docker-in-Docker, privileged containers, clean state per run)
Your pipeline load is unpredictable, and you don't want to pay for idle compute
You want runners in a specific region (EU or US) for compliance or latency reasons
You're prototyping and want something live in 2 minutes, not 45

The bottom line

Shared runners are free but unreliable. Self-hosting is cheap on paper but comes with hidden ops overhead. Renting a dedicated runner by the hour sits in between: full isolation, no setup, and a cost that scales with actual usage — no engineer babysitting required.

If you've been putting up with slow or flaky GitLab pipelines, it's worth trying a dedicated runner. With a 48-hour free trial and no contracts, the cost of finding out is zero.

Spin up a dedicated GitLab runner in 2 minutes

👉 Get started at rocketrunner.io — card required, no charge for 48 hours.