Migrate from Depot to Latchkey: GitHub Actions Runners
Depot and Latchkey are both fast, drop-in, cheaper managed GitHub Actions runners. If your priority is fewer flaky re-runs, moving from Depot to Latchkey is a one-line runs-on change.
Depot GitHub Actions runners are a drop-in replacement for GitHub-hosted runners: according to Depot's docs you adopt them in any job by changing the runs-on label. Depot markets its "Ultra Runners" as up to 3x faster than GitHub-hosted, running on 4th Gen AMD EPYC "Genoa" CPUs (~30% faster than GitHub's native runners per Depot) with an integrated distributed cache. Latchkey is also a drop-in managed runner reached by a runs-on swap, but it is built around self-healing CI: transient and mechanical failures are detected, diagnosed, fixed, and retried automatically. This page is an honest look at what Depot does well, why some teams move, and exactly how to switch.
Depot vs Latchkey at a glance
| Capability | Depot | Latchkey |
|---|---|---|
| Drop-in via runs-on label | Yes | Yes |
| Cheaper than GitHub-hosted | Yes (Depot: ~half the cost of GitHub-hosted) | Yes (up to 70% lower per minute) |
| Built-in caching | Yes (integrated distributed cache, per Depot) | Yes (dependency + Docker layer) |
| Docker build integration | Strong (BuildKit builders next to runners) | Standard Docker layer caching |
| Self-healing CI (auto-fix + retry transient failures) | No | Yes |
| Runner types | Intel x86, ARM, macOS, Windows, GPU (GPU on Business plan) | Managed Linux runner sizes |
| Best known for | Fast CPUs + strong distributed cache + Docker builds | Self-healing reliability + low cost |
What Depot is
Depot provides managed GitHub Actions runners that drop into your existing workflows. Per Depot's docs, you switch a job by changing its runs-on label, so your YAML, actions, and steps stay the same. Depot runs on 4th Gen AMD EPYC "Genoa" CPUs and ships an integrated distributed cache that Depot says delivers up to ~1000 MiB/s upload/download and about 10x faster caching with no config changes. If you also use Depot for Docker image builds, its BuildKit builders run next to the runners. See depot.dev/docs/github-actions/overview.
What Depot is genuinely good at
Credit where it is due: Depot's distributed cache and its tight integration with remote Docker builds are real strengths. For container-heavy pipelines where cache hit rate and BuildKit build speed dominate your CI time, Depot is a strong choice, and its fast Genoa CPUs help CPU-bound steps too. Note that Depot's well-known "up to 55x faster builds" tagline refers to its remote Docker build product, not its runners.
Why some teams move to Latchkey
The most common reason is reliability. Fast runners still fail on transient and mechanical issues such as out-of-memory kills, disk-full errors, and registry timeouts, and re-running those jobs costs money and time. Latchkey adds self-healing CI: it detects, diagnoses, fixes, and retries those failures automatically, so flaky builds stop failing your pipeline. Latchkey also lists up to 70% lower per-minute cost than GitHub Actions, zero queue time, and AI-powered build optimization. If your pain is flaky re-runs and cost rather than raw Docker-build throughput, that is the switch that pays off.
How to migrate (step by step)
- Pick one workflow to pilot, ideally one that suffers occasional flaky failures.
- On Depot today, that job's runs-on points at a Depot runner label. Swap it back or across in a single line: change runs-on to your target managed runner label.
- On Latchkey the change is symmetric: set runs-on to the Latchkey runner label. No new CI platform, no infrastructure, no YAML rewrite.
- Run the pilot and compare wall-clock time, cost, and how many transient failures self-healed instead of going red.
- Roll the label change out to remaining workflows once you are satisfied, keeping Depot on any Docker-build-dominated jobs if it wins there.
The verdict
If your CI is dominated by Docker image builds and cache hit rate, Depot is a solid choice and worth keeping for those jobs. If your bigger problem is flaky re-runs and per-minute cost, migrating to Latchkey is a one-line runs-on change that adds self-healing reliability on top of low-cost managed runners. Pilot it on a single workflow and compare against your real builds. Always verify current Depot pricing at depot.dev/pricing, since vendor pricing changes.