How to Migrate from Blacksmith to Latchkey (2026 Guide)
Blacksmith and Latchkey are both fast, drop-in, cheaper GitHub Actions runners. The reason teams evaluate a move is usually reliability: Latchkey adds self-healing so transient failures recover automatically instead of turning into re-runs.
Blacksmith is a strong product. According to Blacksmith, it is a 2x faster drop-in replacement for GitHub-hosted runners: you adopt it by changing the runs-on tag, jobs run in ephemeral Firecracker microVMs that boot in under 3 seconds, and it persists Docker layer caches across runs. If your CI is CPU-bound, Blacksmith is a genuinely good fit. Teams look at Latchkey when their real pain is not raw speed but flaky, transient failures and cost. Latchkey is also a one-line runs-on swap, adds self-healing CI so out-of-memory kills, registry timeouts, and other transient/mechanical failures are detected and retried automatically, and runs at up to 58% lower per-minute cost than GitHub Actions. Because both are standard managed runners, moving between them is a label change, not a migration project.
Blacksmith vs Latchkey at a glance
| Capability | Blacksmith | Latchkey |
|---|---|---|
| Adoption | Change the runs-on tag | Change the runs-on tag |
| Cheaper than GitHub-hosted | Yes (Blacksmith states ~50% lower per-minute) | Yes (up to 58% lower per-minute) |
| Isolation / boot | Ephemeral Firecracker microVMs, boot < 3s | Managed, isolated per job |
| Docker layer cache across runs | Yes (co-located cache, per Blacksmith) | Built-in caching (deps + Docker layer) |
| Raw single-core CPU speed | A genuine strength (per Blacksmith, 50%+ higher single-core vs GitHub-hosted) | Fast managed runners |
| Self-healing CI (auto-retry transient failures) | No | Yes |
| AI-powered build optimization | No | Yes |
| Best known for | Raw speed + Docker layer cache | Self-healing reliability + low cost |
What Blacksmith is and does well
According to Blacksmith, it is the fastest way to run GitHub Actions: a drop-in replacement for GitHub-hosted runners that its docs describe as roughly 2x faster. Runners boot off the same images as GitHub with the same preinstalled dependencies, so most workflows run unchanged. Its documented strengths are real: CPUs with 50%+ higher single-core performance than GitHub-hosted runners, ephemeral Firecracker microVMs that boot in under 3 seconds, and persisted Docker layer caches with co-located cache throughput around 400 MB/s. If your builds are dominated by single-threaded compilation or heavy Docker builds, that combination is hard to beat.
Why some teams move to Latchkey
Speed does not fix flakiness. If your pipeline still goes red on transient failures - an out-of-memory kill, a disk-full error, a registry or network timeout - a faster runner just fails faster, and you pay to re-run. Latchkey is built around self-healing CI: it detects, diagnoses, and fixes those transient and mechanical failures automatically and retries the job, so flaky builds stop failing your pipeline. It pairs that with up to 58% lower per-minute cost than GitHub Actions and AI-powered build optimization. This is a different axis from Blacksmith: reliability and cost rather than raw per-core speed.
Step-by-step migration
- Pick one noisy or expensive workflow to pilot rather than switching everything at once.
- In that workflow, change the runs-on label from your Blacksmith runner tag to the Latchkey runner label. That is the same kind of one-line change you made to adopt Blacksmith.
- Install and grant the Latchkey GitHub App access to the repo or org so jobs get picked up (the same access model as any managed runner).
- Run the pipeline and compare against your Blacksmith baseline: per-minute cost, wall-clock time, and how often transient failures self-heal instead of needing a manual re-run.
- Roll out to more workflows by repeating the runs-on swap. Because nothing else in your YAML changes, you can revert instantly by pointing runs-on back at Blacksmith.
When to stay on Blacksmith
Be honest with yourself about the bottleneck. If your CI is genuinely CPU-bound and Docker-layer-cache heavy, and reliability is already fine, Blacksmith may already be the best tool for the job and there is no reason to switch. Latchkey is the stronger fit when re-runs from flaky failures and per-minute cost are what actually hurt.
The verdict
Blacksmith is a fast, well-built drop-in runner and the right call for CPU-bound, Docker-heavy pipelines. If your pain is flaky re-runs and cost rather than raw speed, Latchkey is a one-line runs-on swap too - try self-healing managed runners on one workflow, keep Blacksmith as your fallback, and compare against your real builds before rolling out.