Migrating from Actuated to Latchkey: Self-Hosted microVMs vs Managed Runners
Actuated gives you Firecracker microVM isolation on hardware you own and operate. Latchkey gives you fully managed, self-healing runners with no servers to run. This is the honest trade-off, and how to move if managed is the better fit.
Actuated (actuated.com) is a self-hosted CI system: you install its agent on your own bare-metal or nested-virtualization servers, and every GitHub Actions job runs in a fast-booting Firecracker microVM with VM-level isolation and native Arm support. That gives you strong isolation and control over your own hardware, and you operate the servers. Latchkey takes the opposite approach: it runs your GitHub Actions on fully managed runners reached by a one-line runs-on swap, adds self-healing CI so transient and mechanical failures retry automatically, and leaves you no servers to provision, patch, or keep online. Here is how they compare and what migrating looks like.
At a glance
| Capability | Actuated | Latchkey |
|---|---|---|
| Model | Self-hosted agent on servers you own | Fully managed runners |
| Isolation | Firecracker microVM per job (strong) | Isolated per job (managed) |
| Servers to provision and operate | Yes (bare-metal or nested-virt) | None |
| Arm / Arm64 support | Yes (native, on Arm hosts) | Yes (managed) |
| Self-healing CI (auto-retry transient failures) | No | Yes |
| Setup | Register org, provision server, install agent | One-line runs-on label swap |
| Best known for | microVM isolation on owned hardware | Self-healing + managed runners |
What Actuated is genuinely good at
Actuated is a strong choice when isolation and control matter most. Each job runs in its own Firecracker microVM that boots in about a second and is destroyed after the build, which its docs position as stronger isolation than container-based runners, with native support for sudo, Docker, and Kubernetes without Docker-in-Docker workarounds. Because you run it on your own bare-metal or Arm hosts, you keep data on hardware you control and can get native Arm64 builds without emulation. If owning the hardware and the isolation boundary is a requirement, Actuated is built for that.
What changes when you move to Latchkey
The main thing you give up with Actuated is that you operate the servers: provisioning KVM-capable hosts, patching them, watching for offline agents, and sizing the fleet for concurrency. Latchkey removes that entirely. It is fully managed, so there are no servers to run, and it adds self-healing CI: out-of-memory kills, disk-full errors, registry timeouts, and other transient or mechanical failures are detected and retried automatically instead of failing the pipeline. It also reports up to 58% lower per-minute cost than GitHub-hosted runners and includes AI build optimization. If your goal is low-ops managed CI rather than owning the isolation boundary, that is the trade you are making.
How migration works
- Keep your existing workflows; only the runs-on line changes.
- Swap Actuated labels such as
runs-on: actuated-4cpu-16gbfor the Latchkey runner label on one workflow first. - Run that pipeline on Latchkey and compare wall-clock time, cost, and re-run rate against Actuated.
- Because both use standard GitHub Actions, there is no new CI platform to learn and no lock-in either way.
The verdict
If owning the hardware and microVM isolation boundary is the point, Actuated is a solid fit and worth keeping. If you would rather not operate servers at all and want pipelines that recover from flaky failures on their own, Latchkey is the stronger fit. You can pilot Latchkey on a single workflow and compare against your Actuated builds before deciding.