Depot’s Cloud Build Layer Is Quietly Cornering Buildkite’s CI Base

The Quiet Infrastructure Play Reshaping CI Pipelines

Container image builds are boring until they are not. When a build takes twelve minutes on a developer’s local machine and forty-five minutes in CI, the pipeline stops being a productivity tool and starts being a tax on shipping speed. Depot is betting that this specific pain point – the gap between local build performance and cloud build performance – is large enough to wedge itself into CI workflows that Buildkite has spent years cultivating.

Depot launched as a faster Docker image build service, positioning its cloud-based BuildKit instances as a drop-in replacement for whatever build step currently sits inside your pipeline. What makes the Buildkite angle worth watching is not that Depot is attacking Buildkite head-on. It is that Depot is making itself indispensable inside Buildkite pipelines, and once the build layer is owned, the rest of the relationship tends to follow.

How Depot Carves Into the Stack

The architecture here is straightforward and that is exactly the point. Depot runs persistent, high-performance BuildKit instances in its own cloud infrastructure. Developers point their Docker build commands at Depot instead of building locally or spinning up ephemeral CI runners to do the heavy lifting. The persistent layer means build caches are always warm, which is where the speed gains actually come from. Ephemeral CI runners – the kind Buildkite provisions by default – start cold every time, meaning layer caches are rebuilt from scratch on every run unless teams have invested significant engineering time in cache management.

Buildkite’s model is agent-based. Teams run their own infrastructure, Buildkite orchestrates the pipeline, and developers get fine-grained control over their build environment. That model is genuinely popular with larger engineering teams who want to avoid vendor lock-in at the compute layer. But it also means Buildkite is not in the business of optimizing your Docker builds. That gap is where Depot lives. By integrating with a single environment variable change – pointing DOCKER_HOST to Depot’s remote BuildKit – teams using Buildkite can cut image build times without changing anything else about their pipeline configuration.

The Developer Gravity Problem for Buildkite

Buildkite has built a strong reputation among mid-size and enterprise engineering teams, particularly those who had outgrown GitHub Actions or wanted more control than CircleCI offered. Its agent model and pipeline-as-code approach earned real loyalty. The challenge Buildkite now faces is not a frontal assault from a better CI platform. It is the slow accumulation of specialized tools that each solve one part of the pipeline better than the generalist CI platform can.

Depot’s positioning mirrors what has happened in adjacent categories. The database layer has seen similar dynamics, where focused infrastructure tools start as supplements and gradually become the preferred primary choice for developers who discover them. The stickiness comes from cache persistence. Once a team’s build cache is living in Depot’s infrastructure and delivering consistent sub-five-minute image builds, moving that cache somewhere else requires deliberate effort. That is not lock-in in the traditional enterprise sense – Depot is not making it contractually hard to leave – but it is gravitational lock-in, which is often more durable.

The pricing model reinforces this dynamic. Depot charges based on compute minutes used, which for teams with warm caches often means they are paying for far less compute than an equivalent ephemeral runner would consume. When the bill is lower and the builds are faster, there is no obvious trigger point that prompts a team to reconsider its build infrastructure. The relationship just persists and deepens as the team ships more services, adds more images, and relies more heavily on the cache state Depot is maintaining.

What Buildkite cannot easily counter here is that the integration is cooperative, not competitive. Depot does not require teams to leave Buildkite. It sits inside the existing pipeline, making Buildkite-orchestrated builds faster. This is a deliberate go-to-market choice that reduces friction at the adoption stage. The strategic question for Buildkite is what happens when a team’s primary emotional and operational relationship with their CI stack is increasingly about the build layer Depot controls rather than the orchestration layer Buildkite provides.

Native Docker Build Cloud and the Counter-Move

Docker launched its own Build Cloud product targeting the same problem – persistent BuildKit instances, warm caches, fast remote builds. This matters because Docker has a distribution advantage Depot does not. Docker Desktop is already running on millions of developer machines, and Docker’s brand association with containers means Build Cloud lands with less explanation required. For Depot, this is the most credible competitive threat on the build-performance side of the argument.

Depot’s counter is a combination of pricing transparency, multi-architecture support, and the fact that it has been refining this specific product longer than Docker Build Cloud has existed at scale. Depot supports building for both AMD64 and ARM64 natively without emulation, which matters significantly for teams deploying to ARM-based infrastructure or supporting Apple Silicon developer environments. That technical specificity is the kind of thing that earns champions inside engineering teams and gets Depot added to internal tooling recommendations.

Where the Developer Relationship Goes Next

The pattern Depot is following has shown up before in infrastructure software. A company enters an established workflow as an accelerant – making something faster, cheaper, or simpler – without asking teams to change what they already know. Adoption is low friction. Then the product expands. Depot has already moved beyond image builds into GitHub Actions integration and a Depot-hosted runner product, which puts it directly in Buildkite’s territory rather than adjacent to it.

The runner product is the tell. Once Depot is handling both the build execution layer and the runner infrastructure, the Buildkite orchestration layer becomes more replaceable, not less. Teams that came to Depot for faster Docker builds may find that Depot’s runners are cheaper or easier to manage than maintaining Buildkite agents. That is not a guaranteed outcome, and Buildkite’s pipeline features – particularly its visual pipeline editor and enterprise audit tooling – are genuinely differentiated. But the gravitational direction of the relationship is shifting.

The teams most at risk of drifting from Buildkite are the ones using it primarily for its agent flexibility rather than its pipeline orchestration depth. For a startup running a relatively simple pipeline that adopted Buildkite because it gave them control over their compute, Depot’s growing runner offering removes the main reason to stay. Buildkite’s strongest retention is with teams that are deeply embedded in its pipeline-as-code configuration and using its more advanced features – dynamic pipelines, test analytics, enterprise access controls. That is a real and defensible base.

But Depot is not trying to win that customer today. It is winning the developer who opens a ticket about slow CI builds, finds Depot in a forum thread, integrates it in an afternoon, and never looks for an alternative because the problem stopped hurting. That developer, multiplied across enough teams at enough companies, is how infrastructure startups quietly reshape where the industry’s defaults end up pointing.