Blacksmith Firecracker microVM Boot and Isolation
Blacksmith's fast, clean start comes from ephemeral Firecracker microVMs. Each job gets a fresh VM that boots in under 3 seconds.
According to Blacksmith's docs, jobs run on ephemeral Firecracker microVMs that boot in under 3 seconds on bare-metal gaming CPUs. Ephemeral means each job starts from a clean VM, so state does not leak between jobs unless you deliberately persist it via a cache or sticky disk.
Why ephemeral microVMs matter
- Fresh isolation per job reduces the stale-runner and leftover-state problems common on long-lived self-hosted runners.
- Sub-3-second boot, per the docs, keeps startup overhead low.
- Persistence is opt-in: Docker layer cache and sticky disks carry state across otherwise clean VMs.
Nested virtualization note
Per the docs, x64 Linux runners support nested virtualization for KVM-dependent jobs and emulator-based tests, while ARM Linux does not. If your job needs nested virtualization, target an x64 Linux runner.
Clean start still meets transient failures
A fresh VM avoids state-leak bugs but not transient failures like registry timeouts or OOM kills. Latchkey's self-healing retries those automatically on top of clean, managed runners.
If you want failures to recover on their own
Blacksmith is a strong choice when raw runner speed and per-core performance are your priority. If your recurring pain is instead flaky, transient failures that force manual re-runs, Latchkey is worth a look: it runs your GitHub Actions on managed, drop-in runners and adds self-healing CI, so out-of-memory kills, disk-full errors, and registry timeouts are detected and retried automatically. You can pilot it on a single workflow with a one-line runs-on change and compare against your real builds.