Dora NodaDepot's remote build cache is billed the same way cloud storage is: by the gigabyte, sampled hourly, averaged over the month, at $0.20/GB for every gigabyte past whatever your plan includes. That's not a footnote in the pricing page — it's a second, independent meter running next to your per-minute build bill, and for a team with a real dependency and Docker layer cache footprint, it adds up to real money. A Cluster API-managed fleet building on owned Hetzner nodes gets the same persistent, cross-build cache for the marginal cost of the disk it's already paying for: zero. Here's the actual arithmetic, plan by plan and gigabyte by gigabyte.
How Depot Actually Meters the Cache
Depot's two published plans both carry the same overage rate, just different included allotments:
| Plan | Monthly base | Cache included | Overage rate |
|---|---|---|---|
| Developer | $20 | 25 GB | $0.20 / GB / month |
| Startup | $200 | 250 GB | $0.20 / GB / month |
| Business | Custom | Custom | Custom |
That storage pool isn't just Docker layers — it's shared across Depot Cache (Bazel, Go, Gradle, Turborepo, sccache, Pants), the Depot Ephemeral Registry, GitHub Actions cache, and Docker layer cache all at once. That's exactly how a real project blows past the included allotment faster than "just Docker layers" would suggest.
Usage is measured by taking an hourly snapshot of storage consumed and averaging those snapshots across the month, so a cache that spikes to 500GB for a week and drifts back down still gets billed on its time-weighted average, not its peak.
This is the same shift this blog already tracked at GitHub: a resource that used to be a flat, silently-evicting free tier became a metered line item. GitHub's version is considerably gentler, though — Actions cache overages past a free 10GB-per-repository allotment run $0.07/GB/month, roughly a third of Depot's rate. Depot's cache buys you something GitHub's doesn't: cross-machine persistence outside any single CI runner, addressable from Bazel, Turborepo, and sccache directly, not just actions/cache.
So the higher price isn't unreasonable on its face. The question is what it costs once a team's actual footprint gets large enough to matter.
What Actually Fills 400GB
The plan-tier allotments — 25GB, 250GB — sound generous until you count what's actually competing for that one shared pool. It isn't one number, it's a sum:
- Docker layer cache, one lineage per service — a dozen services with their own base images and dependency layers adds up fast.
- sccache's compiled-object cache for any Rust or C++ build, which routinely runs tens of gigabytes per active branch once you're caching more than one target architecture.
- Bazel's remote-execution cache for a large monorepo, designed to hold years of build outputs, not weeks.
- Turborepo's per-task output cache — small per task, but multiplied across every package and every task in the graph, on every branch.
None of these individually looks alarming. Stacked into one billed pool across a team with a dozen active branches, 400GB stops being a hypothetical and starts being Tuesday.
Depot's default retention window makes this worse, not better, for a team trying to stay under the meter: cache entries live for 14 days by default (organizations can tune it from 7 to 30 days, or cap total size, in settings), which means an active team's footprint doesn't shrink on its own — it holds near its high-water mark as long as branches keep merging and cache keeps getting written faster than it ages out. Staying under an allotment isn't a one-time cleanup; it's an ongoing retention policy someone on the team has to actively tune.
The Worked Comparison
Take the overage rate at face value and isolate it: for every gigabyte a team's combined cache footprint sits above whatever their plan includes, Depot charges $0.20/month. Line that up against two self-hosted alternatives — a Hetzner Cloud block Volume at today's rate (€0.0572/GB/month, about $0.062 at current exchange rates), and a local NVMe volume on a Hetzner bare-metal node a Cluster API fleet already owns and is already paying for as part of its compute budget:
| Cache footprint over the included allotment | Depot overage/month | Hetzner Cloud Volume equivalent | Owned bare-metal NVMe (already-budgeted node) |
|---|---|---|---|
| 25 GB (small team, past Developer's 25GB) | $5.00 | $1.55 | $0 |
| 125 GB (mid-size monorepo) | $25.00 | $7.75 | $0 |
| 400 GB (Docker layers across a dozen services + Turborepo/sccache) | $80.00 | $24.80 | $0 |
| 1,000 GB (large polyglot monorepo, several build systems) | $200.00 | $62.00 | $0 |
The pattern holds at every size: Depot's per-GB rate runs about 3.2x a Hetzner Cloud block Volume bought at retail, and the gap only widens against hardware you already own.
Put a number on the extreme end of that range. A Startup-plan team whose combined cache footprint reaches 1,250GB — plausible for an org running Docker layer caches across a dozen microservices plus a JS/Rust monorepo's Turborepo and sccache state — pays the $200 base plan plus 1,000GB of overage at $0.20/GB, or $200/month in cache alone. That's $400/month total, literally doubling the plan's sticker price before a single extra build-minute is spent.
The same 1,250GB sitting on a persistent local-NVMe PersistentVolumeClaim on an owned Hetzner build node — the StatefulSet-plus-pinned-cache recipe this blog covered when Depot's colocated architecture first shipped — costs nothing beyond the node the fleet was already running to build tenant images. There's no allotment to track, no hourly snapshot deciding what you owe, no plan-tier upgrade forced by cache growth alone.
What Depot's Model Actually Buys You Instead
None of this means Depot's rate is unreasonable for what it replaces. A team without owned hardware — nobody running a Cluster API control plane, no bare-metal fleet, just GitHub-hosted runners and a laptop — is comparing $0.20/GB against the alternative of provisioning and operating that infrastructure themselves, not against a Hetzner node that's already sitting there. For that team, Depot's storage line is a genuinely fair price for durable, Ceph-backed, cross-machine cache they'd otherwise have to build.
It's worth being precise about one claim that's easy to overstate here: Depot's metered build cache is namespaced per project, shared across your own team's builds, not pooled across different Depot customers. Two unrelated companies building the same public node:20-alpine base image don't get to split the storage bill or share cache hits on that per-project volume — each pays for and populates their own copy.
The actual cross-tenant sharing lives one layer up, in Depot's Registry product, which can act as a pull-through cache for external registries: a base image layer pulled once through Depot's CDN can stay warm there for the next customer's pull, independent of whose build triggered it. That's a real structural advantage a single tenant's local disk can't replicate on its own — though it's also not exclusive to Depot. A self-hosted fleet can run the same pattern cheaply with a standard registry pull-through mirror in front of Docker Hub, solving the "don't refetch a popular public layer from the internet every time" problem without a vendor's per-GB cache meter.
The gap that's genuinely hard to close yourself is durability, not sharing: Depot's Ceph-backed cache survives an instance dying, where a cache pinned to a single node's local NVMe doesn't, unless the fleet replicates it itself.
The Actual Trade
Strip away the marketing framing and the comparison is simple: Depot is selling infrastructure you don't have to build, priced by the gigabyte, sampled hourly. If you don't own build hardware, that's a fair trade at $0.20/GB. If you're already running a Cluster API-managed fleet on owned Hetzner nodes — which is precisely the platform architecture a self-hosted git-push PaaS needs anyway — that same gigabyte is already paid for as part of the node, and every dollar spent on Depot's cache meter past that point is buying storage you were already going to own.
Put a concrete machine under that claim: a single Hetzner AX102 (16 cores, 128GB RAM, 2x1,920GB NVMe) runs about $134/month at current German pricing — and that node exists to build tenant images regardless of whether it also hosts a cache volume. Its raw NVMe alone could hold the 1,250GB monorepo footprint from the table above more than twice over, with room left for the OS and other tenant data, at no incremental cost beyond the compute the fleet already needed. The retention tuning Depot asks a team to actively manage doesn't disappear on owned hardware — BuildKit's own garbage-collection thresholds still need setting so one tenant's cache can't quietly consume a shared node — but there's no monthly bill attached to getting that number wrong, only a slower cold build the next time the GC runs.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with no per-GB cache meter watching your build pipeline. Star the repo on GitHub or deploy your first app today.
