Buildkite vs Blacksmith: They Are Not the Same Product
These two are usually compared as if they were competing runner vendors. They are not. Buildkite replaces your CI platform; Blacksmith replaces the machine your existing GitHub Actions workflows run on.
The most common mistake in this comparison is treating it as a like-for-like runner decision. Blacksmith is a drop-in replacement for GitHub-hosted runners: you install a GitHub App, change one runs-on label, and your existing workflows execute on Blacksmith hardware. GitHub Actions remains your orchestrator, your YAML is untouched, and reverting is the same one-line change.
Buildkite is a CI platform. It brings its own pipeline definition, its own orchestrator, its own UI, and a hybrid model where the control plane is hosted and agents can run on your own infrastructure. Moving to Buildkite means rewriting pipelines and changing where your CI lives, which is a different order of decision entirely.
So the real question is not which is faster. It is whether you are replacing a machine or replacing a platform. Standard GitHub-hosted runners are free and unlimited on public repositories, and public repos get 4 vCPU and 16 GB rather than the 2 vCPU and 8 GB private repositories receive. No paid runner beats free, so everything below assumes a private repository past its included minutes.
Buildkite vs Blacksmith at a glance
| Buildkite | Blacksmith | |
|---|---|---|
| What it is | A CI platform | A runner for GitHub Actions |
| Keeps GitHub Actions? | No, it replaces it | Yes, unchanged |
| Adoption cost | Rewrite pipelines, migrate secrets and checks | One runs-on line |
| Reversal cost | A second migration | One runs-on line |
| Hosted compute price | $0.004 per vCPU-minute (Linux) | $0.004/min (Linux x64), $0.0025 (arm64) |
| Seat cost | $30 per active user/month on Pro, plus $3.50 per agent | None |
| Self-hosted agents | Yes, a core part of the model | No, fully managed |
| Free tier | Free plan: 5 users, 2,000 Linux vCPU-min/month | 3,000 minutes/month |
| Distinctive property | Hybrid control plane, runs agents in your infra | Bare-metal gaming CPUs, sub-3-second boot |
| Automatic failure recovery | No | No |
The pricing models are not comparable as printed
Buildkite bills hosted Linux agents per vCPU-minute, so the headline $0.004 is not the price of a runner-minute. A 4 vCPU hosted agent consumes 4 vCPU-minutes per wall-clock minute and therefore costs $0.016/min. Blacksmith bills per runner-minute at a fixed machine size.
| Shape | Buildkite hosted | Blacksmith | GitHub-hosted |
|---|---|---|---|
| ~2 vCPU Linux | $0.008/min (2 x $0.004) | $0.004/min | $0.006/min |
| ~4 vCPU Linux | $0.016/min (4 x $0.004) | $0.008/min | $0.012/min |
| ~8 vCPU Linux | $0.032/min (8 x $0.004) | $0.016/min | $0.022/min |
| Linux arm64, 2 vCPU | Not published separately | $0.0025/min | $0.005/min |
When Buildkite is the right answer anyway
The seat cost buys something real, and for some teams it is worth more than the compute difference.
- You need agents inside your own network or cloud account for data residency, private service access, or hardware you own. Buildkite is built around that; Blacksmith is fully managed and cannot do it.
- You have outgrown what GitHub Actions expresses well: complex fan-out, dynamic pipeline generation, or long-lived multi-stage delivery flows.
- You want one orchestrator across repositories that do not all live on GitHub.
When Blacksmith is the right answer
- Your GitHub Actions workflows are fine and the machine underneath them is the problem.
- Your critical path is single-threaded: compilation, bundling, a single-threaded test runner. Blacksmith cites a single-thread PassMark of 4484, the highest in the category per the independent RunsOn benchmark.
- You want the decision to be reversible. A one-line change you can revert is a fundamentally different risk profile from a platform migration.
- Your builds run on ARM, where the published $0.0025/min is the strongest rate in this comparison.
Switching, and switching back
Every managed runner in this category is selected by the runs-on label, so adoption and reversal are the same one-line edit. That makes a two-week trial on your slowest job a better decision procedure than any amount of modelling.
jobs:
build:
runs-on: ubuntu-latest # GitHub-hosted
# runs-on: latchkey-small # Latchkey
How to evaluate a managed runner honestly
Runner vendors compete on a headline per-minute rate, and the rate is rarely what decides the bill. Measure the whole job, on your own pipeline, before committing.
- Compare at equal machine shape. A cheaper per-minute rate on fewer vCPUs or less RAM is not cheaper per unit of work.
- Check billing granularity. Per-minute rounding costs real money on a wide matrix of short jobs; per-second does not.
- Include queue and boot time. A runner that is cheaper per minute but slower to start can cost more per merge.
- Count your re-runs. If a meaningful share of your runs are retries of a failed job, you are paying for the same work twice at whatever rate you negotiated, and no rate card prices that.
- Verify the free tier is recurring. A one-time credit is not a free tier.
The verdict
These are not substitutes and should not be shortlisted against each other. Decide first whether your problem is the platform or the machine.
If GitHub Actions is working and builds are slow: Blacksmith. It is a one-line, reversible change with no seat cost, and it targets the single-threaded critical path most pipelines actually have.
If you need agents in your own infrastructure, or you have outgrown what Actions can express: Buildkite. Price the seats honestly, because at $30 per active user plus $3.50 per agent the compute rate is rarely what decides the bill.
If you are only comparing them on per-minute cost, note that Buildkite bills per vCPU-minute and Blacksmith per runner-minute, so the printed numbers are not measuring the same thing.