Skip to content
compiler.dev

BuildJet vs compiler.dev: After the Shutdown

Last updated

BuildJet is no longer an option: it announced on 6 February 2026 that it was shutting down and stopped running GitHub Actions jobs on 31 March 2026. If any workflow of yours still says buildjet-* in runs-on, it is failing or stuck waiting for a runner that will never come. This page explains what BuildJet was, how to replace it, and how compiler.dev compares with the other options. Facts were checked in October 2026 against BuildJet's own site and WarpBuild's migration post.

What BuildJet was

BuildJet sold faster GitHub Actions runners, Linux x64 and ARM, plus its own cache action, buildjet/cache. Its site now shows a notice that BuildJet for GitHub Actions has been shut down. The stated reason, reported by multiple sources, was that the gap it set out to fill had largely closed. New signups were halted when the shutdown was announced, and pay-as-you-go billing continued until the March cutoff.

Because the company is gone, a price comparison is not useful, so the table below is about what you now need to look for in a replacement.

What to compare in a replacement

What BuildJet didcompiler.dev
Linux x64YesYes, 2 to 32 vCPU, default 8 vCPU / 16 GB at $0.012/min
ARM LinuxYesNot offered
macOSNot listedM4 Pro 14-core $0.055/min (early access)
CacheIts own buildjet/cache actionUse standard actions/cache, plus caches on the machine and Nx/Turborepo remote cache
BillingPer minutePrepaid credit, no expiry
Free tierNot applicable200 minute trial, card required
Still operatingNoYes
FallbackNoJobs run on your original runners

The last two rows are the lesson from the shutdown. A runner provider sits in the path of every build, and a vendor that disappears can leave you with broken CI until you fix every workflow. compiler.dev's design limits that risk for its own customers: if its credit runs out or anything fails, jobs run on your original runners, and undoing it is one line. Any provider you choose should have an exit plan that costs you minutes, not days.

Where another provider is the better choice

  • You rely on ARM Linux. compiler.dev has no ARM runners. WarpBuild, Ubicloud and Blacksmith list ARM prices. WarpBuild published a label mapping for BuildJet users, which makes it the most direct drop-in.
  • You want the nearest equivalent. WarpBuild's post maps buildjet-4vcpu-ubuntu-2204 to warp-ubuntu-2204-x64-4x and says most teams finish in under ten minutes.
  • You need a free tier today. Blacksmith lists 3,000 free minutes a month and Ubicloud a $2.50 monthly credit.

Where compiler.dev is the better choice

  • Linux x64 only, and you want the simplest move. One runs-on line, and nothing to configure.
  • You value a fallback after being burned. If compiler.dev has a problem, your own runners pick the jobs up.
  • You want measured full-pipeline results. Our benchmarks show GitHub-hosted vs compiler.dev the headline result is a median 1.5× faster across 18 measured stacks (15 faster, 2 the same, 1 slower). We have no BuildJet numbers and it no longer matters.
  • You want a low risk of lock-in. Prepaid credit never expires and unused credit is refundable on request.

How to migrate

First find every BuildJet reference:

grep -rn "buildjet" .github/

Then replace the runner labels. For compiler.dev:

jobs:
  test:
    # was: runs-on: buildjet-4vcpu-ubuntu-2204
    runs-on: [self-hosted, Linux, compiler-ci]
    steps:
      - uses: actions/checkout@v4
      # was: uses: buildjet/cache@v4
      - uses: actions/cache@v4
        with:
          path: ~/.npm
          key: npm-${{ hashFiles('**/package-lock.json') }}
      - run: npm ci && npm test

Install the GitHub App at app.compiler.dev. Replace buildjet/cache@v4 with actions/cache@v4, as the WarpBuild post also advises, because the BuildJet cache action went away with the service. For cache keys, see the cache key builder.

If you land on WarpBuild instead, the label examples from its post are:

runs-on: warp-ubuntu-2204-x64-4x          # replaces buildjet-4vcpu-ubuntu-2204
runs-on: warp-ubuntu-latest-arm64-2x      # replaces buildjet-2vcpu-ubuntu-2204-arm

How to choose without repeating the mistake

  1. Ask what happens to your builds if the vendor stops. Prefer a design with a fallback to your own runners.
  2. Put the vendor label in one place if you can, for example a reusable workflow, so a future switch is a one-line change.
  3. Do not buy a year of prepaid usage. Prefer credit that does not expire or monthly billing.
  4. Run your real workflow for a few days before you move everything.

Our ranking of runner providers covers the options, and the GitHub Actions alternatives guide is for teams thinking of leaving Actions altogether. If you want to understand why a self-hosted setup stays under your control, read self-hosted vs GitHub-hosted runners.

FAQ

Is BuildJet still available?

No. It announced on 6 February 2026 that it was shutting down, and jobs stopped running on 31 March 2026. Workflows that still use buildjet-* labels fail.

What is the best BuildJet alternative?

It depends on what you used. For ARM and a label mapping, WarpBuild. For the lowest price, Ubicloud. For a fallback to your own runners on Linux x64, compiler.dev. See the provider ranking.

Do I need to change my cache action?

Yes, if you used buildjet/cache. Switch to actions/cache, which works on any runner. Your old cache is gone, so the first run is cold.

What happens to jobs stuck waiting for a BuildJet runner?

They queue until they time out. Cancel them, change the label, and re-run.