Buildkite vs Blacksmith for CI on GitHub

By Kaveh Alemi·Latchkey

Buildkite vs Blacksmith is not two runner vendors, it is a runner vendor against a CI platform: Blacksmith keeps your GitHub Actions workflows and changes one label, while Buildkite replaces them with its own pipeline definitions and charges $30 per active user a month before a job runs. Choose Blacksmith if you are staying on Actions and want it cheaper, and Buildkite if you want an orchestrator that can run agents inside your own infrastructure.

Blacksmith is a drop-in for GitHub-hosted runners. Your workflow files, actions, secrets and matrix stay exactly as they are; you install a GitHub App and change runs-on. The product is compute, and the price is a single published rate per platform.

Buildkite is a CI platform. You define pipelines in .buildkite/pipeline.yml, and jobs run either on Buildkite-hosted agents or on agents you run yourself, which is the model it is genuinely known for. The compute is billed per vCPU-minute, but the platform is billed per active user, and on a team of any size the seat line is the bigger number.

Every cell below was read from the vendor's own public pricing or documentation page on 20 September 2026. Where a vendor does not publish a number, the cell says "not published" instead of carrying a guess.

Blacksmith, Buildkite and Latchkey side by side (read 20 September 2026)

These are not the same purchase

Every other comparison in this section is between two products that do the same job at different prices. This one is not, and pretending otherwise is how teams end up six weeks into a migration they did not need.

Blacksmith changes where your jobs execute. Buildkite changes what defines them. If you move to Buildkite, your uses: steps, your composite actions, your reusable workflows, your GITHUB_TOKEN permissions model and your matrix syntax all need rewriting, and the marketplace actions you depend on have no equivalent. That can be entirely worth it if you want an orchestrator with dynamic pipeline generation and agents inside your own VPC, and it is a very expensive way to get a lower per-minute rate.

Speed

Not benchmarked yet; the runner benchmark report will replace this section. We have not run the same workload on these runners ourselves, and until we have, there is no number here worth quoting.

What you will find elsewhere is each vendor's own figure, measured on a workload the vendor chose. Those numbers are not wrong, but they are not comparable to each other, and none of them is your repository. The cheap way to get a real answer is to point one slow job at each candidate for a week: runner selection is per job, so three jobs in the same workflow file can run on three providers, and the Actions run log gives you the timings for free.

Cost: 20 engineers, the same month

Per-vCPU-minute pricing makes Buildkite look cheap until you multiply. A 2 vCPU agent at $0.004 per vCPU-minute is $0.008 a minute, which is twice Blacksmith's 2 vCPU rate; and then the seats arrive. Here is the usual month, 10,000 Linux minutes at 2 vCPU plus 2,000 macOS minutes, for a team of 20.

Two notes on the arithmetic, because per-vCPU-minute pricing is easy to misread. Buildkite's included allowance is 4,000 vCPU minutes on Pro, and 10,000 minutes on a 2 vCPU agent is 20,000 vCPU minutes, so 16,000 of them are billable at $0.004. Its macOS M4 Medium is 6 vCPU at $0.02 per vCPU-minute, which is $0.12 a minute, roughly double GitHub-hosted and half as much again as Blacksmith.

The seat line is the point. At 20 engineers it is two thirds of the Buildkite bill and it does not fall when your CI gets faster, which inverts the usual optimisation: on Buildkite, making builds cheaper barely moves the invoice. That is a reasonable model for a platform you use as your orchestrator, and a poor one if you wanted cheaper GitHub Actions runners. Latchkey is not free of this either: the $273 above carries a $49 Scale plan and fifteen extra seats, and its 6,000 included minutes are not netted off the compute line.

Reliability

Buildkite is the only product on this page with retries in the box: retry: automatic on a step, configured by you, optionally scoped to an exit status. That is genuinely more than Blacksmith offers, and it is worth understanding what it is not. A blind retry re-runs a command without knowing why it failed, so it also retries the failures that will never pass, and it will happily burn three attempts on a job that is out of disk.

Blacksmith publishes a 99.9% SLA as an Enterprise plan feature and no figure otherwise. Its capacity model is per repository with the GitHub App installed, which means a repository using the labels without the app can under-provision the pool for everyone.

The diagnostic middle ground is the reason the failure pages here exist: a retry helps when the cause was a coincidence, and nothing but a fix helps when the cause was no space left on device or a missing shared library.

When to choose Blacksmith

• You are staying on GitHub Actions and want the same workflows to cost less. This is the whole case and it is a strong one.
• You do not want a per-seat line on your CI invoice, because your headcount grows faster than your build minutes.
• You need Windows runners from the same vendor: Buildkite has no hosted Windows agent.
• You want actions/cache to get faster with no edits to any workflow file.

When to choose Buildkite

• You want agents inside your own infrastructure with the orchestration managed for you. This hybrid model is what Buildkite is for and no managed runner vendor offers it.
• You have outgrown what Actions YAML can express and want pipelines generated dynamically at run time.
• Your builds are long and few, so per-vCPU-minute metering to the second with no rounding beats a per-minute rate.
• Your team is small enough that seats are not the dominant line: the Free plan covers 5 users and 2,000 Linux vCPU minutes a month.

Switching: the exact diff

This is the part most comparisons gloss over. Moving to Blacksmith is a one-line change to an existing file. Moving to Buildkite means a new file in a different language, plus agent configuration, plus reimplementing whatever the marketplace actions were doing for you.

# Blacksmith: edit the file you already have
 jobs:
   build:
-    runs-on: ubuntu-latest
+    runs-on: blacksmith-4vcpu-ubuntu-2404
     steps:
       - uses: actions/checkout@v7
       - run: npm ci && npm test

# Buildkite: a new file, and actions/checkout has no equivalent
# .buildkite/pipeline.yml
+steps:
+  - label: "test"
+    command: "npm ci && npm test"
+    agents:
+      queue: "default"
+    cache:
+      paths: ["node_modules"]
+      size: "20g"

The verdict

If you are on GitHub Actions and the question is cost, this is not a close call: Blacksmith halves the per-minute rate of a comparable Buildkite hosted agent, adds no seat fee, and the migration is one line you can revert in a minute. Buildkite is a good product being asked the wrong question here. Its case is architectural, not financial: a real orchestrator, dynamic pipelines, retries in the box, and agents running inside infrastructure you control, none of which a managed runner vendor can offer. If that is what you want, the $30 per active user is the price of the platform and the compute rate is a rounding error; if it is not, you are paying a platform fee to solve a compute problem. Neither product detects why a job failed and repairs it, so on both you keep paying for the re-runs.

Frequently asked questions

Related guides

References

• Buildkite pricing, seats, agents and hosted compute
• Buildkite hosted agents: Linux instance shapes
• Buildkite hosted agents: cache volumes
• Blacksmith pricing
• Blacksmith runner instance types
• GitHub Actions documentation