Heroku Dyno Math in 2026: What $50 Standard-2X and $250 Performance-M Bills Buy Against Owned Hetzner Hardware

Heroku is in sustaining mode. Your renewal isn't. Since February 6, 2026, Salesforce has run Heroku as a sustaining-engineering platform — stability, security, and support, but no new features and no new Enterprise contracts. The dynos keep billing, though: $50 a month for a Standard-2X, $250 a month for a Performance-M, at the same list prices Heroku has charged for years. The question a September 2026 renewal writeup puts bluntly is what those dollars actually buy now that the platform they rent has no roadmap — and what they'd buy pointed at hardware you own instead.

This post works that math twice, once per tier: a typical Standard-2X stack and a typical Performance-M stack, each priced line by line, each set against an owned-Hetzner equivalent, each with an exit sketch and the month the move pays for itself. All Heroku figures below are published list prices; Hetzner figures are post–June 2026 repricing.

The two bills, priced as stacks​

Nobody pays for a dyno alone. A production Heroku app is a stack — web dynos, a worker, Postgres, Redis, and the staging and review-app spend that never makes it into the headline comparison. Here are two typical shapes.

The Standard-2X app. A small production Rails, Django, or Node service: one web dyno and one worker at Standard-2X ($50 each, 1 GB RAM, shared 2x CPU), Postgres Standard-0 ($50, 64 GB storage), the entry Redis plan ($15), and roughly one review app plus a staging dyno active at any given time (~$25–30). That sums to just under $200 a month:

The Performance-M app. The same architecture one growth stage up: two Performance-M web dynos and one worker ($250 each, 2.5 GB RAM, dedicated CPU), Postgres Standard-2 ($200), and a mid-tier Redis plan ($60). Add log retention and metrics beyond the free allowance ($50) plus staging and review apps (~$100). Total: roughly $1,160 a month.

These are deliberately ordinary setups — no Performance-L fleet, no Shield compliance markup, no data-transfer surprises. Keep both totals in mind: ~$190 and ~$1,160. Everything below divides into one of those two numbers.

What the same dollars buy on Hetzner​

The owned-hardware anchor for both tiers is one Hetzner dedicated box. An AX42 — 8 cores / 16 threads on a Ryzen 7 PRO, 64 GB of DDR5, 2 × 512 GB NVMe — lists around €47–57 a month after the June 2026 repricing, roughly $50–60. Its sibling AX52 (same CPU class and RAM, 2 × 1 TB NVMe) runs about €64, roughly $70.

Read that twice: a single $55 box carries 64 GB of RAM — twenty-five times the combined memory of the Performance-M stack above — with dedicated cores and local NVMe that no shared dyno tier matches.

Both example stacks fit on one AX42 with headroom to spare; the AX52 only matters if the database wants the extra terabyte of NVMe.

The honest Hetzner-side stack needs more than the bare box, so price it fully:

The monthly deltas fall straight out:

• Standard-2X tier: ~$190 → ~$65, saving ~$125/month (about two-thirds).
• Performance-M tier: ~$1,160 → ~$80–105, saving ~$1,055–1,080/month (over 90%).

Two caveats before the exit sketch. First, Render and Fly.io sit in the same per-instance band as Heroku's low end — Render Standard is $25 for 1 CPU / 2 GB, Fly.io shared with 2 GB runs about $16 — so if the goal is only to shave the compute line, re-platforming to another metered PaaS saves tens of dollars, not hundreds. The order-of-magnitude delta comes from leaving metered compute, not from switching meters. Second, the Hetzner column assumes the team absorbs ops — patching, backups, on-call. That labor is real, and it's exactly what the break-even section prices.

The exit sketch, per tier​

Knowing the delta is half the decision; the other half is what happens to each Heroku primitive on the way out. The mappings differ by tier, because the tiers are buying different things.

Standard-2X team: map to a Render-compatible API first. A two-dyno app with standard add-ons wants git push to keep working, not a Kubernetes education. The sketch:

• Web + worker dynos → services on a Render-compatible API (Render itself, or a self-hosted Render-compatible platform on the Hetzner box), keeping the Procfile process model.
• Buildpacks → Cloud Native Buildpacks or a checked-in Dockerfile; most Heroku buildpack apps build unchanged under Paketo.
• Postgres Standard-0 → pg_dump from Heroku, restore into in-cluster Postgres or a $25 managed alternative; at 64 GB and under this is an afternoon, not a project.
• Redis → in-cluster Redis; nothing about a cache requires a managed plan at this scale.
• Review apps + staging → preview environments per pull request, which every Render-compatible platform and self-hosted PaaS now ships natively.
• Scheduler, metrics, logging → cron-job spec in the app manifest, and the platform's built-in log tail; Papertrail-scale retention is a solved commodity.

Performance-M team: split the workload. Performance dynos are dedicated-CPU machines, and the workloads paying for them usually split into stateless web/worker processes (which map to the same Render-compatible API) and the stateful or compliance-sensitive pieces that deserve raw Kubernetes: Postgres with real backup and failover policy, Redis with persistence, and any workload whose noisy-neighbor isolation the team was implicitly buying with dedicated dynos. On a single AX52 that split is one small cluster, not two infrastructures — but draw the line deliberately, because "everything as stateless services" is how the database's backup story gets forgotten until the first incident.

In both sketches the database moves first and the traffic moves last: dump and restore, dual-write or read-replica catch-up if downtime matters, then cut the DNS over. The migration pattern is the same one every Heroku-to-DigitalOcean or Heroku-to-AWS guide has used for a decade; only the destination changed.

The break-even month​

Hardware savings are monthly; migration costs are once. The break-even month is the one-time migration cost divided by the monthly delta — and the honest version shows the range, because migration labor varies more than any price list.

Read the Standard-2X row carefully: at ~$125 a month saved, a paid migration takes one to two years to pay back. The DIY weekend is the only fast payback at this tier — which is fine, because the Standard-2X sketch above genuinely is a weekend. The Performance-M row is the mirror image: even the cautious $6,000 cutover pays back in half a year, and anything leaner lands in the first quarter.

And then there's the case worth calling out specifically: the team paying Performance-tier prices for a dyno that mostly idles. A single Performance-M web dyno ($250) plus Postgres Standard-0 ($50) and entry Redis ($15) is $315 a month for 2.5 GB of mostly-idle RAM — a box one-twentieth the size of an AX42's memory, billed at five times the AX42's price. That stack's delta (~$250/month against a ~$65 Hetzner replacement) breaks even on a contractor migration in month 2. Idling is the most expensive workload shape on metered PaaS: utilization-based pricing charges for capacity while owned hardware charges for the box, and an idle dyno is pure capacity. If any single dyno in the fleet averages under 20% CPU, it is subsidizing the exit of everything around it.

When staying is the right call​

None of the above means every Heroku team should leave. Three reasons to stay survive the math: deep Salesforce integration that no self-hosted platform replicates, compliance postures (Shield, BAA-adjacent controls) whose audit cost dwarfs the dyno bill, and the genuine zero-ops premium — a team with no one willing to own backups and on-call is buying insurance, not compute, and should price it as insurance. What sustaining mode removed is the fourth reason people used to stay: the expectation that the platform would keep improving. That expectation now has a date on it — February 6, 2026 — and every renewal after that date is a vote for the status quo at full price.

For everyone else, the ledger is the pitch: one $55 box replaces both example stacks combined, the database moves in an afternoon, and the break-even lands somewhere between next month and next year depending on tier and temperament. The dyno was a great abstraction for fifteen years. Owning the machine underneath it is the next one.

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.