Migrate from BuildJet to Latchkey: GitHub Actions Runners
BuildJet for GitHub Actions is winding down, so BuildJet workflows need a new home. Because BuildJet is a drop-in runner, moving off it is mostly a one-line runs-on change plus a caching decision.
If you run GitHub Actions on BuildJet, you need a plan. According to BuildJet's shutdown announcement, new signups were halted effective February 6th, 2026 and BuildJet stops running jobs on March 31st, 2026, with BuildJet directing users back to GitHub-hosted runners. The good news: because BuildJet was a drop-in managed runner reached by a runs-on label, migrating is low-friction. This page covers what to change and how Latchkey fits if you want to keep cheaper-than-hosted runners and add self-healing. Verify BuildJet's current dates on their site before you plan the cutover.
What changes when you move
| Concern | On BuildJet | On Latchkey |
|---|---|---|
| runs-on label | e.g. buildjet-4vcpu-ubuntu-2204 | One-line runs-on label swap |
| Runner sizes | 2 to 32 vCPU tiers (per BuildJet) | Managed sizes, no infra to run |
| Cheaper than GitHub-hosted | Yes (BuildJet's original pitch) | Yes (up to ~70% lower per minute) |
| Caching | buildjet/cache action | Built-in dependency + Docker layer |
| Self-healing CI | No | Yes (auto-retry transient failures) |
Step 1: inventory your BuildJet labels
Search your workflows for runs-on: buildjet- to find every job on BuildJet. According to BuildJet's docs the label format is buildjet-<vcpu>-<os>-<version>, for example buildjet-4vcpu-ubuntu-2204, so a grep across .github/workflows catches them all, including ARM variants.
grep -rn "runs-on:.*buildjet" .github/workflowsStep 2: pick a replacement runner
BuildJet's own guidance is to move back to GitHub-hosted runners (ubuntu-latest, or ubuntu-24.04-arm for ARM). That works, but it gives up the cheaper-than-hosted pricing you chose BuildJet for. A managed runner like Latchkey keeps that lower cost with the same one-line swap and adds self-healing on top.
Step 3: handle caching
If you use buildjet/cache, BuildJet's migration guidance is to move to the standard actions/cache@v4. On Latchkey, dependency and Docker layer caching are built in, so most pipelines do not need a separate cache action at all.
What Latchkey adds beyond a like-for-like swap
Latchkey is built around self-healing CI: out-of-memory kills, disk-full errors, and registry timeouts are detected and retried automatically, so flaky jobs stop failing your pipeline. It pairs that with managed runners at up to roughly 70% lower per-minute cost than GitHub Actions, and AI build optimization to trim wasted minutes.
The verdict
The wind-down means every BuildJet job needs a destination. If a plain move back to GitHub-hosted is fine for you, BuildJet documents that path. If you would rather keep cheaper runners and add pipelines that recover from flaky failures on their own, Latchkey is worth a look. You can pilot it on one workflow and compare before cutting over.
Frequently asked questions
How hard is it to migrate off BuildJet?
runs-on change per job plus a caching decision, because BuildJet and Latchkey both attach managed runners to standard GitHub Actions. Verify BuildJet's current shutdown timeline on their site, as vendor dates can change.