Depot Raised $10M to Kill Slow Builds: What It Still Sells a Team That Owns Its Machines

In March 2026, Depot raised a $10M Series A led by Felicis — with Y Combinator, Pioneer Fund, and Docker founder Solomon Hykes along for the ride — to do something ambitious: rebuild CI itself for the AI era. The pitch is that the bottleneck has moved. Agents now write code faster than pipelines can integrate it, so Depot is selling relief from what it calls the "tax on speed": cache-cold runners, flaky networks, and minutes-long queues on every push.

Here is the verdict up front, with the numbers to back it: Depot's real product is persistent cache, not compute. If your builds keep landing on the same machines you own, you already have roughly 80% of what Depot sells — a warm layer cache on fast local NVMe — for a flat server bill instead of a meter. The meter still wins in exactly one case: bursty, highly parallel build spikes that would force you to buy peak capacity year-round. Everything else is a question of volume, and the breakeven math is simple enough to do on a napkin.

If you recognize your team in the middle or bottom row and already operate a fleet, keep reading for what the meter still buys you — and the one workload shape where you should pay it anyway.

What Depot actually sells: warm cache, not fast CPUs​

To price Depot fairly, you have to understand the failure mode it was built to kill. A standard CI run starts from zero every time: an ephemeral VM spins up cold and empty, clones your repo from scratch, downloads every dependency from the internet, builds, then gets destroyed. Depot's founders hit this wall at previous jobs watching multi-platform image builds take 45 minutes in GitHub Actions — flaky networks, tight cache limits, painful ARM emulation — and their first prototype made the same builds 5x faster just by keeping the cache warm between runs.

That mechanism is still the core of the product three years later. When you swap docker build for depot build, your build runs on a remote BuildKit host with your project's Docker layer cache automatically persisted to fast NVMe SSDs — no cache-from/cache-to wiring, shared across your whole team, with configurable retention and cache volumes that scale to 1TB. The compute is ephemeral EC2; the cache is the durable asset. Depot has since layered GitHub Actions runners, a globally distributed container registry, remote caching for Bazel/Go/Turbo, and agent sandboxes on top of the same insight: every commercial fast-builder treats cache as the product.

Depot CI, launched in March 2026 at KubeCon Amsterdam, extends that logic from the build step to the whole pipeline. Depot's argument is that it could previously make about 30% of a CI system exponentially faster — the build and the runner — while the other 70% (the control plane, runner provisioning, orchestration) belonged to someone else's infrastructure. So it built its own programmable CI engine: GitHub Actions workflow syntax works from day one via a depot ci migrate command, jobs start in seconds on Depot's own compute, every run gets logs, CPU/memory metrics, and SSH debugging, and the whole pipeline is API-driven so agents can trigger runs and pull logs without a GitHub event. Pricing is per-second with no minimums — $0.0001/second for a 2vCPU/8GB sandbox, scaling linearly to 64 vCPUs.

None of this is snake oil. For teams on cache-cold ephemeral runners, Depot's speedup claims are credible precisely because the baseline is so bad: re-downloading the internet on every run is a tax most teams pay without itemizing it. The question is only whether you still pay that tax — or whether owning the machines already exempted you.

The owned-fleet math: your cache is already warm​

Now run the same workload on infrastructure you own. A Hetzner AX41-class dedicated server — 6-core Ryzen, 64GB RAM, 2x512GB NVMe — runs roughly $40–55/month, with 20TB of included traffic. A beefier AX52-class box with 8 cores and 2x1TB NVMe lands around $55–90/month.

Park a BuildKit builder or your CI runners on that box, and every build after the first reuses the previous build's layers from local NVMe. There is no cache upload step, no cache download step, no per-GB cache storage line item, and no per-minute meter. The marginal cost of one more build minute is zero.

Depot's Startup plan costs $200/month and includes 5,000 Docker build minutes, 20,000 Depot CI minutes, and 250GB of cache and registry storage. Divide the plan price by the Docker overage rate of $0.04/minute and you get exactly 5,000 minutes — the breakeven is printed on the tin. Past that line, each additional 1,000 Docker build minutes costs $40 in overage, which is approximately one more AX41 that would serve unlimited minutes forever.

Work through three representative volumes:

The side project (~500 Docker minutes/month). Depot's $20 Developer plan covers this with room to spare, and the honest answer is that renting a whole dedicated server to save $20 is false economy — unless you already run the box for other workloads, in which case builds ride free. At this volume, Depot wins on simplicity, not price.

The working team (~5,000 Docker minutes/month). This is exactly Depot Startup's included bundle: $200/month, meter never tripped. The same workload on one $45 AX41 costs $45/month with unlimited headroom. Owning the machine is more than 4x cheaper, and the cache behavior is identical — warm layers on local NVMe, reused across every run. The $155/month difference is the price of never thinking about a builder. For some teams that is money well spent; it is not money spent on performance.

The busy monorepo (~20,000 Docker minutes/month). Depot bills $200 plus 15,000 overage minutes at $0.04 — $800/month before extra cache storage at $0.20/GB. The owned fleet serves it from the same one or two boxes for under $100/month. At steady high volume, the meter costs roughly what seventeen dedicated build servers cost. This is the row where "just put it on Depot" quietly becomes the most expensive line in the infrastructure budget.

Two honest caveats before the owned-fleet crowd declares victory. First, the server bill is not the total bill: somebody operates the builder, patches the host, manages disk pressure when the cache grows, and gets paged when builds queue. Depot's price includes all of that plus support. Second, the comparison above assumes your builds actually reuse cache — a fleet that wipes runners between jobs for isolation reasons has rebuilt the cache-cold problem on owned hardware and should fix that before comparing prices.

What the meter still buys​

Price-per-minute is not the whole product, and four Depot capabilities genuinely don't come free with a server:

Unlimited burst concurrency. Depot plans include unlimited build concurrency; a hundred PRs can each get a warm builder at once. Your two AX41s serve exactly as many parallel builds as they have cores for. If your workload is fifty builds a day punctuated by a 200-build release-train spike every Friday, the owned fleet either queues the spike or sits idle all week. Elasticity is the oldest cloud argument there is, and it still applies to builds.

Zero cache operations. Retention policies, disk-pressure eviction, cache-volume scaling to 1TB, per-project isolation — Depot operates all of it. On your own fleet, BuildKit's garbage collection and disk management are your problem at 2am. This is real toil, not imagined, and small teams without platform bandwidth should price it honestly.

Native multi-arch without emulation. Depot builders run natively on Intel and ARM, which is what made those original 45-minute emulated multi-platform builds 5x faster. Reproducing that on owned hardware means buying and operating ARM machines too — Hetzner has them, but it's a second fleet to manage for a workload many teams run a few times a day.

Registry, remote cache protocols, and sandboxes. The CDN-backed registry with free standard transfer, the shared cache for Bazel/Gradle/sccache/Turbo, the $0.01/minute agent sandboxes — each is reproducible (registry mirrors and sccache buckets are solved problems), but each is another system to run. Depot's bundle argument is strongest for teams that want all of it on day one.

Notice what these four have in common: none of them is "faster builds for a steady workload on warm cache." They are elasticity, operations, architecture coverage, and bundling. Worth paying for — but worth naming correctly when the invoice arrives.

The one case where metered wins: spikiness​

Put the two sides together and the decision reduces to a single workload property: how spiky are your builds?

A steady-state team — roughly the same number of builds every hour of every workday — is the worst possible customer for metered builds and the best possible owner of a fixed fleet. Utilization stays high, cache stays hot, and every overage dollar converts directly into server budget at a 4–10x ratio. If that describes you, own the builders and spend the savings on something that differentiates.

A spiky team — quiet nights, a hundred parallel builds when the release train leaves or when a fleet of coding agents all push at once — faces the opposite math. Sizing owned capacity for the spike means paying for idle cores 90% of the time; sizing for the mean means queuing the spike. This is the case the Depot pitch is really about, and the AI-era framing is honest here: a team of ten engineers with agents operating like a team of a hundred doesn't generate 10x steady load, it generates 10x spikes. Unlimited concurrency against warm per-project cache is genuinely hard to replicate on fixed hardware, and per-second billing means the spike costs dollars, not a server contract.

The pragmatic answer for most self-hosted teams is both: a fixed owned fleet sized for steady state, with Depot (or any metered remote builder) as the overflow lane for spikes. Route the everyday builds to warm builders you own at zero marginal cost, and let the meter absorb the Friday-afternoon surge. You get the 4x savings where volume lives and the infinite ceiling where spikes live — which, not coincidentally, is how every mature fleet treats compute generally.

Treat cache as the product, wherever it lives​

Depot's $10M bet is that integration — not code generation — is the bottleneck of the AI era, and that bet looks directionally right. Its growth from a two-founder YC project annoyed by 45-minute image builds into a full CI control plane powering thousands of teams is evidence that the tax on speed was real and large. But the deepest lesson of Depot's architecture isn't "rent your builders." It's that cache is the product: the team that keeps layers warm wins, whether the NVMe sits in Depot's account or yours.

If you own a fleet, audit it with that lens before you audit your CI bill. Warm, shared, persistent builder cache on local NVMe closes most of the gap Depot charges to close. What remains — burst elasticity, zero cache ops, native multi-arch, the bundled registry — is a real but narrow list, and only spikiness makes it worth $0.04 a minute. Measure your build arrival pattern, do the napkin math, and buy the meter only for the shape it serves.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.