Depot Docker Builds vs Runners: Do Not Confuse the 55x
A frequent mix-up: Depot's eye-catching "55x" number is about remote Docker image builds, not its GitHub Actions runners. Setting the right expectation avoids disappointment.
Depot sells distinct products. Its remote Docker build product accelerates container image builds; its GitHub Actions runners accelerate general CI jobs. The "up to 55x" figure traces to a Depot customer case study (PostHog, cited by Depot as builds cut from 193 minutes to about 3 minutes 26 seconds) and Depot's Docker-build homepage tagline, not to runner benchmarks. Runners are marketed separately as up to 3x faster than GitHub-hosted. This page keeps the two straight.
Where 55x comes from
Depot's "55x" number is a Docker-build result: Depot's PostHog case study describes builds dropping from 193 minutes to roughly 3 minutes 26 seconds, and the homepage advertises up to 40x-55x faster builds. These are container-build figures for the Docker product, not GitHub Actions runner speedups. Do not use 55x to set runner expectations.
What the runners actually claim
Depot markets its Ultra Runners as up to 3x faster than GitHub-hosted, benchmarking depot-ubuntu-latest against ubuntu-latest on the upstream BuildKit repo, and attributes part of the gain to a RAM disk reserving up to 25% of memory. If you enabled runners expecting 55x, the right expectation is up to 3x plus faster caching.
How to get the Docker-build acceleration
To get the container-build speedups, use Depot's Docker build product: the depot/build-push-action (a drop-in for docker/build-push-action) or depot build via depot/setup-action. Per Depot's docs its BuildKit builders can run next to the runners, so a runner job can also drive fast Depot builds. Keep the two products distinct when reading benchmarks.
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.