StarSling vs Depot for GitHub Actions

Docker builds are often slow in CI because an ephemeral runner starts without the layers your last build produced. Depot changes that part of the system by running builds on remote BuildKit builders in the same private network as the runner, with a persistent NVMe layer cache on the builder. Depot Cache is a separate remote cache product for GitHub Actions, Bazel, Go, Gradle, Turborepo, and other build tools.

StarSling does not move your Docker build to a separate builder service. The build stays inside your GitHub Actions workflow on faster StarSling runners, and standard BuildKit cache backends still work. The agent layer is the difference: it can open PRs that fix Dockerfile ordering, cache scopes, install steps, and workflow structure instead of only making the existing build machine faster.

Depot is strongest when the Docker build itself is the bottleneck. StarSling's customer proof is broader: the agents have shipped PRs against caches, dependency installs, service readiness, test sharding, queue pressure, and runner right-sizing. These are published case-study windows, not head-to-head Depot benchmarks; follow each case study for source method and caveats.

• Better Auth: after migration and three agent PRs, E2E went from 2m 22s to 1m 04s and CI went from 1m 40s to 1m 02s.
• Mastra: agents replaced fixed sleeps, added healthchecks, sharded E2E, and migrated workflows; Combined store Tests measured 29m 56s to 5m 06s in the post-migration window.
• Partcl: on a synthesis-bound workload, the agents cut heaviest-job compute cost 13x per run and reduced p95 queue time from 9.5 minutes to 35 seconds.