Dora NodaOn February 6, 2026, Heroku's chief product officer published a short post titled "An Update on Heroku" that made official what the industry had whispered for years: the platform that invented git-push deploy is transitioning to a sustaining engineering model. No new features. No new Enterprise contracts. The Register's headline for the story was characteristically blunt: "Salesforce puts Heroku out to PaaSture."
If your team still deploys there, the announcement changes nothing about today and quite a lot about every planning conversation after today. Heroku works right now, and Salesforce says it will keep working. What froze is the roadmap. This post is a concrete read of what that freeze covers, the clocks that will actually force your hand, what a typical app costs on a frozen platform versus its successors, and a decision framework for stay, plan, or move.
Here is what Heroku actually announced, in the post's own operative terms:
- Sustaining engineering model. The platform is now run for "stability, security, reliability, and support," with "an emphasis on maintaining quality and operational excellence rather than introducing new features."
- No change for dashboard customers. Teams paying by credit card in the Heroku dashboard — existing and new — see no changes to pricing, billing, service, or day-to-day usage. Apps, pipelines, teams, and add-ons are unaffected, and Heroku says customers can keep relying on it for production workloads.
- Enterprise door closed to newcomers. Enterprise Account contracts will no longer be offered to new customers. Existing Enterprise subscriptions and support contracts "will continue to be fully honored and may renew as usual." Product and engineering investment is being redirected toward enterprise-grade AI elsewhere in Salesforce.
That third bullet is the tell. This is not a pause; it is a reallocation of the team that would have built Heroku's future.
What "sustaining engineering" freezes: the concrete inventory
"Sustaining mode" sounds gentle, so translate it into a keeps-versus-frozen table and read the frozen column as permanent:
| Still shipping | Frozen |
|---|---|
| Security patches and stack security updates on supported stacks | New platform features of any kind |
| Uptime, reliability work, and support | New regions (US/EU on AWS is the final map) |
| Renewals of existing Enterprise contracts | New Enterprise Account contracts |
| Existing apps, pipelines, teams, add-ons running as-is | New language runtimes, buildpack generations, or integrations |
| Compliance posture of what exists today | Any response to competitive pressure |
Two rows deserve emphasis. First, Heroku's sharp edges are now load-bearing walls: the 30-second router timeout, daily dyno restarts, AWS-only infrastructure, and the US/EU region list will never improve, because improvement is a feature and features are frozen. If any of those already hurts, no relief is coming from the vendor. Second, "existing add-ons unaffected" describes Heroku's side of the catalog; every partner-maintained add-on follows its own roadmap, and partners invest where growth is.
None of this arrived out of nowhere. Salesforce bought Heroku for $212 million in 2010, and the investment slope since has pointed one way: an April 2022 breach involving stolen OAuth tokens damaged developer trust, the free tier was shut down on November 28, 2022, feature development visibly slowed through 2023–2025, and a major June 2025 outage further eroded confidence. February's announcement formalized the trajectory; it did not start it.
The forcing functions: what will actually push you off, and on what clock
Nothing breaks today. That is precisely why sustain mode is dangerous to plan around: the pressure arrives as a set of slow clocks, not an incident. Here are the five, ordered by how concrete their deadlines are.
1. Your stack's EOL date. Heroku stacks track Ubuntu LTS releases, and the stack update policy has real teeth: when a stack reaches end of life, apps on it keep running but stop receiving security updates — and no new builds can be performed until the app is upgraded to a supported stack. That is the Heroku-18 precedent from May 2023, and it is the shape every future stack deadline takes. Sustain mode keeps security updates flowing on supported stacks, but a whole new stack generation is uncomfortably close to a "new feature," which makes your current stack's EOL the single most important date on your Heroku calendar. Look it up this week.
2. Managed-data version EOLs. Heroku Postgres and Heroku Data for Redis follow upstream PostgreSQL and Redis end-of-life schedules. Major-version upgrades are forced marches with vendor-published deadlines, extension-compatibility work (PostGIS, pgcrypto, and friends), and downtime windows to plan. Sustain mode does not pause upstream EOLs; if anything, running each forced upgrade on a platform with a shrinking team is the risk compounding over time.
3. Add-on catalog drift. Retirements and partner deprioritizations do not need Heroku's permission. Audit every add-on you depend on — logging, monitoring, email, queues — for vendor health, not just current function. An add-on whose maintainer has stopped investing is a migration you will do under time pressure later instead of on your schedule now.
4. Growth walls you cannot buy your way through. This is the Enterprise bullet with teeth. The day your security review requires Private Spaces-style isolation, Shield-level compliance features, or contract terms available only on an Enterprise plan — as a new buyer, that contract no longer exists. Same for a region Heroku never shipped: your EU data-residency requirement or APAC latency problem is now permanently yours to solve elsewhere. Growth into enterprise needs is the most common way "it still works" becomes "we needed to leave six months ago."
5. Hiring and morale drag. Every engineer you hire from now on learns a platform the industry press describes in past tense. That shows up as slower onboarding (tribal buildpack knowledge instead of living docs), raised eyebrows in interviews, and the quiet tax of explaining to each new hire why the deploy target is a platform its owner stopped investing in.
The money: a typical small production app, costed honestly
Cost was already a migration driver before February — the free tier's removal in 2022 saw to that — but sustain mode reframes the bill: you are now paying full price for a platform guaranteed never to improve. Anchor the comparison on a typical small production setup, using a published 2026 estimate of its Heroku cost: two Standard-1X dynos ($50), Postgres Standard-0 ($50), Redis Mini ($15), and routine add-ons for monitoring and logging ($15–30). Total: roughly $130–165 per month.
| Destination | Same small-production footprint | Notes |
|---|---|---|
| Heroku (frozen) | ~$130–165/mo | 2× Standard-1X + PG Standard-0 + Redis + add-ons |
| Render | ~$38+/mo | Closest Heroku-style DX; web service from $7, managed Postgres from $7 |
| Railway | ~$20–30/mo | Usage-based; fastest onboarding of the managed options |
| Fly.io | ~$15–35/mo | Usage-based; multi-region by default |
| Self-hosted (Hetzner + Coolify/Dokploy) | ~€15–40/mo | Whole footprint on one box; marginal cost per extra app near zero |
Read the sensitivity, not just the row: the gap scales with dyno count and data tier. At Standard-2X ($50 each) or Performance dynos ($250–500 each), the multiple gets worse fast, and the $50 entry fee for production-grade managed Postgres dominates every small bill.
Two honest caveats cut the other way. First, managed successors reintroduce per-service metering, so a sprawling microservices footprint can surprise you the same way dynos once did — price your actual topology, not the marketing page. Second, self-hosting trades the bill for ops time: patching, backups, and on-call become yours. For a team already running infrastructure, that trade is usually a win; for a team of three with no ops appetite, Render or Railway is the honest answer.
Stay, plan, or move now: the decision framework
Sustain mode raises the priority of your migration decision (the roadmap is now a known-frozen variable) without raising its urgency (nothing breaks today) — except for teams already at a wall. Sort yourself:
Stay — consciously. Your app is small, stable, and profitable. Standard dynos, a modest Postgres, no Enterprise needs on the horizon, no new-region requirements, and a team that already knows buildpacks. Staying is rational, but make it deliberate: calendar your stack EOL and Postgres version EOL, keep the app twelve-factor clean so the exit stays cheap, and revisit yearly. "Still works" is a fine strategy only while someone is watching the clocks.
Plan now, move on your schedule. You are hiring, approaching compliance or Enterprise needs, bumping into the 30-second timeout or the region list, or watching an add-on wobble. The move is a matter of when, so buy the option cheaply: pick a destination this quarter, run staging there, rehearse the data cutover once. A rehearsed migration is a routine project; an unrehearsed one under a stack-EOL deadline is an incident with a marketing page.
Move now. You are already blocked — you need an Enterprise contract you can no longer buy, a region that will never ship, a runtime Heroku lacks — or the bill is scaling faster than revenue, or a dependency you rely on is visibly rotting. Every month of delay is full price for zero roadmap progress plus interest on the eventual cutover.
The failure mode to avoid is the middle disguised as the top: "we'll stay for now" with no clocks calendared and no destination picked. That is not staying; it is drifting toward a forced migration at the worst possible time.
If you move: the sequencing that avoids the big-bang rewrite
Heroku migrations are operationally forgiving for one reason: Heroku's model won. Every successor copied dynos, config vars, pipelines, and git-push deploys, so the migration is mostly vocabulary translation, not re-architecture. Sequence it smallest-blast-radius first:
- Inventory everything. Dynos and formation, buildpacks, config vars, add-ons, pipeline stages and review apps, schedulers, and your Postgres version plus extensions. The things teams forget — a scheduler job, a review-app pipeline, one extension — are the things that page you at 2 a.m.
- Move the stateless tier first. Web and worker dynos go to the destination while Heroku Postgres stays primary; point the new services at the existing database over external connections. This validates the new platform with a one-line rollback.
- Cut the data over deliberately. For small databases, pg_dump and pg_restore during a maintenance window is fine. For anything larger, stand up a follower or read replica on the destination and promote it, with extension parity verified before cutover, not after.
- Move Redis and sessions last. Session stores and caches are the state everyone underestimates. Verify session behavior across the cutover — log out every user once rather than debugging split-brain sessions for a week.
- Cut DNS with a rollback window. Shorten TTLs a day ahead, switch over, and keep the Heroku app warm for one full billing cycle as instant rollback. Delete it only after you have survived a deploy, a failover drill, and an invoice on the new side.
Destination choice follows team shape, not feature matrices: Render for the closest Heroku-flavored experience, Railway for the fastest path from git push to URL, Fly.io when multi-region matters, and self-hosted Coolify or Dokploy on a Hetzner box when you want the meter to stop entirely.
The first PaaS endgame is now explicit
Heroku defined the category — git push, buildpack, dyno, done — and February 2026 defined the category's endgame: a beloved platform can be profitable enough to sustain and stagnant enough to leave, simultaneously, for years. The teams absorbing that lesson are splitting two ways: managed-PaaS successors for teams that want Heroku's DX without its owner, and own-your-machine self-hosting for teams done with meters entirely. Either destination is easier to reach than it looks, because the vocabulary travels intact. What does not travel is delay: every planning cycle spent assuming the roadmap might thaw is a cycle the forcing-function clocks above keep ticking through.
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.
