Depot vs dockerfiler

Depot has moved well past build caching. Test results reached general availability in July with org-wide flaky, slow, and recurring failure analytics plus timing-based shard splitting; Sherlock's AI analysis became available on any run rather than only failed ones; and CI jobs can join a Tailscale tailnet to reach private services. The runner fleet now defaults to macOS 26 on M4 hardware, Depot CI understands GitHub stacked pull requests, and Depot Code — a diskless git server backed by blob storage — entered private beta.

The pattern is absorbing each adjacent piece of the pipeline that Depot's position already gives it data about. It runs the builds, so it owns test timing, so it can balance shards; it runs the jobs, so it can diagnose them; it hosts the runners, so it can wire private networking into them. Depot Code extends the same logic upstream to source hosting, which would close the loop between repository and runner. A quieter parallel thread keeps moving SDK- and dashboard-only settings into the CLI, stated explicitly as making projects configurable by agents and scripts.

Depot Code widening past private beta and binding more tightly to CI is the move the rest of the window sets up. The test work is also positioned to go from reporting to selection — skipping tests a change cannot affect — since Depot now holds the timing and failure history that would require, though the entries stop short of saying so.