Depot: /dev/kvm Not Available (KVM Acceleration)
The error "Failed to open the device kvm: No such file or directory" on Depot runners is expected: Depot GitHub Actions runners do not expose /dev/kvm.
Per Depot's troubleshooting docs, Depot GitHub Actions runners do not expose /dev/kvm, so workloads needing KVM hardware acceleration (nested virtualization, some emulators, Android emulator) will hit an error like "Failed to open the device kvm: No such file or directory". The documented fix is to move that job to Depot CI sandboxes. Attributed to depot.dev/docs/github-actions/troubleshooting.
Why /dev/kvm is missing
Depot's standard GitHub Actions runners do not expose the KVM device, so anything requiring hardware-accelerated virtualization cannot open /dev/kvm. This is a documented property of the runners, not a misconfiguration on your side.
The documented fix: Depot CI sandboxes
Per Depot's docs, migrate the KVM-dependent job to Depot CI sandboxes, where /dev/kvm is enabled by default. Depot CI is a separate execution environment in Depot's platform intended for workloads like this. Fix: run the KVM-needing steps in a Depot CI sandbox rather than on the standard runner.
When the real problem is flaky failures, not setup
If your Depot jobs are picked up and fast but still fail intermittently on out-of-memory kills, disk-full errors, or registry timeouts, no runner-speed tuning removes that class of failure. Latchkey is also a drop-in managed runner reached by a runs-on label swap, but it is built around self-healing CI: it detects, diagnoses, fixes, and retries transient and mechanical failures automatically, and lists up to 58% lower per-minute cost than GitHub Actions. If troubleshooting keeps landing on flaky re-runs, it is worth piloting one workflow on Latchkey next to Depot and comparing.