Depot vs Self-Hosted GitHub Actions Runners
Self-hosted runners give the lowest raw compute price but you own the ops. Depot is managed and drop-in with a built-in cache. Here is the honest split.
Some teams weigh Depot's managed runners against running self-hosted runners on their own EC2, Kubernetes, or bare metal. Both are legitimate; they trade cost against operational burden. This page compares them fairly and notes where self-healing changes the calculus. Depot facts attributed to depot.dev/docs; verify current pricing at depot.dev/pricing.
Where self-hosted wins
Self-hosted gives the lowest per-unit compute price and total control: specific hardware, strict network placement, and data residency. It fits teams with a platform group that can operate a runner fleet at scale.
Where Depot wins
Depot removes the ops. Per its docs, adoption is a runs-on label change, the distributed cache needs no configuration, and BuildKit builders sit next to the runners for Docker builds. You get managed, drop-in runners at about half the cost of GitHub-hosted (per Depot) without owning scaling, patching, or cleanup.
The gap neither closes
Neither self-hosted nor Depot self-heals transient failures. Out-of-memory kills, disk-full errors, and registry timeouts still cost re-runs. Latchkey is a drop-in managed runner (also a runs-on swap) built around self-healing CI that detects, diagnoses, fixes, and retries those failures automatically, and lists up to 58% lower per-minute cost than GitHub Actions.