Depot Alternative: Self-Healing GitHub Actions Runners
Depot is a strong, drop-in managed runner. If your bottleneck is flaky re-runs and per-minute cost rather than Docker-build throughput, a self-healing alternative may fit better.
Depot provides managed GitHub Actions runners you adopt by changing the runs-on label (for example runs-on: depot-ubuntu-24.04, per Depot's docs), plus a distributed cache and remote Docker builds. It is genuinely good at what it does. This page is a fair rundown of where Depot excels and where teams look for an alternative, so you can choose the right tool. Latchkey is one such alternative: also drop-in, but built around self-healing CI. Verify current Depot details at depot.dev/docs and pricing at depot.dev/pricing, since vendor specifics change.
Depot vs a self-healing alternative
| Capability | Depot | Latchkey |
|---|---|---|
| Drop-in via runs-on label | Yes (e.g. depot-ubuntu-24.04) | Yes |
| Cheaper than GitHub-hosted | Yes (Depot: ~half the cost of GitHub-hosted) | Yes (up to 70% lower per minute) |
| Distributed cache | Yes (Depot: 10x faster, up to 1000 MiB/s, no config) | Built-in (deps + Docker layer) |
| Remote Docker builds | Strong (BuildKit builders next to runners) | Standard Docker layer caching |
| Runner types | Intel/ARM/macOS/Windows/GPU (GPU on Business plan) | Managed Linux runner sizes |
| Self-healing CI (auto-fix + retry transient failures) | No | Yes |
What Depot is genuinely good at
Credit where it is due. Per Depot's docs, its runners are drop-in via a runs-on label change, run on fast CPUs (4th Gen AMD EPYC Genoa for Intel, AWS Graviton4 for ARM), and ship an integrated distributed cache Depot markets as up to 10x faster with no config changes and upload/download up to 1000 MiB/s. Its Ultra Runners are marketed as up to 3x faster than GitHub-hosted (Depot attributes this partly to a RAM disk reserving up to 25% of memory). If your CI is dominated by container image builds and cache hit rate, Depot is a strong choice.
Why teams look for an alternative
The usual reason is reliability and cost, not speed. Fast runners still fail on transient and mechanical issues, and re-running those jobs costs money and time. That is the gap a self-healing runner fills. Note: Depot's well-known "55x" figure comes from a Docker-build customer case study (PostHog) and the homepage Docker-build tagline, not its runners, so do not use it to set runner expectations.
Where Latchkey fits
Latchkey is a drop-in managed runner reached by a runs-on swap, built around self-healing CI: it detects, diagnoses, fixes, and retries transient and mechanical failures automatically, and lists up to 70% lower per-minute cost than GitHub Actions. Many teams keep Depot on Docker-build-heavy jobs and move flaky, cost-sensitive workflows to Latchkey. You can run both.
The verdict
If container builds and cache hit rate dominate your CI, Depot is a solid pick and worth keeping for those jobs. If your bigger pain is flaky re-runs and per-minute cost, evaluate a self-healing alternative like Latchkey on one workflow and compare against your real builds. Always verify current Depot pricing at depot.dev/pricing.