Docs Benchmarks Pricing Calculator Changelog Blog Install in 10 min
githubactionsbuildjetalternativesself-hosted

BuildJet Is Shutting Down. Here’s What I’d Replace It With

BuildJet is discontinuing service. If you need a replacement, don’t just swap one hosted runner vendor for another. Decide what you want from CI, then pick the model that matches it.

RunsOn Team RunsOn Team
· 5 min read
BuildJet Is Shutting Down. Here’s What I’d Replace It With

BuildJet just announced it’s 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 that market.

But I think their read on the market is wrong. The gap has not closed. GitHub’s larger runners are still expensive, still blunt instruments, and still missing things teams actually care about once CI becomes a real line item: better cache performance, native Docker layer caching, predictable hardware, and the ability to choose the machine instead of a t-shirt size.

What changed is simpler: “hosted runners, but a bit cheaper” stopped being enough. Once teams start looking closely at CI, they want either the easiest possible managed service, or they want real control over performance, caching, networking, and cost. The middle ground got weaker.

Don’t just swap one hosted runner for another

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 multi-GB 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 homepage calculator. Your actual workload.

Those questions matter more than feature tables. Most runner vendors can say “Linux, arm64, larger runners, autoscaling.” That is not the hard part. The hard part is whether your CI gets faster, cheaper, and easier to reason about after the migration.

Why RunsOn is different

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 the machine you actually want. 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 launches the matching EC2 instance.

→ Runner labels and configuration · GPU runners

Caching is actually fast. RunsOn stores caches in S3 in your own account, close to the runners using them. Large restores that are painful on GitHub-hosted runners drop to a few seconds instead of tens of seconds.

→ Cache benchmark · Caching docs

Docker layer caching works the way people expect it to. No extra service, no weird workaround. Repeated image builds can reuse layers instead of rebuilding everything from scratch.

→ Docker caching docs

The hardware is better. RunsOn uses modern EC2 instance families: Graviton on arm64, current Intel and AMD families on x64. That shows up directly in our CPU benchmarks.

→ CPU performance benchmark

The cost model is cleaner. Since runners launch in your AWS account, and you can use spot instances, you pay for compute instead of paying someone else’s markup on top of compute. That matters a lot once CI is running all day.

→ Pricing · Spot instance guidance

The migration path is simple

You do not need to redesign your workflows. In most cases, you change the runner label and keep moving.

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

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

A practical rollout:

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

If you hit issues: Troubleshooting guide.

What BuildJet shutting down actually says

BuildJet shutting down does not mean third-party runners are dead. It means the easy pitch is dead. “We are GitHub Actions runners, but cheaper” is not a durable position anymore.

Teams that care about CI enough to switch providers usually want one of two things:

  • the simplest possible managed service, with all the tradeoffs that come with shared infrastructure
  • runners in their own account, on hardware they choose, with pricing tied directly to the cloud bill

I think the second model is stronger, especially for teams with serious CI volume, security requirements, or strong opinions about performance.

If you’re replacing BuildJet, that’s the decision I would make first. Everything else follows from it.

If you want to evaluate RunsOn specifically: