BuildJet Is Shutting Down. What Should GitHub Actions Teams Do Next?

BuildJet just announced they’re shutting down ↗. Their reasoning:

“The gap we set out to fill has largely closed, and we’ve decided to focus our efforts elsewhere.”

They deserve credit — BuildJet was early to the idea that GitHub Actions runners could be faster and cheaper, and they proved there was real demand for it.

But I think their read on the market is wrong. The gap hasn’t closed. GitHub’s larger runners are still expensive, still limited in configuration, and still missing features like proper Docker layer caching or fine-grained hardware selection. What’s actually happened is that the “just resell runners cheaper” model stopped working. The teams who care about CI performance need more than that.

What actually matters when replacing BuildJet

If you’re migrating off BuildJet, don’t just find another hosted runner service and call it a day. The questions worth asking:

Can you pick exact hardware per job? CPU, RAM, disk, architecture, GPU — not just S/M/L/XL t-shirt sizes.
How fast is caching, really? Not “we support caching” — what’s the actual throughput on a 2GB cache restore?
Does Docker layer caching work natively? If you’re building containers in CI (and most teams are), this alone can cut minutes off every run.
Are arm64 runners actually fast? Or just available?
What does it cost at your real volume? Not the marketing page estimate — your actual workload.

How RunsOn compares

RunsOn takes a different approach than BuildJet did. Instead of running shared infrastructure, RunsOn launches runners directly in your own AWS account. You get the performance and cost benefits of EC2 without managing the orchestration yourself.

Here’s what that means in practice:

Pick any runner shape. Every job can specify its own CPU, RAM, disk size, architecture, and whether it needs a GPU. No predefined tiers — you describe what you need in the runs-on label, and RunsOn spins up the right EC2 instance.

→ Runner labels and configuration · GPU runners

Caching is genuinely fast. RunsOn stores caches in S3 within your own account, co-located with your runners. Large cache restores that take 30+ seconds on GitHub-hosted runners finish in a few seconds.

→ Cache benchmark · Caching docs

Docker layer caching just works. No external services, no workarounds. RunsOn supports native Docker layer caching so repeated image builds pull from local layers instead of rebuilding from scratch.

→ Docker caching docs

Fast machines on both x64 and arm64. RunsOn uses modern EC2 instance families (Graviton for arm64, latest-gen Intel/AMD for x64) that consistently outperform GitHub-hosted and BuildJet runners in CPU benchmarks.

→ CPU performance benchmark

Up to 10x cheaper. Since runners launch in your AWS account — and you can use spot instances — costs drop dramatically compared to any hosted runner service. The savings compound fast at scale.

→ Pricing · Spot instance guidance

Migrating from BuildJet

The migration is straightforward. You don’t need to rewrite your workflows — just swap the runner labels.

# Before (BuildJet)
runs-on: buildjet-4vcpu-ubuntu-2204

# After (RunsOn)
runs-on: runs-on=${{ github.run_id }}/runner=4cpu-linux-x64

A reasonable approach:

Install RunsOn in your AWS account (takes ~10 minutes with CloudFormation).
Configure the GitHub App for the repos you want to migrate.
Pick one high-volume workflow and switch its runner label. Compare queue time, build time, and cost.
Roll out to the rest once you’re satisfied.

If you hit issues: Troubleshooting guide.

The bigger picture

BuildJet shutting down doesn’t mean third-party runners are dead. It means the “cheaper hosted runners” pitch alone isn’t enough anymore. Teams want performance, control over their infrastructure, and costs that scale predictably.

That’s exactly what RunsOn is built for. If you’re evaluating alternatives: