Skip to content

company

BuildJet shut down. Here is what that means for managed CI.

A competitor exiting the category is worth taking seriously rather than spinning. Here is our honest read on why BuildJet closed and what it says about managed runners.

Jess Okonkwo · Co-founder · 2026-04-14 · 7 min read

On 6 February 2026 BuildJet announced it was shutting down its GitHub Actions runner service. On 31 March it stopped running jobs. Their migration guide told customers to move back to GitHub-hosted runners.

GitHub has made substantial improvements — faster hardware, larger runner options, and native ARM runner support. The gap we set out to fill has largely closed.

BuildJet's shutdown announcement

It would be easy to write a post about how this is great news for us. It is more useful to take the argument seriously, because a lot of it is correct.

What BuildJet got right

GitHub genuinely has improved. Larger runners exist. Native arm64 exists on paid plans. If your entire pitch was "the same thing, but with more vCPUs", that pitch is now much weaker than it was in 2022. Any vendor whose only differentiator is machine size should be nervous.

What we think they got wrong

Machine size was never the interesting part. The parts GitHub has not closed are the ones that dominate real pipelines:

  • The 10 GB per-repository cache cap, and the throttled bandwidth to it
  • No persistent Docker layer cache without shipping it to a registry and back
  • Branch-scoped caching, so every new pull request starts cold
  • No per-job resource metrics, so nobody can tell an undersized runner from a slow one
  • No bring-your-own-cloud option for teams with data residency requirements

In our own measurements, cache behaviour explains more CI wall-clock time than CPU count does on most pipelines. That is the gap, and it has not closed.

The uncomfortable question

If you are evaluating managed runners right now, the correct question to ask any vendor — us included — is what happens to you if we shut down.

Our answer: the integration surface is one line. Migrating in takes five minutes and migrating out takes five minutes, because runs-on is the only thing you changed. We publish the exact reverse diff on every migration page. That is deliberate. A platform that is hard to leave is a platform that has to be good, and we would rather be the second thing.

Your next build could be twice as fast, at half the price

Start free. Migrating away is the same one line, and we publish that diff too.