Dora NodaOn August 7, 2026, Render published one of the most honestly written changelog entries in PaaS history: service builds moved to nodes with faster CPU and disk, and the median build time fell from 38 seconds to 21 seconds — a 40% cut, labeled conservative, reflected across every runtime. No new cache layer, no rewritten pipeline. Faster hardware, 17 fewer seconds per build.
Seventeen seconds sounds like nothing until you price it. At Render's overage rate of $5 per 1,000 build minutes, the median build cost $0.0032 before and $0.0018 after. And that saving is the setup for the real question: what does it cost to reproduce Render's 21-second median on a builder you own, and at what volume does the fixed box beat the meter? The full table is below; the rest of this post substantiates every row.
| Metered build, 21s median | Cost per build | Builds/day to match a ~$10/mo Hetzner box |
|---|---|---|
| Render ($0.005/min overage) | ~$0.0018 | ~190 |
| Railway (2 vCPU/4 GB at $0.00000772/vCPU-s + $0.00000386/GB-s) | ~$0.0007 | ~513 |
| Depot metered, the engine behind Fly remote builders (~$0.04/min) | ~$0.014 | ~24 |
| Hetzner CX32-class box (4 vCPU, 8 GB, ~€9.38/mo) running warm BuildKit | flat ~$10/mo | — |
(Render's own prior single-runtime cuts — 25% for Node.js, 27% for Python, 60% for Docker — were mostly caching work; this one was hardware, which is exactly why a self-hoster can copy it.)
What Render actually bought
Read the entry literally: "builds now run on nodes with faster CPU and disk." The bottleneck that remained after all that caching work was the physical floor — clock speed for compile steps, disk throughput for layer unpack and dependency install. Median build time by week sat at 38 seconds through the week of July 13; from July 27, the first full week after the rollout, no weekly median has exceeded 21 seconds. Raw medians imply closer to a 45% reduction, hence "conservative 40%."
There are two lessons, and only the second is obvious. The obvious one: build fleets are hardware products, and stale builder generations tax every deploy on the platform. The less obvious one: Render did the caching wins first. By the time faster disks arrived, there was almost nothing left in the build that faster disks couldn't touch. Anyone reproducing this on owned hardware has to do both halves — the disk floor and the cache strategy — because a fast box with a cold cache still builds cold.
The breakeven math, with sensitivity and sizing
Take a 30-day month and three team shapes: 50 builds/day (small team, a few services), 200/day (busy monorepo or preview-environment-heavy shop), and 1,000/day (platform-scale CI). Price each at the warm 21-second median and at a 60-second cold-Docker-build duration, because duration is the variable that drives everything.
At 21 seconds per build (1,500 / 6,000 / 30,000 builds per month):
| 50/day | 200/day | 1,000/day | |
|---|---|---|---|
| Render | $2.63 | $10.50 | $52.50 |
| Railway (2 vCPU/4 GB) | $0.97 | $3.89 | $19.45 |
| Depot metered | $21.00 | $84.00 | $420.00 |
| Owned Hetzner box | $10 | $10 | $10 |
At 60 seconds per build (same volumes):
| 50/day | 200/day | 1,000/day | |
|---|---|---|---|
| Render | $7.50 | $30.00 | $150.00 |
| Railway (4 vCPU/8 GB) | $5.56 | $22.23 | $111.17 |
| Depot metered | $60.00 | $240.00 | $1,200.00 |
| Owned Hetzner box | $10 | $10 | $10 |
Three things fall out. First, duration moves the answer more than vendor choice at the low end: a team whose real builds run 60 seconds crosses the own-it line at a fraction of the volume its 21-second math suggests — on Render, the breakeven drops from ~190 builds/day to ~67. If you only remember one sensitivity, remember that your p99 build, not the median, sets the bill. Second, the metered vendors differ by an order of magnitude from each other: Railway's resource-second pricing is genuinely cheap for short builds on small shapes ($0.97/month at 50/day!), while per-minute metered builds cost 8x Render's rate and lose to a fixed box at barely two dozen builds a day.
Third, free allowances cover the hobby tier entirely — Render includes build minutes with plans plus 500 free minutes, Fly announced a 300-minute monthly allowance — so this whole comparison only starts once a team outgrows the free tier, which is exactly when they start asking the question.
Then comes sizing, which the per-day table hides. Builds per day is not the capacity question; concurrent builds is. Little's law: average concurrency equals arrival rate times build duration. 200 builds/day spread over an 8-hour workday is 25 builds/hour; at 60 seconds each that is 0.42 average concurrent builds — one box, asleep half the time. 1,000/day over the same window is 2.08 concurrent — now you want two builders, or one builder plus metered overflow.
And averages lie about merge peaks: 30 pushes landing in 10 minutes with 60-second builds is 3 arrivals/minute against a single box that finishes ~2/minute, i.e. 150% utilization for the whole burst, with the tail of the queue waiting several minutes. Sustained volume sizes the fleet; burstiness decides whether the meter stays on as a relief valve.
Pick the builder: BuildKit vs Kaniko vs Buildpacks
Hardware is half the reproduction. The other half is which builder runs on the box, because the three serious options put the cache in three different places:
BuildKit (buildx) | Kaniko | Cloud Native Buildpacks (Paketo) | |
|---|---|---|---|
| Model | Daemon (or rootless) with a persistent local layer store | Daemonless, unprivileged — builds in userspace, pushes to registry | Lifecycle daemon; auto-detects language, caches layers, rebases without rebuilding |
| Where the cache lives | Warm on the box: local layers, inline/registry cache (mode=max), mount caches | Registry only (--cache + --cache-repo): every build pushes the full layer manifest | Layer cache on the box plus image rebasing for OS patching |
| Why it can be slow | Cold box is still cold; needs privileged mode or userns setup | Registry push overhead on every build even for cache hits; no warm daemon to reuse across ephemeral nodes | Heavier first build; detection magic you don't control |
| Best fit on hardware you own | The default: a persistent box keeps the daemon warm between builds, which is the whole game | Clusters where you can't get privileged builders, or fully ephemeral build pods | Teams that want git push with no Dockerfile and will trade first-build speed for zero config |
On a box you own, the warm BuildKit daemon is the answer in nearly every case — persistence is the feature Kaniko was designed to live without, and paying registry round-trips per build made sense for ephemeral CI, not for a builder that never goes away. One honest caveat on published numbers: a 2026 benchmark writeup making the rounds claims Buildpacks built in 85 seconds what a Dockerfile build did in 620 — treat that 7.3x as a vendor-adjacent data point, not a law of nature, but the direction is right and the mechanism (layer reuse plus rebase instead of rebuild) is why.
Reproducing Render's 21-second median on a CX32-class box is a cache-hit-rate problem first and a CPU problem second: at 90%+ layer reuse, even modest shared vCPUs land warm builds in the teens of seconds; at 0% reuse, a dedicated CCX23 (~€37.47/mo, 4 dedicated vCPUs) still builds cold.
The burst problem owned builders can't dodge
The fixed box has exactly one weakness and it is structural: it cannot autoscale. Metered builders absorb a merge-peak burst by spending money; your box absorbs it by queueing. Overnight the box sits idle — pure waste on paper — while the metered team pays nothing between pushes.
So the decision rule is a workload shape, not a volume number:
- Spiky and thin (a few deploys a day, preview environments that burst at merge time, nights and weekends dead): stay metered. Railway's resource-second pricing is brutally hard to beat under ~100 short builds/day, and idle costs zero.
- Sustained and thick (hundreds of builds/day across a workday, monorepo CI, preview envs per push): own the box. The breakeven lands between ~25 and ~200 builds/day depending on vendor and duration, and past it every additional build is free.
- Thick with spikes (platform-scale plus merge peaks): own the base fleet, keep the meter as overflow. One or two warm Hetzner builders handle the median; burst overflow spills to metered builds instead of a third box that idles 20 hours a day.
Note what is missing from every metered option: none of them lets you own the cache across builds the way a warm daemon does. Render's own history proves the point — the 60% Docker cut came from caching, and it compounded with the hardware cut instead of being replaced by it.
Conclusion: buy the disk, own the cache
Render's 40% is reproducible because it was never magic: faster disks under a pipeline whose caching was already done. The self-hosted recipe is three lines — a CX32-class box ($10/mo) or a dedicated CCX23 (€37/mo) when builds need guaranteed CPU, a warm BuildKit daemon with registry cache mode=max so layers survive across builds, and a metered overflow for merge peaks — and it matches 21-second medians at any volume past a couple dozen builds a day.
The deeper lesson travels further than one changelog: on a build fleet, cache ownership is the durable advantage and hardware is a purchase order. Render bought the hardware. You can buy the same hardware. The cache is the part you have to operate — and it is the part that keeps paying after the new-disk smell fades.
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.
Sources
- Render changelog, August 7, 2026: "Reduced median service build time by 40% (all runtimes)" — 38s median (week of July 13) to max 21s weekly median (since July 27) on faster CPU/disk nodes; prior Node.js 25%, Python 27%, and Docker 60% single-runtime cuts.
- Render pricing research: build-minute overages at $5 per 1,000 minutes ($0.005/min); 500 free build minutes/month; Performance build pipeline (8x RAM/CPU) billed separately.
- Railway usage pricing: $0.00000772 per vCPU-second and $0.00000386 per GB-second; Hobby $5/mo with $5 usage included.
- Fly.io community (Depot remote builders thread): 300 build-minutes/month free allowance planned, then $0.05/min; Depot's listed metered rate widely quoted at ~$0.04/build-minute plus ~$0.20/GB-month cache storage.
- Hetzner pricing (2026): CX32 4 vCPU/8 GB ~€9.38/mo; CCX23 4 dedicated vCPU/16 GB ~€37.47/mo; AX41-class dedicated from ~€37/mo.
- BuildKit registry-cache mechanics (
--cache-to type=registry,mode=max); registry-cache push-overhead analysis (ai-dynamo BuildKit remote-build note); 2026 Buildpacks-vs-Dockerfile 85s-vs-620s benchmark claim, attributed as third-party.
