Migrate BuildJet to Tenki Runners: Labels, Cache, Costs

BuildJet for GitHub Actions stopped running jobs on March 31, 2026. If your workflows still reference buildjet-* runner labels, they're failing right now. This guide covers exactly what you need to change to move from BuildJet to Tenki Runners: runner label mappings, cache migration steps, workflow YAML diffs, and a cost comparison to make sure you're not paying more.

What happened to BuildJet

On February 6, 2026, BuildJet announced it was shutting down. New signups were blocked immediately, concurrency subscriptions became free for existing users, and pay-as-you-go billing continued until the hard cutoff on March 31, 2026. After that date, BuildJet runners stopped accepting jobs entirely.

Their explanation was straightforward: GitHub's own runners had closed the performance gap. That's partially true. GitHub does offer larger runners and native ARM support now. But it glosses over the fact that GitHub's larger runners are expensive, and "fast enough" isn't the same as "fast." As RunsOn noted in their post-mortem, the real issue was that "hosted runners, but a bit cheaper" stopped being a durable value proposition. Teams either want the simplest managed experience or they want real control over hardware, caching, and cost.

If you were on BuildJet, the question now is where to go. Falling back to GitHub-hosted runners is the path of least resistance, but it also means paying more per minute for less hardware. Tenki Runners offer a drop-in replacement that keeps the cost savings and actually improves build speed.

Runner label mapping: BuildJet to Tenki

The biggest migration task is swapping runner labels in your workflow YAML. BuildJet used labels like buildjet-4vcpu-ubuntu-2204. Tenki uses a different naming convention: tenki-standard-{size}-{cpu}c-{ram}g. Here's the direct mapping for x64 runners:

BuildJet Label                     → Tenki Label                            Specs
─────────────────────────────────────────────────────────────────────────────────────
buildjet-2vcpu-ubuntu-2204         → tenki-standard-small-2c-4g              2 vCPU / 4 GB
buildjet-4vcpu-ubuntu-2204         → tenki-standard-medium-4c-8g             4 vCPU / 8 GB
buildjet-8vcpu-ubuntu-2204         → tenki-standard-large-8c-16g             8 vCPU / 16 GB
buildjet-16vcpu-ubuntu-2204        → tenki-standard-large-plus-16c-32g       16 vCPU / 32 GB
buildjet-32vcpu-ubuntu-2204        → Contact Tenki (hello@tenki.cloud)       32 vCPU / custom

A few things to note. BuildJet allocated more RAM per vCPU than Tenki does at most tiers. A BuildJet 4-vCPU runner came with 16 GB; the equivalent Tenki runner gives you 8 GB. For most CI workloads (compilation, testing, Docker builds) that's plenty. If you have memory-heavy jobs, test on the Tenki runner first and reach out to their team for a custom configuration if 8 GB isn't enough.

Tenki also offers tenki-standard-autoscale, which dynamically allocates compute based on what the job actually needs. BuildJet had no equivalent. If your jobs vary in resource requirements across a matrix, autoscale might save you money compared to always requesting your biggest runner.

For BuildJet's ARM runners (buildjet-*-arm), Tenki doesn't currently list ARM-specific SKUs on their public pricing page. Your options are to fall back to GitHub's native ARM runners (ubuntu-24.04-arm) for those specific jobs, or contact Tenki directly about ARM availability.

Workflow YAML changes

Here are the concrete diffs for common patterns. You can also use Tenki's built-in Migration Wizard, which detects your current runner labels and generates a pull request with the replacements. But if you prefer doing it manually or need to understand what's changing, these examples cover the most common cases.

Basic build job

jobs:
  build:
    # Before (BuildJet)
    # runs-on: buildjet-4vcpu-ubuntu-2204
    # After (Tenki)
    runs-on: tenki-standard-medium-4c-8g
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

Docker build

jobs:
  docker:
    # Before (BuildJet)
    # runs-on: buildjet-8vcpu-ubuntu-2204
    # After (Tenki)
    runs-on: tenki-standard-large-8c-16g
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: myapp:latest

Matrix job

jobs:
  test:
    strategy:
      matrix:
        node: [18, 20, 22]
    # Before (BuildJet)
    # runs-on: buildjet-2vcpu-ubuntu-2204
    # After (Tenki)
    runs-on: tenki-standard-small-2c-4g
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - run: npm ci && npm test

ARM jobs (hybrid approach)

Since Tenki's public SKU list doesn't include ARM yet, use GitHub's native ARM runners for those jobs and Tenki for x64:

jobs:
  build-x64:
    runs-on: tenki-standard-medium-4c-8g
    steps:
      - uses: actions/checkout@v4
      - run: make build

  build-arm:
    # GitHub native ARM runner (replaces buildjet-4vcpu-ubuntu-2204-arm)
    runs-on: ubuntu-24.04-arm
    steps:
      - uses: actions/checkout@v4
      - run: make build

Cache migration

If you were using buildjet/cache@v4, that action is dead. The good news: BuildJet's cache was designed to be a drop-in replacement for actions/cache@v4, so the migration is a one-line swap:

steps:
  - uses: actions/checkout@v4
  # Before (BuildJet cache)
  # - uses: buildjet/cache@v4
  # After (standard GitHub cache — works on Tenki runners)
  - uses: actions/cache@v4
    with:
      path: ~/.npm
      key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}

Expect cold caches on your first runs. BuildJet stored its caches on its own infrastructure. Those caches are gone. When you switch to Tenki, your first workflow run will be a cache miss. By the second run, actions/cache will have populated GitHub's cache storage and your hit rates should return to normal.

BuildJet offered 20 GB of cache per repository per week. Tenki's free tier includes 10 GB of cache storage. For most repositories, that's fine. If you were routinely hitting BuildJet's 20 GB limit, keep an eye on eviction behavior during the first week and adjust cache keys if needed.

One difference worth flagging: BuildJet ran its own cache infrastructure close to its runners, which gave it fast restore times for large caches. Tenki runners use GitHub's standard cache backend. Restore times for small-to-medium caches (under 1 GB) should feel the same. For very large caches, you might see slightly different throughput, but Tenki's faster runner hardware tends to compensate.

Cost comparison

BuildJet's pricing was $0.002 per vCPU per minute across all tiers. Tenki's pricing is $0.0015 per CPU per minute on the Developer tier, with 1,700 free minutes per month. Here's how they compare at each tier:

Runner Size     BuildJet (was)    Tenki         GitHub Hosted    Tenki Savings vs BuildJet
──────────────────────────────────────────────────────────────────────────────────────────
2 vCPU          $0.004/min        $0.003/min    $0.006/min       25%
4 vCPU          $0.008/min        $0.006/min    $0.012/min       25%
8 vCPU          $0.016/min        $0.012/min    $0.022/min       25%
16 vCPU         $0.032/min        $0.024/min    $0.042/min       25%

At every tier, Tenki is about 25% cheaper than BuildJet was, and roughly 50% cheaper than GitHub's standard larger runners. On top of that, Tenki's benchmarks show 30-67% faster build times compared to GitHub-hosted runners depending on the workload. Faster builds mean fewer minutes consumed, so the effective savings compound.

The free tier gives you 700 minutes one-time on signup, plus 1,700 free minutes per month on the Developer tier. That's enough to migrate and validate a handful of workflows before committing to paid usage.

Common migration pitfalls

Runner image differences. BuildJet used custom Ubuntu images that were similar to, but not identical to, GitHub's runner images. Tenki runners use standard Ubuntu-based images. If your workflows relied on a tool that was pre-installed on BuildJet's image but isn't on Tenki's, you'll see failures on the first run. The fix is simple: add an explicit install step. If you were using setup-* actions (setup-node, setup-python, etc.), those work identically on Tenki and you won't notice any difference.

Hardcoded runner labels in reusable workflows. If your org has reusable workflows or composite actions that hardcode buildjet-* labels, search across all repos before you assume migration is done. A quick grep -r 'buildjet' .github/ in each repo will catch stragglers.

Concurrency limits. BuildJet's default was 64 concurrent AMD vCPUs. Tenki allows up to 40 concurrent jobs on the free and developer tiers. If you were pushing BuildJet's concurrency hard, verify that Tenki's limit works for your peak usage. Enterprise plans offer higher limits.

The GitHub App installation. Tenki requires installing its GitHub App on your organization. If you selected "Only select repositories" during installation, make sure every repo that needs Tenki runners is included. Workflows will silently fall back to GitHub-hosted runners (and their pricing) if the repo isn't connected.

Memory-sensitive builds. As mentioned in the label mapping section, BuildJet gave more RAM per vCPU. If you're building large Rust projects or running resource-heavy integration tests that touched 16 GB+ on a BuildJet 4-vCPU runner, you may need to bump up one tier on Tenki or request a custom config.

Step-by-step migration checklist

1. Create a Tenki account at app.tenki.cloud/auth/registration. No credit card required.
2. Install the Tenki GitHub App on your GitHub org. Grant it access to the repos you want to migrate.
3. Audit your workflows. Run grep -r 'buildjet' .github/ across all repos to find every reference.
4. Use the Migration Wizard or swap labels manually using the mapping table above.
5. Replace buildjet/cache@v4 with actions/cache@v4 in any workflow that used BuildJet's cache action.
6. Start with one high-traffic workflow. Compare wall-clock time, queue time, and cost against your BuildJet baseline.
7. Roll out to remaining workflows once you're confident in the results.
8. Uninstall the BuildJet GitHub App from your org settings once migration is complete.

The whole process takes under an hour for most teams. The only thing that takes real time is waiting for cache to warm back up, and that's automatic after the first run per workflow.