Press enter or click to view image in full size
If you’ve spent any time staring at slow CI runs on GitHub Actions, you know the pain: minutes tick away while runners spin up and tests crawl.
We’ve been chipping away at this for a while, constantly tweaking caching and optimizing job dependencies. But we recently hit a ceiling that came down to the simplest piece of infrastructure: the runners themselves.
Even when you pay for beefier GitHub hardware, per-minute pricing adds up quickly — and the default GitHub runners may still not keep up with how fast teams like us want to iterate.
The goal was simple: keep all the goodness of GitHub Actions (YAML workflows, integrations, secrets, triggers), but run them on hardware and tooling that gives you better performance per dollar. Hence we started to use Blacksmith as a drop-in replacement for GitHub’s hosted runners.
Benefits
Here’s what we found when we adopted Blacksmith:
- Significant speedups — Blacksmith runs Actions on high-performance machines with better throughput than GitHub’s default runners and even faster than their dedicated runners with the same hardware configuration, so builds and tests finish noticeably faster.
- Faster runs, lower bills: Blacksmith advertises ~2× faster execution and ~50% cheaper per‑minute cost than GitHub hosted runners, which in practice can cut your CI bill by up to ~75%. Your mileage may vary but we are seeing good improvements.
- Plug‑and‑play adoption: For most workflows, you only need to swap the
runs‑onlabel to a Blacksmith runner — no major config rewrites. - Better observability: You get deeper insights into pipeline performance and failures rather than the opaque logs you typically see in GitHub Actions.
Beyond the Cost-Per-Minute: The Hidden Factors
Startups and smaller CI providers don’t have the decades of uptime and SRE experience that GitHub itself has built up. Public status trackers do show occasional service warnings or outages reported for services such as Blacksmith, just like any modern SaaS. And it’s not like that GitHub does not experience outages as well.
That doesn’t mean these providers are flaky by default but it does mean you need to think about operational risk: how often does a CI provider go down? What’s your fallback? And how does that compare to simply accepting slower builds on a hyper‑scale provider?
For teams thinking about this, don’t ignore security and compliance either. CI runners execute arbitrary code and often have access to sensitive data, so the underlying platform needs to meet your security bar. In our case we were comfortable because the runner provider we chose publishes compliance details like SOC 2 Type II and standard data protection certifications, and runs jobs in isolated microVMs so that state isn’t shared across workflows.
Conclusion
Cutting down run times and CI costs means fewer context switches, faster PR cycles, and more predictable velocity. If you’re evaluating third‑party runners, there isn’t a single “right” choice — it’s a tradeoff between faster feedback, lower CI costs, and how much operational responsibility you want to shoulder for another service.
There’s a whole space of third-party runners out there (BuildJet, WarpBuild, Ubicloud, self-hosted options, etc.), and the right choice depends on your workload and priorities. But if you’re on GitHub Actions today and want an easy way to bump throughput without a big migration, Blacksmith or similar providers are worth trying.
Appendix
Just as I was about to post this article I had received an email from GitHub:
With this change, GitHub is introducing a $0.002 per-minute platform fee for all GitHub Actions usage, regardless of where jobs run. Going forward, CI costs will have two components:
- Compute costs (paid to whoever runs your runners, e.g. Blacksmith)
- A GitHub platform fee, charged per minute of Actions usage
If cost is the primary reason you are evaluating third party runner providers it may make sense to make a comparison. In our case, I expect the third party runner to still be cheaper overall.