Render's $7 Starter Math: 20 Services Cost $140/Month vs $6 on One Hetzner Box

Twenty small services — a handful of internal tools, a couple of cron workers, three or four preview environments nobody remembered to clean up — is an easy fleet size to arrive at by accident. On Render's Starter tier, that fleet costs $140 a month before a single byte of bandwidth or a single workspace fee gets added. The same twenty processes, bin-packed onto one shared Hetzner box the way a Cluster-API-managed platform already treats a multi-tenant node, cost as little as $6 a month. That's not a rounding error — it's a 23x gap for running the identical workloads.

$7 a month sounds like the kind of number you don't bother optimizing. That's exactly the point: it's cheap enough per service that nobody does the multiplication until the invoice does it for them. Below is the line-by-line recompute — what twenty Starter services actually bill on Render, what the same fleet costs packed onto owned hardware, and the two numbers that actually answer "when does this stop being the cheap default" (hint: neither of them is a graceful crossover point).

What $7 a Month Actually Reserves​

Render's Starter instance is $7/month per service: 512MB of RAM, 0.5 vCPU, always-on. It's a reserved slot, not a metered one — Render bills for the full 512MB/0.5vCPU allocation whether the process inside it is serving real traffic or idling at 60MB of actual memory use, which is closer to reality for the kind of workload this math is about: internal admin tools, scheduled cron jobs, and short-lived preview deployments rarely come close to saturating half a virtual core.

Compute isn't the only line item. Render restructured its workspace pricing on April 23, 2026, replacing legacy per-seat billing with three flat-fee tiers:

A team running twenty small services fits under Hobby's free tier on seats and, at 20 of 25 services, is still technically inside its service cap — with no room to spare. That "free" workspace plan is doing a lot of quiet load-bearing work in this scenario, and it's worth flagging now because it comes back in the last section.

The Twenty-Service Render Bill, Line by Line​

Run the actual numbers for twenty Starter services on a Hobby workspace:

Compute is 99% of the bill. The workspace fee is zero and bandwidth is nearly a rounding error for this kind of low-traffic fleet — which matters, because it means the $140 isn't inflated by some avoidable extra. It's the base price of twenty always-on reserved slots, full stop. Scale to forty services and the same math produces $280 in compute alone, plus a forced move to the $25/month Pro workspace the moment the 25-service Hobby cap is crossed.

The One-Box Alternative​

Hetzner's shared-vCPU CX line, repriced June 15, 2026, looks like this:

Twenty lightweight processes — the same internal tools, cron workers, and preview services from the Render scenario — running at a realistic 100–150MB of actual memory use apiece need roughly 2–3GB of RAM in aggregate, plus headroom for the OS and container runtime. That fits comfortably on a CX23: 4GB of RAM, 2 vCPUs, 20TB of bundled bandwidth (four thousand times the traffic Render's Hobby workspace includes for free), for €5.49 — about $6 a month.

Even sized generously for growth — a CX43, with 16GB of RAM and room for well over a hundred services at that footprint before the box itself needs replacing — the bill is $17 a month. That's the deliberately pessimistic comparison, sized for headroom nobody in this scenario actually needs yet, and it's still roughly 8x cheaper than Render's twenty-service bill. The realistic comparison, a right-sized CX23, is closer to 23x cheaper.

The Specific Numbers That Actually Matter​

The title asks for a service count: where does "just spin up another Render service" stop being the cheap default? There are two concrete answers, and they're not the graceful crossover a reader might expect — they're both worse than that for Render.

Service #1. A single Render Starter instance already costs more per month ($7) than an entire right-sized Hetzner box running twenty processes ($6). There's no service count at which Render becomes the economical choice, because the "shared box" isn't a bigger, better-amortized version of a Render service — it's a different unit of billing entirely, one where the marginal cost of the twentieth process is close to zero. Render's cost curve is $7 × N, flat and linear with no economies of scale built in. Hetzner's is a step function: free until the box runs out of RAM, then one discrete jump to the next box size.

Service #25. This is the number that forces a decision regardless of budget. Render's Hobby workspace — the free tier that a twenty-service team is otherwise perfectly happy on — hard-caps at 25 total services, counting suspended ones. A team at 20 services is sitting at 80% of that ceiling while already paying nearly $141 a month for compute a shared box would run for $6. Adding five more Starter services doesn't just cost another $35 — it trips the service cap outright, forcing either a cleanup pass (deleting or suspending old preview environments) or a jump to the $25/month Pro workspace on top of the $175 those 25 services would then cost in compute alone. Nobody hits that wall because the compute got too expensive to justify; they hit it because Render's architecture, not its pricing, decided twenty-five was the ceiling for a free workspace.

Put those two together and the honest framing isn't "migrate once you cross N services" — it's that the twenty-service fleet in this article was never the cheap default to begin with, and the one number that will force the question regardless of anyone's tolerance for a $141 bill is five services away.

Where the Math Doesn't Favor the Box​

None of this makes Render a bad choice for the workload it's actually priced for: a single service, or a small handful, run by a team that would rather pay $7 a month than own an SSH session. Render's Starter tier includes zero-downtime deploys, a managed TLS certificate, log aggregation, and a dashboard a non-infrastructure engineer can operate without ever touching a shell — real operational value that a bare Hetzner box doesn't hand you for free. The math in this article breaks specifically at fleet size, not at service #1 in isolation: one team running one Starter service for $7 a month isn't overpaying for what they get, because there's no twentieth service diluting the fixed overhead of "someone has to patch the OS, configure the reverse proxy, and handle certificate renewal" across more workloads.

The gap opens because that operational overhead doesn't multiply by service count on a self-hosted box the way Render's per-service billing does — it's paid once, by the platform, regardless of whether the box runs one process or a hundred. A team running exactly one or two services genuinely has a smaller gap to close than the twenty-service fleet in the table above; it's the sprawl — the cron worker nobody remembers deploying, the third preview environment for a feature branch that shipped two months ago — that turns a defensible $7-a-service default into a $141 line item nobody budgeted for.

Why This Is the Default, Not a Migration Project​

The reason this gap exists isn't that Render is badly priced for what it does — a managed, per-service reserved compute slot with its own dashboard, zero-downtime deploys, and a support team behind it is a real product with real operating costs. The gap exists because "one service, one billed unit" and "twenty processes sharing one box's spare RAM" are structurally different ways of allocating compute, and only one of them has a cost that scales sublinearly with fleet size.

On a Cluster-API-managed fleet, packing many small, low-traffic tenant processes onto a shared node isn't a manual optimization a team has to engineer — it's the scheduler's default behavior, the same way Kubernetes bin-packs any other workload against available node capacity. The twenty-service team in this math never had to choose between "one service per box" and "cram everything onto one machine by hand"; a platform built on real bin-packing does that automatically, and the internal tools, cron workers, and preview environments that would have quietly cost $140 a month on a per-service reserved-slot platform instead cost whatever fraction of one shared Hetzner box they actually use.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, where twenty small internal tools share one node's capacity instead of renting twenty separate reserved slots. Star the repo on GitHub or deploy your first app today.

Sources​

• Render Pricing
• Render: New Workspace Plans
• Render: Outbound Bandwidth
• Render Blog: Better Pricing for Fast-Growing Teams
• Hetzner: Price Adjustment 15 June 2026
• Hetzner Cloud