Is Heroku shutting down? What sustaining engineering means

TL;DR

• What you get: a plain answer to "is Heroku going away?", what changed on 6 February 2026, a 10-question checklist to decide whether to stay or move, and a dated price table for the same app on 5 platforms.
• Who it's for: anyone running a production app on Heroku who saw the news and isn't sure whether to act.
• Time needed: 10 minutes to read, 20 minutes to run the checklist against your own app.
• Short answer: Heroku is not shutting down. Nothing is forcing you to move this year. But if you're on the heroku-22 stack, you have a real deadline in April 2027 either way.

Your app has run on Heroku for years. Then a headline says Heroku is in "maintenance mode", and your team chat fills up with "do we need to migrate?". Moving a production app is risky and expensive. Moving too late, in a panic, is worse.

This guide helps you decide calmly. You'll learn exactly what Heroku announced, what it does and doesn't change, how to score your own app's risk in 20 minutes, and what the same app costs on Heroku and four alternatives, with prices read on 4 November 2026. If the answer is "move", you'll also see the cheapest safe way to try it first.

Try it on Hubfly space: the free tier gives you 360 compute hours a month with no card, enough to run a copy of your app next to Heroku before you decide anything.

What Heroku announced, in plain words

On 6 February 2026, Heroku published An Update on Heroku. It said three things:

1. Heroku is moving to a "sustaining engineering model". The focus is stability, security, reliability and support, "rather than introducing new features".
2. Nothing changes for card-paying customers. Pricing, billing, service and day-to-day use stay the same, for existing and new customers who pay by card. Apps, pipelines, teams and add-ons keep working.
3. Enterprise Account contracts are no longer offered to new customers. Existing Enterprise contracts are honoured and can renew.

The reason given: Heroku is putting its investment into other areas, including helping organisations build enterprise AI securely.

What "sustaining engineering" means in practice

Think of a car model that's still sold and serviced, but won't get a redesign. You still get oil changes, recalls and safety fixes. You don't get a new dashboard.

For your app, that means:

• Security patches and OS updates keep coming. The Heroku stack page lists the newest stack, heroku-26, as supported until April 2031.
• Your bill doesn't change. The Heroku pricing page still shows Eco at $5, Basic at $7 and Standard-1X at $25 a month.
• Fewer big new features. The roadmap is about keeping things running, not chasing what newer platforms ship.

What it does not mean

It's not a shutdown, and nobody announced an end date. To be fair to Heroku, it's also not a freeze. Heroku's own October 2026 update lists Heroku Postgres Advanced (a new database tier), Cloud Native Buildpacks for Cedar apps, and Postgres 18 as the default on every database tier. The pace is slower and more focused, but work continues.

So the honest summary is: Heroku is a stable, slower-moving platform now. For many apps, that's fine. For some, it's a reason to plan an exit on your own schedule.

The one deadline that matters either way

Before you debate staying or leaving, run this:

heroku stack -a your-app

If the active stack is heroku-22, note the date. The stack page lists heroku-22 as deprecated, end of life April 2027. You'll need to upgrade to heroku-24 or heroku-26 before then, which can mean code and dependency changes.

That's useful for planning. An upgrade is already a chunk of work that touches your build. If you were going to move platforms within a year, it may be cheaper to do it once, instead of upgrading the stack now and migrating later.

Stay or move? A 10-question checklist

Score each question for your app. Give yourself 2 points for each "yes" and 0 for each "no". A "yes" points toward moving. Be honest; nobody else sees this.

#	Question	Why it matters
1	Is the app on heroku-22 (or older)?	You must touch the build before April 2027 anyway.
2	Are you waiting on a feature Heroku doesn't have (more regions, GPUs, bigger dynos for less money)?	Under sustaining engineering, don't plan around it arriving.
3	Is your Heroku bill a noticeable share of your costs?	Same-size apps cost less elsewhere (see the table below).
4	Were you hoping to sign a new Enterprise contract?	New Enterprise contracts are no longer offered.
5	Is your app containerised already (Dockerfile, or easy to add)?	Moving is mostly config work then, not a rewrite.
6	Do you have fewer than 5 add-ons?	Each add-on is something to replace or re-wire.
7	Is your database under 10 GB?	pg_dump and restore in minutes, not hours.
8	Can you accept a short maintenance window (10–30 min)?	A planned cutover is far simpler than zero-downtime.
9	Does someone on the team have a free week in the next quarter?	Migrations fail when they're squeezed between other work.
10	Is your app not tied to Salesforce (Heroku Connect, Salesforce data sync)?	Those integrations are Heroku's real moat. Leave them alone if you depend on them.

How to read your score:

• 0–6: stay. Heroku still works, your bill is stable, and moving would cost more in time than it saves. Upgrade your stack, set a calendar reminder to rerun this in 6 months, and get on with your product.
• 8–12: plan, don't rush. Run a copy of your app on one alternative this quarter. Compare cost, deploys and logs side by side. Move when it's boring, not when it's urgent.
• 14–20: move this quarter. You're paying for a platform that won't grow with you, and the move is cheap for your app's shape. Pick a quiet week and do it.

If question 10 is a "no" for you (you depend on Heroku Connect), take 4 points off your total. Replacing that integration is a project of its own, and it's where Heroku is strongest.

What the same app costs on 5 platforms (November 2026 snapshot)

Here's a typical small production app: one web process, one background worker, and a small Postgres database, all always on. Prices were read on each platform's official pricing page on 4 November 2026.

Platform	Web	Worker	Postgres	Monthly total
Heroku (dynos, Postgres)	Basic, 0.5 GB: $7	Basic, 0.5 GB: $7	Essential-0, 1 GB: $5	$19.00
Render (pricing)	512 MB instance: $7	512 MB instance: $7	256 MB, 1 GB storage: $6	$20.00
Railway (pricing)	usage-based	usage-based	usage-based + 1 GB volume	≈ $10.81 (see assumptions)
Fly.io (pricing)	shared-cpu-1x 512 MB: $3.69	shared-cpu-1x 512 MB: $3.69	Managed Postgres Basic: $38 + 1 GB at $0.28	$45.66
Hubfly space (pricing)	0.5 vCPU / 512 MB: $2.23	0.5 vCPU / 512 MB: $2.23	Managed PostgreSQL Nano (0.25 vCPU / 512 MiB / 10 GiB): $2.02	$6.48

How the totals are worked out:

• Heroku: $7 + $7 + $5 = $19.00.
• Render: $7 + $7 + $6 = $20.00 on the free Hobby workspace. Render's background workers use the same instance prices as web services.
• Railway: Railway bills what you actually use: $0.00000772 per vCPU-second ($20.29 per vCPU for a 730-hour month), $0.00000386 per GB-second of RAM ($10.14 per GB-month), and $0.00000006 per GB-second for volumes ($0.16 per GB-month). Assume each of the 3 services averages 0.05 vCPU and 0.25 GB of RAM: (0.05 × $20.29) + (0.25 × $10.14) = $3.55 per service, × 3 = $10.65, plus a 1 GB volume at $0.16 = $10.81. The Hobby plan's $5 a month includes $5 of usage, so the bill is $10.81. A busier app costs more; a quieter one less.
• Fly.io: $3.69 × 2 + $38 + $0.28 = $45.66. Fly's own example notes that Managed Postgres is most of a small app's bill. You can run Postgres on a plain Machine for less, but then backups and upgrades are your job.
• Hubfly space: compute is $0.004 per vCPU-hour and $0.002 per GB-hour of RAM, over 730 hours. One 0.5 vCPU / 512 MB service with 4 GB of disk: (0.5 × 0.004 × 730) + (0.5 × 0.002 × 730) + (4 × 0.00001536 × 730) = $1.46 + $0.73 + $0.04 = $2.23. Two of them plus Managed PostgreSQL Nano at $2.02: $2.23 + $2.23 + $2.02 = $6.48.

Where each platform wins

Price isn't everything, so here's the fair version:

• Heroku wins on maturity and ecosystem: the add-on marketplace, pipelines, Heroku Scheduler for cron-style jobs, and deep Salesforce integration. If those carry your app, staying is reasonable.
• Render wins if you want something that feels most like Heroku, with point-in-time recovery on Postgres (3 days on Hobby, 7 days on paid plans) and up to $10K in migration credits, per its pricing page.
• Railway wins for spiky or mostly idle apps, because you pay for real usage, not reserved size.
• Fly.io wins when you need your app close to users in many regions.
• Hubfly space wins on price for always-on small services, and you can run apps, databases, file storage and email from one account. Be clear on the trade-offs: for Managed PostgreSQL, automatic backups are still marked "coming soon", and there's no built-in scheduler like Heroku Scheduler yet. If you need automatic database backups on day one, Render or Heroku is the safer choice for the database today.

For a deeper side-by-side, see Best Heroku alternatives in 2026: 7 options and what they cost and Heroku vs Render vs Railway vs Hubfly space: 4 prices for one app + Postgres. If you can't decide between fixed and usage-based billing, Fixed vs pay-as-you-go hosting: find your break-even point does the maths.

If you decide to move: the low-risk way

Don't migrate in one go. Run both side by side first. For the full walkthrough with commands, see Migrate from Heroku without losing jobs.

1. Freeze the app's shape. Write down every process in your Procfile (web, worker, release), every add-on, and every config var. Run heroku config -a your-app --shell > heroku.env to export the config vars. That file holds secrets, so keep it out of Git.
2. Containerise it. If you don't have a Dockerfile yet, add one now. It removes the biggest difference between platforms. A Dockerfile in the repo root is picked up automatically on Hubfly space.
3. Rebuild the Procfile as a Compose file. Each process becomes a service. The release command becomes a one-off job that must finish before web starts. On Hubfly space, a service with restart: "no" imports as a Job, and depends_on with service_completed_successfully makes web wait for it.
4. Copy the database. Take a fresh backup with heroku pg:backups:capture, download it with heroku pg:backups:download, and restore it into the new database with pg_restore (Heroku's import and export guide shows the exact flags). Do a dry run first and check row counts on your biggest tables.
5. Run the copy for a week. Point a staging domain at the new app. Compare deploy time, logs and the real bill.
6. Cut over in a quiet window. Put the Heroku app in maintenance mode, take a final backup, restore it, switch DNS, and keep the Heroku app around for a few days in case you need to roll back.

What can go wrong

1. You treat "sustaining engineering" as "shutting down" and rush. A rushed migration is how data gets lost. Fix: run the checklist, and if your score is under 8, stay and revisit in 6 months. Nothing in the announcement forces a date on you.

2. You forget the stack deadline. You decide to stay, then heroku-22 reaches end of life in April 2027 and builds start failing. Fix: run heroku stack -a your-app today and put the upgrade on the calendar.

3. Workers lose jobs during the cutover. If an old worker on Heroku and a new worker elsewhere both read from the same queue, or the old one is killed mid-job, jobs vanish. Fix: maintenance mode on Heroku doesn't stop worker dynos, so scale them to zero after the queue is drained (heroku ps:scale worker=0 -a your-app), then start workers on the new platform.

Takeaway

Heroku isn't going anywhere soon. It's a stable platform that's stopped racing. That's a fine place to run an app that doesn't need new features. Your real decisions are smaller and more concrete: upgrade off heroku-22 before April 2027, and use the 10-question checklist to decide whether that upgrade is also the moment to move.

If you score high, try the move on your own schedule. Run a copy for a week, compare the bills, and only then switch DNS.

Next step: price your own app. In the Hubfly space dashboard, Create Container shows the monthly cost live as you move the CPU and RAM sliders. Start with 0.5 vCPU and 512 MB per process, add a Nano database from the pricing page, and compare the total to your last Heroku invoice. To run a copy for free, create a Hubfly space account; the free tier needs no card.

Go further on Hubfly space

• Get a managed database for about $2 a month: How to get a managed PostgreSQL database for about $2 a month.
• Bring your whole Compose file: Deploy a docker-compose.yml as-is: 8 platforms compared.
• Deploy automatically on every push: How to deploy on every push with GitHub Actions and a webhook.