Has anyone else tried running self-hosted GitHub Actions runners on Lambda MicroVMs? The pricing looks attractive: roughly $0.0042 per minute compared with about $0.005 per minute for a two-vCPU hosted runner, with no 60-second minimum. MicroVMs can run for up to eight hours, start within a few seconds, scale down completely when idle, and still support Docker and other workloads because they are full VMs. I built a Terraform module that handles the setup after manually creating a GitHub App, and it has worked well for several company projects with performance comparable to hosted runners. The main limitations are the ARM64-only architecture and the relatively fixed hardware configuration. I'm especially interested in how this approach compares with spot-based ECS or Kubernetes runners, and how people handle Docker layer caching, image pulls, networking, and interrupted jobs.
3 Answers
The approach makes the most sense when the workloads are compatible with ARM64 and the fixed VM shape is sufficient. For typical tests, packaging jobs, and container builds, a disposable VM gives a clean environment without paying for an always-on runner. Workloads that require x86 binaries, specialized hardware, or persistent local caches would likely be better served by another runner design.
The fairest comparison is probably spot capacity rather than standard hosted pricing. If you already operate an EKS or ECS cluster, spot runners can be dramatically cheaper. But when there is no existing cluster to share, scaling MicroVMs all the way to zero and avoiding a 60-second billing minimum is a strong advantage. The main concern would be Docker layer caching: a fresh VM for every job has to pull the base image and rebuild layers, which can erase much of the per-minute savings.
That’s the tradeoff with spot-based runners: they’re inexpensive when the cluster already exists, but interruptions and maintaining warm capacity add operational complexity.
This is a neat alternative to a larger container-orchestration setup. The short startup time and scale-to-zero behavior are especially useful for projects with irregular build traffic. The cost calculation should include image downloads, artifact transfers, cache storage, and any networking overhead, though. Those extras can matter more than the raw compute price for build-heavy workflows.
Exactly. The compute rate looks excellent, but cache reuse and artifact handling are probably what determine whether it wins for real-world builds.
How do you handle spot interruptions in practice? Do failed jobs simply restart from the beginning, and do you keep spare capacity running to avoid longer startup times?