Porter, the Heroku-style layer that runs in your own cloud, once told prospective customers something almost no vendor says out loud: if you spend less than about $300 a month on Heroku, stay on Heroku — or use Fly.io or Render. Their base infrastructure alone costs around $300, so below that line they lose. That candor is worth more than a hundred "Kubernetes saves 80%" threads, because it names the crossover instead of gesturing at it. So let's take the number seriously and re-price it for 2026 — against Kubernetes on hardware you actually own, not AWS.
The short answer is in the table below. Take a typical small-production stack — two web instances, one worker, managed Postgres, managed Redis, plus an identical staging copy — price it on three managed platforms and on a small high-availability Cluster API fleet on Hetzner, and the $300 rule splits in two:
| Stack S + staging, per month | Managed total | vs. owned fleet |
|---|---|---|
| Heroku (Standard dynos + Essential Postgres + Mini Redis) | $266 | +$211 |
| Render (Standard web + managed Postgres + Key Value) | $174 | +$119 |
| Fly.io (shared-cpu Machines, always-on staging) | $80 | +$25 |
| Fly.io (staging auto-stopped when idle) | ~$45 | −$10 |
| CAPH fleet on Hetzner (HA control plane + 2 workers + LB + volumes/backups) | ~$55 | — |
All figures in USD at €1 = $1.08, from public list prices, September 2026. Component breakdowns follow below, and every total here is reused exactly — not recomputed — in the sensitivity matrix at the end.
Two things jump out. First, for this stack, Heroku and Render have already crossed Porter's line well before $300 — the rule bites earlier than its own number suggests once staging doubles the bill. Second, Fly.io with scale-to-zero staging has not crossed at all, which is exactly why the honest version of the rule is a matrix, not a number. That matrix — and the ops-time term everyone leaves out — is the rest of this post.
Where the $300 comes from
Porter's number was never about dynos. It was about the fixed floor under an AWS-based Kubernetes platform: the EKS control plane alone is $0.10 an hour, about $72 a month before a single pod runs. Two NAT gateways across two availability zones add roughly $65 in hourly charges plus data-processing fees, landing near $90–100 in practice. An application load balancer contributes another $16–25. Two small worker nodes to hold the platform itself add roughly $60. Sum it and you are at $250–300 of base infrastructure that exists whether you serve ten requests or ten million.
That is what makes the quote remarkable. Most vendors hide their lose-below line; Porter stated it as buying advice, adding that costs on Heroku escalate fast past a point — one Performance L dyno alone was already about $500 a month. A 2026 survey of migration guides lands in the same place: under roughly ten services, stay on the managed platform; past that, the per-instance meter starts compounding.
The $300 rule is an AWS-floor number quoted by a vendor that operates the floor for you. Change the floor — owned Hetzner hardware instead of rented AWS primitives — and change who operates it, and the crossover moves. The rest of this post measures by how much.
The managed side, line by line
Define stack S as two web instances in the 1 GB RAM class, one worker, Postgres around 1 GB, a small Redis, and an identical staging copy. Staging matters because it is the multiplier teams forget: the day you add a staging environment that mirrors production, most managed bills roughly double while the owned-hardware bill barely moves.
On Heroku's 2026 list prices — Eco at $5, Basic at $7, Standard-1X at $25, Standard-2X at $50, Performance-M at $250, Performance-L at $500 — production prices out as two Standard-2X web dynos ($100), one Standard-1X worker ($25), Essential Postgres with 1 GB of storage ($5), and Mini Redis ($3): $133 a month. The identical staging copy doubles it to $266. Note how close that is to Porter's line with entirely mid-tier dynos — and how one upgrade to a single $250 Performance-M dyno would blow straight past $300 on its own.
On Render — Starter web at $7, Standard web with 2 GB RAM at $25, managed Postgres Standard with 1 GB at about $20, Key Value Redis around $10 — production is two Standard web services ($50), one Starter worker ($7), Postgres ($20), and Redis ($10): $87 a month. Doubled for staging: $174. Render crosses later than Heroku but the shape of the curve is the same, and it steepens the moment traffic outgrows Starter tiers or the database needs the next size up.
On Fly.io the meter works differently, which is the point. Three shared-cpu Machines with 1 GB RAM run roughly $21 a month, volumes add about $5, a small Postgres Machine about $7, Redis about $3, and modest North America/Europe egress around $5: about $40 for production. An always-on staging copy doubles it to $80 — but staging that auto-stops when idle falls toward $5–10, putting the realistic total near $45. Fly.io's per-second billing with scale to zero is structurally load-following in a way dyno and instance subscriptions are not, and that is why it is the last of the three to cross.
The owned-hardware side, line by line
Now the same stack on a real fleet — not a single box, because the honest comparison with managed platforms includes high availability. Prices are Hetzner's post-June-2026 adjustment, when the dedicated CCX and shared AMD CPX lines roughly doubled while the Intel shared CX and ARM CAX lines rose about a third.
A minimal HA Cluster API fleet: three small Intel-shared control-plane nodes at roughly $14 combined, two ARM workers with 4 vCPUs and 8 GB each at about $23 combined, a load balancer near $6, block volumes and snapshots around $6, and backup space near $5. Total: about $55 a month, holding all of stack S plus staging with headroom.
Postgres and Redis here are self-operated with nightly backups and a tested restore — that is the parity assumption, and it is also where the ops-time cost below comes from. Cheaper exists: a single ARM box with 4 vCPUs and 8 GB at about $11 holds the whole stack with no HA, which is fine for staging or side projects and not the number to compare against production dynos.
The structural difference is the marginal cost. On every managed platform above, the second service and the staging copy each re-pay the full per-component meter. On the fleet, they cost nothing until the workers fill — and filling two 4-vCPU/8-GB workers takes several services beyond stack S. Managed pricing multiplies with architecture; owned hardware steps with utilization. That is the entire crossover mechanism in one sentence.
The crossover matrix, including the hours
Here is the threshold as a matrix, reusing the totals above. Each row names concrete counts; the staging pair shows the doubling instead of asserting it:
| Workload | Cheapest managed total | Owned fleet (~$55) or box | Verdict |
|---|---|---|---|
| Side project: 1 small web, no database | $3–7 (Fly idle / Render Starter / Heroku Basic) | $4–11 single box | Stay managed |
| 1 service in production: 1 web + Postgres + Redis, no staging | $20–58 (Fly ~$20 / Render ~$55 / Heroku ~$58) | ≈ break-even vs. fleet, cheaper on a box | Stay, unless staging is coming |
| Stack S, no staging: 2 web + worker + Postgres + Redis | $40–133 (Fly $40 / Render $87 / Heroku $133) | Fleet $55 | Heroku and Render cross; Fly does not |
| Stack S + identical staging | $80–266 (Fly $80 / Render $174 / Heroku $266) | Fleet $55 | Cross, except Fly with auto-stopped staging (~$45) |
| Stack S + staging + a second service | Managed roughly ×1.5–2 from the row above | Fleet +~$11 (one more worker) | Gap widens every row from here |
Now the term the matrix omits: your hours. Routine fleet ownership — monthly Kubernetes and OS upgrades, CVE patching, backup-restore drills, the occasional 2 a.m. page — runs something like 2–4 hours a month for a small, well-automated fleet. At a fully loaded $75–150 an hour, that is a $150–600 monthly shadow cost sitting next to the $55 hardware bill.
Add it honestly and the effective crossover for most teams lands around $150–250 of managed spend — below Porter's $300, because Hetzner's floor is far lower than AWS's, but far above zero, because hardware was never the whole price.
Read that way, Porter's rule and this matrix agree completely. The $300 was always hardware-floor-plus-someone-else's-ops-time with an AWS floor. Put the floor on owned hardware and the ops time on your own calendar, and the rule becomes personal: you cross over when your managed bill exceeds your hardware plus your hours times your rate. For stack S with staging, that is Heroku and Render today, Fly.io only once staging stays warm, and a second service pushes every row but Fly's over the line.
Stay or move: the checklist
Convert the matrix into decisions, keyed to its rows rather than to vibes:
- Below about $60 of managed spend with no staging on the roadmap, stay. The fleet's ops-time shadow alone exceeds any hardware saving.
- The week staging becomes a requirement, re-price. Mirrored staging is the single event that moves most teams across the line in one step.
- At the first Performance-tier (or equivalent) upgrade — one $250 dyno, one database size-up — re-price immediately. Managed curves kink at tier boundaries; that kink is usually the crossing.
- Trial credits and free tiers move the date, not the math. Credits that cover 6–12 months are a migration timer: run the matrix against month 13, when the meter starts for real. A database that expires 30 days after creation forces the same question on day one.
- Move when two rows point the same way: the current bill crosses and the next hire, service, or environment widens the gap. One crossed month is noise; a crossed trajectory is a decision.
None of this makes managed platforms a bad deal — below the line they are a very good one, which is exactly what Porter said. The $300 rule was never "Kubernetes is cheaper." It was a vendor telling you the number under which operating leverage cannot beat a meter. Recompute that number with your floor, your hours, and your staging plans, and it stops being their rule and starts being your budget.
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.



