Nx vs Blacksmith

Blacksmith makes your CI machines faster. Nx makes far less work run on them at all, through affected detection, remote caching, and task distribution, the bigger win in a monorepo.

What is Nx?

Nx is a monorepo platform: a task runner, remote caching, distributed CI across machines, e2e test splitting, flaky-task handling, self-healing CI, and editor integration. It layers onto whatever CI provider you already run.

What is Blacksmith?

Blacksmith is a drop-in replacement for GitHub Actions runners. It moves your jobs onto faster bare-metal machines with accelerated dependency and Docker layer caches.

Quick takeaway

Blacksmith and Nx work on different layers:

Blacksmith is a runner provider. Swap the runs-on label and every job runs on a faster machine.
Nx is a monorepo platform. It reads your project graph to skip unaffected tasks, replay cached results, and distribute the rest across machines.

Blacksmith gives a one-time raw-speed bump, and past that there is little more to squeeze. Nx keeps compounding: task distribution, flaky re-runs, and task-level caching, plus it drops the manual matrix and sharding that become the real maintenance cost once simple parallelism stops scaling.

Topic	Nx Cloud	Blacksmith
Model	Task orchestration on any CI provider	Faster runners for GitHub Actions
Remote caching	Content-addressed task cache, shared with local dev	Accelerated `actions/cache` and per-job sticky disks
Distribution	Task-level, dynamically balanced from timing history	Static workflow matrix with manual sharding
Test splitting and flaky tests	Atomizer, flaky re-runs, self-healing CI	Not available
Observability	Task-level cache, timing, and agent utilization analytics	Job-level performance and cost dashboards, log search
Pricing model	Credit-based plans	Per-minute usage billing with a monthly free tier

Model

Blacksmith's pitch is speed per job: ephemeral Firecracker microVMs on high-clock CPUs, fast cache downloads, and its flagship Docker layer caching. Migration is a one-line label change, with a wizard that rewrites your workflows. If your workflows are slow because GitHub's hosted runners are slow, it delivers.

Blacksmith runs whatever your workflow matrix declares, on every push, whether or not the change affected those projects. Nx Cloud starts from the task graph: prune what the change can't reach, replay what already ran, distribute the rest.

Remote caching

Blacksmith transparently accelerates the actions/cache API and offers sticky disks, persistent volumes remounted between jobs, for dependencies and Docker layers. This caching is coarse and manual: you declare which paths to store under a key you compute yourself (path: node_modules, key: ${{ hashFiles(...) }}), so it restores files by key match rather than understanding a task's inputs and outputs. It speeds up restoring state, but a task that already ran with identical inputs still reruns.

Nx Replay caches at the task level and derives the cache key from each task's actual inputs, so there are no paths or keys to maintain. A build or test computed once, on CI or on a developer laptop, replays everywhere else with its terminal output and artifacts, with access-controlled, branch-isolated writes.

Distribution

With Nx, distribution is a single job. nx run-many runs every check, and one --distribute-on line hands tasks to Nx Agents, assigned continuously from historical timing data, with no matrix and no shard count to maintain.

# .github/workflows/ci.yml (Nx)
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: npm ci
      - run: npx nx-cloud start-ci-run --distribute-on="8 linux-medium-js"
      - run: npx nx run-many -t lint test build e2e

Blacksmith is a runner provider, so distribution is on you. Swap runs-on for a faster machine, then hand-write a job per check plus a static matrix to shard slow suites. Each job is a fresh, isolated runner, so every check repeats the checkout and install, and the shard count is fixed before the run, so a slow shard can't hand work to an idle one.

# .github/workflows/ci.yml (Blacksmith)
jobs:
  lint:
    runs-on: blacksmith-4vcpu-ubuntu-2404
    steps:
      - uses: actions/checkout@v5
      - run: npm ci
      - run: npx eslint .
  test:
    runs-on: blacksmith-4vcpu-ubuntu-2404
    steps:
      - uses: actions/checkout@v5
      - run: npm ci
      - run: npx jest
  build:
    runs-on: blacksmith-4vcpu-ubuntu-2404
    steps:
      - uses: actions/checkout@v5
      - run: npm ci
      - run: npm run build
  e2e:
    runs-on: blacksmith-4vcpu-ubuntu-2404
    strategy:
      matrix:
        shard: [1, 2, 3, 4] # shard count fixed before the run, rebalanced by hand
    steps:
      - uses: actions/checkout@v5
      - run: npm ci
      - run: npx playwright test --shard=${{ matrix.shard }}/4

Test splitting and flaky tests

Blacksmith has no test splitting and no automated flaky-test detection or re-running. Its test analytics only report failing tests in PR comments, which neither shortens a slow suite nor stops a flake from failing the build.

Nx Cloud acts on what it detects. Atomizer splits e2e suites into per-file tasks that distribute across agents, flaky task detection retries nondeterministic tasks in isolation instead of failing the pipeline, and self-healing CI proposes verified fixes for real failures.

Observability

Blacksmith provides job-level dashboards: performance and cost per team, run history, global log search, and SSH into live jobs. Nx Cloud's analytics operate at the task level: cache hit rates, per-task timings, and agent utilization breakdowns per run, the data that shows which task to tune when CI slows down.

Pricing model

Blacksmith bills per minute with a free tier. Nx Cloud also has a free tier and usage-based billing, so billing isn't a Blacksmith advantage. The difference is what you get for it: task-level caching, distribution, and flaky re-runs cut CI further than faster minutes alone.

Who should pick which

Nx fits when any of these apply:

Most tasks on most PRs are unaffected or already cached and you want to skip them.
CI time calls for dynamic distribution, e2e splitting, or flaky-task handling.
You want a task cache shared across CI and developer machines, plus task-level analytics.

Blacksmith alone is enough only when:

You want a one-line runner swap and nothing beyond faster machines.
The bottleneck is raw machine speed on a repository small enough to run everything each push.

Nx runs on your existing CI, so you can cut CI time and add distribution without switching runner providers. Nx Agents also run on sized resource classes, so you get faster machines too, not just a one-time raw-speed bump. If you want CI that scales with your team, set up Nx Agents.