Skip to main content

Still on Heroku? A Stay-or-Leave Framework for the Long Tail, From $5 Eco Dynos to $250 Performance-M

11 min readDora NodaDora Noda
Share
On this page

Salesforce never gave Heroku an end-of-life date. That is not a comfort — it is the whole problem. On February 6, 2026, Heroku chief product officer Nitin Bhat published "An Update on Heroku," moving the platform to a sustaining engineering model: stability, security, reliability, and support, "rather than introducing new features," with Enterprise Account contracts no longer offered to new customers. Your dynos kept running. The bill kept arriving. Nothing broke that day, which is exactly how a slow exit works: there is no deadline to plan around, only a platform quietly aging in place while you pay full price.

So here is the verdict up front, cohort by cohort — find your monthly bill shape in this table and you have your answer:

Your Heroku shapeTypical billVerdict
Eco dynos ($5) + Mini Postgres ($5)~$10–$15/moSafe to stay into 2027 if on heroku-24; migrate on the next stack sunset
Basic dyno ($7) + Essential Postgres ($5–$9)~$12–$25/moStay while steady; move when you need a second process or previews
Standard-1X/2X ($25–$50) + Standard-0 Postgres ($50)~$100–$200/moMigrate in the next 1–2 quarters; you pay 3–5x the alternatives
Performance-M ($250) or deeper$300+/moMigrate now; no Enterprise path exists and the premium buys nothing new

The rest of this post substantiates every cell: what "sustaining" has already stopped shipping, why the database — not the dyno — usually sets your migration date, and which workloads are genuinely safest to leave longest.

What sustaining mode has already stopped shipping​

The February announcement was narrow and checkable. No new features. No new Enterprise contracts for new customers — existing ones are honored and may renew, but if your company is not already an Enterprise customer, there is no path to becoming one at any price. Pay-as-you-go continues unchanged. Analysts read it plainly: The Register's headline was "Salesforce puts Heroku out to PaaSture," Janakiram MSV called it dying in slow motion, and Simon Willison noted his blog was his only project left on the platform.

More important than the announcement is the decay order it confirmed — what stops first when a platform ages in place:

  1. Dead stacks stop building. Heroku-20 reached end of life in April 2025, and the terms were brutal in a specific way: apps on it keep running but receive no security updates, and no new builds — no code deploys at all — until the app upgrades. Heroku-22 is supported through April 2027, Heroku-24 (the default) through April 2029, with Heroku-26 arriving as the next runway. Every stack sunset is now a forced migration rehearsal on someone else's schedule.
  2. The new generation ships incomplete. Fir, generally available since April 2025, still does not support Docker deploys — the Container Registry remains Cedar-only. Cloud Native Buildpacks only reached Cedar-generation apps in September 2026. Gaps like these are what "no new features" looks like in practice: not a freeze, but a drip.
  3. Ecosystem changes land on your backlog. Heroku's September 2026 TLS cipher cull forced legacy-client audits on tenants. Each runtime EOL, cipher-suite change, or buildpack lag is now your incident to manage, not the vendor's roadmap item.

Note the shape of this list: nothing in it turns your app off. Everything in it raises the cost of staying — in toil, in risk, in features you cannot buy. That is why "no EOL date" is a trap rather than reassurance. The question was never whether Heroku disappears; it is what staying costs while the platform stops keeping up.

The four cohorts of the long tail​

Sustaining mode punishes waiting unevenly, and the fault lines run along three variables: how many dynos you run, how entangled your Postgres and add-ons are, and how much ops capacity you have. Those three keys sort nearly every remaining Heroku account into four cohorts.

Cohort A: Eco hobbyists​

One Eco dyno ($5/month, sleeps after 30 minutes of inactivity, 1,000 shared dyno hours) plus a Mini Postgres ($5) or Mini Key-Value Store ($3) — roughly $10–$15/month all-in. Side projects, prototypes, student apps, the personal blog its owner keeps meaning to move.

This cohort feels sustaining mode last. A sleeping dyno serving a side project does not care about the Enterprise door closing or Fir's missing Docker support. Your forcing events are stack sunsets — heroku-22 in April 2027 at the latest — and runtime EOLs that outpace your willingness to bump a version.

Verdict: staying is rational. Keep the app on heroku-24, keep runtimes current, and treat each stack sunset as the scheduled moment to reconsider. When you do move, the destination barely matters at this size: Render's free tier (750 hours, sleeps after 15 minutes) or a ~$7 Starter, Railway's $5 Hobby subscription with included usage, and Fly.io's pay-as-you-go from under $2/month for a small shared machine all land within a few dollars of your current bill. The cheapest honest move is often Render's free tier at $0 — the only cohort where migration can cut the bill to zero.

Cohort B: Basic always-on​

A Basic dyno ($7/month, always-on, single instance, no autoscaling, no metrics) with an Essential-0 ($5) or Essential-1 ($9) Postgres — roughly $12–$25/month. Small client sites, internal dashboards, indie SaaS before traction.

The Basic tier's limits — one instance, no horizontal scaling — are the actual constraint here, and sustaining mode freezes them in amber. Nobody is coming to add autoscaling to Basic. The moment you need a second process, a worker, preview environments, or real metrics, you are not upgrading within Heroku so much as re-buying the decision: a second $7 dyno plus a $20 Essential-2 Postgres doubles the bill while the alternatives price the same shape at $13–$26 (Render Starter web plus Basic Postgres is about $13; Railway Hobby lands near $26 for app plus Postgres).

Verdict: stay while the app is genuinely one process and steady. The trigger to leave is growth-shaped: the second process, the first preview environment, the first time someone asks "can we see metrics." Migrate then, not before — a stable single-dyno app on heroku-24 is among the safest things to leave longest.

Cohort C: Standard production​

This is the long tail's center of gravity and the cohort overpaying hardest: Standard-1X ($25) or Standard-2X ($50) dynos, usually a web plus a worker, Postgres Standard-0 ($50, 64 GB, no high availability), often a Redis add-on — roughly $100–$200/month. Small-team production SaaS, agency client apps, the startup that set this up in 2021 and never revisited it.

Run the numbers on the canonical shape — two Standard-1X dynos ($50), Standard-0 Postgres ($50), a small Redis ($15–$30): $115–$130/month on Heroku. The same shape is about $31/month on Render (two $7 Starters, $7 Postgres, $10 Key Value), $15–$33/month on Railway or $11–$19/month on Fly.io at metered usage, and roughly €4.51 (~$5) in raw hardware on a Hetzner CX22 before your ops time. Staying costs three to ten times the alternatives — a premium that used to buy the best git-push DX in the industry and now buys a platform that has publicly stopped investing.

Worse, this cohort sits exactly where sustaining mode bites: old enough to carry Cedar-era assumptions, big enough that every stack sunset and cipher cull is a real incident, small enough that nobody is assigned to watch the vendor. Heroku Connect users are the exception that proves the rule — if your Salesforce integration runs through Connect, you have no good replacement and should weight that entanglement above the bill.

Verdict: migrate in the next one to two quarters, on your schedule, before a stack sunset or runtime EOL picks the schedule for you. Destination by temperament: Render for the shortest conceptual move (Heroku buildpacks work directly, plus an official heroku-import CLI plugin), Railway for usage-based velocity, Fly.io for control and multi-region. The mechanics — Procfile to manifest, add-ons, secrets, rehearsed Postgres cutover — are covered in depth in The Heroku Exit Playbook; budget a weekend for a standard app.

Cohort D: Performance production​

Performance-M ($250, 2.5 GB RAM) and up — L at $500, XL at $750, 2XL at $1,500 — with Standard-2 ($200) or Premium Postgres, for $300+/month and climbing. This is real production traffic on Heroku in late 2026, and it faces the hardest constraint in the whole framework: if procurement requires an Enterprise agreement and you do not already have one, Heroku cannot sell it to you. No renewal conversation, no committed-support tier, no custom terms. For regulated or customer-trust-sensitive teams, CVE response cadence on a skeleton crew is the documented risk sitting under that missing contract.

The math is also the most lopsided. A single Performance-M dyno ($250) plus Standard-2 Postgres ($200) is $450/month before workers, Redis, or logging — a shape that prices at $60–$175/month on Render, Railway, or Fly.io at techsy.io's 2026 "growth tier" benchmarks, or fits comfortably on one Hetzner box. At this size the Heroku premium is not a convenience fee; it is a second infrastructure budget spent for nothing.

Verdict: migrate now. The only defensible reason to stay is deep Heroku Connect or Private Space entanglement with a migration already scheduled — and "scheduled" means a quarter on the calendar, not a vague intention.

The entanglement multiplier: it is the database, not the dyno​

Across all four cohorts, one pattern decides actual migration dates: teams estimate the move by counting dynos and then discover the database sets the timeline. Heroku's Postgres ladder has cliffs, not slopes — $5 Mini to $50 Standard-0 to $200 Standard-2 and beyond — and each step up deepens the entanglement: larger datasets lengthen the pg_dump/pg_restore cutover window, followers and HA configurations have to be rebuilt on the target, and Postgres extensions or Heroku-specific backup tooling need equivalents.

So before trusting any verdict above, score your entanglement:

  • Low: Mini or Essential Postgres under a few GB, no followers, Redis is cache-only. Cutover is a rehearsed dump and restore; outage window in minutes.
  • Medium: Standard-0 Postgres, a follower or scheduled backups you rely on, Redis holding sessions or queues. Budget a sprint; rehearse the cutover twice.
  • High: Standard-2 or Premium Postgres, Heroku Connect syncing to Salesforce, Scheduler or Kafka add-ons woven into app logic. The database and add-ons are the project — the dynos are the easy part. Connect in particular has no good replacement; teams bound to it should plan the longest runway and treat Heroku as a Salesforce-adjacent runtime, not a PaaS choice.

Ops capacity multiplies everything. A team with no one to own Postgres backups should not self-host the database on a Hetzner box to save $45/month — that trade converts a billing problem into a pager problem. The honest Hetzner comparison is hardware plus your ops time, and for teams without that time, managed Postgres on Render ($7–$9 Starter/Basic) or Railway is the correct destination even though it costs more than a volume on a VPS.

Safest to leave longest​

Two shapes can stay with the least regret. First, steady-state internal tools on heroku-24 with current runtimes and no Enterprise need: no growth, no new processes, nothing that needs the vendor to move. Schedule the move deliberately — each stack sunset is the natural review point — but there is no fire. Second, Heroku Connect-bound Salesforce shops, where leaving means re-platforming an integration, not an app; here Heroku is infrastructure you rent from your CRM vendor, and the bill is Salesforce's ecosystem tax.

Everyone else is paying a premium that grows in two currencies at once: dollars on the invoice, and toil every time the ecosystem moves and the vendor doesn't. Migrate on your own schedule in the next one to two quarters. Do not wait for a forcing event — sustaining mode's whole design is to never give you one, right up until a stack sunset or a CVE does.

Running the numbers on your own Heroku bill? 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.

Related articles

Check your move before you migrate

Free browser tools: check a render.yaml or your Render scripts against bex, or turn a Heroku app or docker-compose.yml into a draft render.yaml. Nothing you paste leaves your browser.

Open the migration tools