CI runners + Terraform runs
Your tests and your infrastructure, on one timeline
Fast GitHub Actions runners and OpenTofu runs on one platform. One meter, one bill, and a single view of everything a commit set in motion. Pay for the compute you used — not per seat, not per resource.
One line for CI. A hostname for infrastructure. We open the pull request for you.
What we can prove
Three numbers, with the working shown
$0.004 a minute against their $0.006, and 1.3× to 2.2× faster on the same 2 vCPU shape — so the same builds cost $0.015 here against $0.038 there. The rate is the smaller half of it; finishing sooner is the rest, and this market bills whole minutes, so every minute saved is a whole minute.
Medians of the cold track, cross-provider benchmark, over the rounds both providers completed. Every round links to the GitHub run that produced it on /pricing.
Layer-cache and sticky-disk storage are $0.50/GB-month, billed on what you actually use rather than what you reserved. The Actions cache is included and never metered.
Every figure read from billing_rates, and proved on a real draft invoice by apps/web/scripts/verify-addon-billing.mjs.
A test suite and a terraform apply draw from the same allowance at the same rate, because they are the same thing: minutes on a sized machine. One bill, one number to forecast.
1 run-minute = one minute of a 2 vCPU / 8 GiB machine.
The speed multiple above is measured, not modelled — which is why it took until August to appear. Three open-source projects at pinned commits, built with their own CI commands on every provider we currently benchmark, 4 times a month at a different hour each time. Times are the whole job, read from GitHub's own API rather than reported by the runners, so nobody times themselves. Every round on the pricing page links to the run that produced it, the machine each provider gave us is named, and the cache state is stated: none, on any row, ours included. Re-run it yourself. Everyone else's is modelled.
One timeline
The apply and the tests that preceded it, on one screen
One commit. Two test jobs and a production apply, joined by the SHA that caused them. When a deploy goes wrong at 4pm, the run that let it through is the row above it — not a different tab, a different vendor and a different bill.
A CI vendor and a Terraform platform, run separately, can't show you this. A CI vendor sees your tests and stops at the merge. A Terraform platform sees your infrastructure and has no idea what produced it. We run both, so the causal chain survives — and so does the bill, which arrives once, in one unit, for both.
One meter
You pay for compute you actually used
$0 per organisation per month, including 3,000 run-minutes, then $0.0040 a run-minute above it. A card is required to start. No per-seat charge — invite everyone. No per-resource charge — your estate can be as large as it likes.
What we deliberately do not bill you for
Queue wait. Sandbox cold start. Control-plane API calls. State reads and writes. The clock starts when your engine process starts and stops when it exits, so none of these has a process running to measure.
Provider downloads from our mirror happen during terraform init, which is your engine running — so they are inside the run minute, like everything else init does. What we never do is add a line for them: no bandwidth charge, no per-request charge, and the mirror is there to keep the download short rather than to bill it.
Both lists exist because a minute-based meter has an obvious hazard: if the platform is slow, we get paid more. Every second of latency we introduce is on our side of the line, and every second we remove costs us money. The one place that argument is weaker is the mirror: a provider download is inside your run minute, so we run our own and keep it close rather than asking you to take the timing on trust.
Feature parity
What matches, what we add, and what we do not have yet
Your workflows do not change. Same YAML, same actions, same secrets, same logs in the GitHub UI — you change the runner label and everything else carries on working.
- Your existing workflow files
One label changes. Nothing else. - actions/cache
Drop-in. We serve it ourselves, in Europe, where every job runs. - Secrets, environments, OIDC
Handled by GitHub, untouched by us. - Status checks and branch protection
Reported back the same way. - Matrix builds, reusable workflows, composite actions
- Job logs in the GitHub UI
Plus ours, which are searchable. - One clean VM per job
Its own virtual machine, which no other job uses, destroyed after. Never reused.
- $0.004/min at 2 vCPU
Against GitHub's $0.006 for the same size — and 1.3× to 2.2× faster on it, so the build itself costs about 39% of theirs. - Docker layer cache that persists across runs
Including RUN --mount=type=cache contents. - The same bill as your Terraform runs
- macOS and Windows runners
GitHub has both. We are Linux x64 today. - ARM64
Planned. GitHub has it now. - GPU runners
Not on our roadmap. - Larger runners above 16 vCPU
The largest runner on sale today has 16 vCPU. - Queryable log search and monitors
Being built. Blacksmith has both today; GitHub has neither. - SSH into a running job
Planned. - GitHub Enterprise Server
Cloud only.
The third column is the one worth reading. Every platform comparison you have seen lists only the first two, which is why none of them help you decide. If something in that column is load-bearing for you, we would rather you found out here than three weeks into a migration.
Where we actually differ
Including the rows where we are simply level
A comparison table that wins every row is not a comparison, it is a brochure. Here is where we are genuinely ahead, and where a competitor or your own hardware matches us.
| Capability | runners.io | CI vendors | Terraform platforms | Self-hosted |
|---|---|---|---|---|
| CI runs and infrastructure runs on one timeline Requires running both. CI vendors, Terraform platforms, and self-hosted setups don't. | Yes | No | No | No |
| One meter across both | Yes | N/a | N/a | No |
| Billed per resource under management HCP Terraform charges for the size of your estate, whether or not you touch it. | Never | N/a | Yes | No |
| Per-seat pricing | Never | No | Varies | No |
| EU region available today Blacksmith's region selector offers US West only; the rest are marked Soon (Aug 2026). | Yes | Not yet | Yes | Yes |
| State diff, rollback and recovery window HCP Terraform's states screen is a flat list of version IDs. | Yes | N/a | No | No |
| Cache hit rate, not just cache size Per-repository hit rate and trend, in the dashboard. | Yes | No | N/a | Build it |
| Its own virtual machine per job, destroyed after Genuinely equal. A virtual machine no other job uses, never reused between jobs. | Yes | Yes | Yes | Depends |
| Someone else runs it at 3am | Yes | Yes | Yes | No |
Getting here
We open the pull request. You review it.
Connect your GitHub organisation, pick a repository, and we open a draft pull request that changes the runs-on lines and nothing else. Its own checks run on our runners, so you see the move work before you merge; your other builds stay where they are until you do, and reverting is the same button any other PR has.
- 01Connect GitHub
You choose which repositories we can see. - 02We open a draft pull request
The runner labels change. Nothing else in your workflows does. - 03Review the pull request
Merge it, or close it and nothing has changed.