Dora NodaHeroku did not shut down in February 2026. That is precisely why so many teams still have not left — and why the ones paying attention are leaving anyway.
On February 6, 2026, Salesforce moved Heroku into a "sustaining engineering model": no new features, reliability and security patches only, and no new Enterprise Account contracts for new customers. Your dynos kept running. The bill kept arriving. Nothing broke that day, which is exactly how a slow exit works.
Here is the verdict up front: if you are not already on a Heroku Enterprise contract, you can never become one — that door closed in February and it is not reopening. For everyone else, the question is no longer "will Heroku still be here next year" but "what does staying cost while the platform quietly stops keeping up." The short answer: a typical web-plus-worker-plus-Postgres workload that costs roughly $38/month on Render, about $20–$30/month on Railway or Fly.io at modest scale, and about €4.51/month in raw hardware on a Hetzner CX22 is still costing $100+/month on Heroku — and the gap widens every time a runtime or CVE response lags. Migrate on your own schedule in the next one to two quarters; do not wait for a forcing event.
This post is the timing companion to our mechanics playbook, The Heroku Exit Playbook: that one shows how to leave (Procfile to manifest, add-ons, secrets, database cutover). This one answers when to leave and where to go.
What "sustaining engineering" actually means
The official announcement came from Heroku chief product officer Nitin T. Bhat on the Heroku blog in early February 2026: Heroku would transition to a sustaining engineering model focused on stability, security, reliability, and support. Salesforce framed it as continued commitment — existing apps, pipelines, teams, and add-ons unaffected, production workloads still supported. Analysts read it differently: InfoWorld called it possible preparation for phasing out the platform, DevOps.com described feature development as frozen, and The Motley Fool summarized the market verdict bluntly — Heroku is not exactly dead, but it may as well be.
Strip away the framing and the facts are narrow and checkable:
- No new features. The roadmap is security and reliability patches, not new platform capabilities. Back4App's February 2026 alternatives guide lists this as the headline migration driver alongside cost and control limits.
- No new Enterprise contracts — explicitly. Enterprise Account contracts are no longer offered to new customers. Existing Enterprise subscriptions and support contracts continue to be honored and may renew as usual. Read that carefully: if your company is not already an Enterprise customer, there is no path to becoming one. Procurement teams that require an enterprise agreement, custom terms, or committed support tiers cannot buy them on Heroku anymore, at any price.
- Pay-as-you-go continues. Nobody's app was turned off. Hobby, production dynos, and add-ons keep billing. That continuity is the trap: everything works until the day something you depend on — a Node.js or Python runtime, a buildpack stack, a TLS cipher set — needs the vendor to move and the vendor moves slowly.
- The decay is already visible. The new Fir generation (generally available since April 2025) does not support Docker deploys — the Container Registry remains Cedar-only and amd64-only. Heroku's September 2026 TLS cipher cull forced legacy-client audits on tenants. Each of these is individually survivable; together they are the texture of sustaining mode.
Sustaining mode does not mean shutdown. It means the platform's side of the shared-responsibility bargain — keep runtimes current, keep buildpacks fresh, keep pace with the ecosystem — is now running on a skeleton crew while your side of the bargain stays full price.
The migration math: one workload, five bills
Comparisons only mean something when the workload is fixed. Take the smallest honest production shape a Heroku team actually runs: a web dyno, a background worker, a managed Postgres, and a small Redis. Price that same shape on each target at 2026 list prices, before egress surprises:
| Layer | Heroku | Render | Railway | Fly.io | Hetzner CX22 (self-hosted) |
|---|---|---|---|---|---|
| Web process | $25–$50/mo (Basic/Standard dyno) | $7/mo (Starter, 512 MB) | ~$5–$10/mo usage ($10/GB RAM, $20/vCPU metered) | ~$2–$6/mo (shared-cpu-1x, 256 MB–1 GB) | Included in box |
| Worker process | $25–$50/mo (second dyno) | $7/mo (second Starter) | ~$5–$10/mo usage | ~$2–$6/mo (second machine) | Included in box |
| Postgres | $15–$50/mo (Mini/Standard-0) | $7/mo (Starter) | ~$3–$8/mo (volume + compute) | ~$5/mo (1 GB volume + machine) | Self-managed on box |
| Redis | $15–$30/mo (add-on) | $10/mo (Starter Key Value) | ~$2–$5/mo usage | ~$2/mo (small machine or Upstash) | Self-managed on box |
| Honest total | ~$80–$180/mo | ~$31/mo | ~$15–$33/mo at this size | ~$11–$19/mo at this size |
Three things this table does not hide, because a hardware line by itself is a marketing trick:
- Railway and Fly.io are meters, not prices. Railway's Hobby plan is $5/month including $5 of usage, with overages at $10/GB RAM-month and $20/vCPU-month metered per minute. A 0.5 vCPU plus 512 MB app is roughly $15/month ($5 subscription plus $10 overage). Fly.io bills pay-as-you-go from the first machine — cheapest shared-cpu-1x at 256 MB is under $2/month, but there is no free tier for new accounts since October 2024 and a card is required. Both are cheap at this workload size and both grow with usage; neither is flat.
- Render is flat per service. That predictability is the appeal and the tax: every process is another $7 Starter. A Django app with web, Celery worker, Celery beat, Postgres, and Redis is five paid line items before traffic exists. Simple to forecast, quick to stack.
- Hetzner is hardware, not a platform. A CX22 (2 shared vCPU, 4 GB RAM, 40 GB SSD, 20 TB included transfer) at roughly €4.51/month is the whole fleet budget above — but Postgres backups, Redis persistence, TLS, deploys, and the 3 a.m. pager are yours now. The 20 TB bandwidth allowance dwarfs anything in the PaaS column, which is exactly why egress-heavy apps show the biggest deltas. The honest comparison is hardware plus your ops time, not hardware alone.
The direction is unambiguous even after all caveats: staying on Heroku costs three to ten times the alternatives for the same shape, and the premium buys a platform that has publicly stopped investing in new capabilities.
Where Render, Railway, and Fly.io actually diverge
Price gets teams to look; fit picks the destination. The three live git-push comparators differ on the dimensions Heroku tenants actually feel:
Render is the closest Heroku UX. It supports Heroku buildpacks directly, ships an official heroku-import CLI plugin that maps a Hobby $7 dyno to a Starter $7 service, and thinks in the same units Heroku tenants already know: one service per process, one plan per service, Postgres and Key Value as attached add-ons. If your team wants the smallest conceptual migration — Procfile mostly intact, config vars renamed to environment variables, pipelines to preview environments — Render is the shortest path. The price of that familiarity is per-service stacking and free-tier services that sleep after 15 minutes of inactivity.
Railway is usage-based velocity. There is no dyno size to pick; there is a meter running at $20/vCPU-month and $10/GB RAM-month with per-minute granularity, plus $0.15/GB-month volumes and $0.05/GB egress. The $5/month Hobby subscription includes $5 of usage, and the $5 one-time trial credit covers a first experiment. Teams that deploy from GitHub, live in preview environments, and would rather watch a usage graph than pre-size dynos feel at home — but the bill moves with the workload, memory dominates (roughly 99% of usage cost in real invoices operators have published), and cost control means setting hard and soft limits, not picking a smaller plan.
Fly.io is edge-first infrastructure with a PaaS face. Apps run as Firecracker microVMs near users, configured in fly.toml rather than a Procfile, with first-class multi-region deploys the other two cannot match. The tradeoff is operational surface: machines, volumes, and autoscaling primitives are yours to understand, the free tier is gone for new accounts, and realistic small-app bills land around $3–$10/month plus Postgres. Edge latency and arbitrary containers are the reason to choose it; Heroku-likeness is not.
None of them reproduces Heroku's old bargain of "nobody thinks about infrastructure." They just charge less for making you think about a little of it.
Migrate now or wait? A timing framework
Sustaining mode punishes waiting unevenly. Four questions sort teams into "this quarter" versus "next two quarters" — nobody gets "indefinitely":
- Do you need an Enterprise contract? If procurement requires one and you do not already have it, the decision is made: Heroku cannot sell you one. Migrate now.
- How deep is your buildpack reliance? Teams on standard Heroku buildpacks (Node, Python, Ruby) with a clean Procfile migrate fastest — Render consumes buildpacks directly, Railway and Fly take Dockerfiles or Nixpacks. Teams pinned to Cedar-only Docker workflows or old stacks (heroku-20 and earlier) should move before the next stack sunset forces a rushed migration under a deprecation deadline.
- What is your CVE tolerance? Sustaining mode still patches, but response cadence is the documented risk: each runtime EOL, cipher-suite change, or buildpack lag lands on your backlog instead of the vendor's roadmap. Regulated or customer-trust-sensitive teams should weight this above the monthly bill.
- Are you growing or steady? Growing teams pay the Heroku premium on every new process and hit the platform's operational limits (30-second request timeouts, daily dyno restarts, AWS-only regions) sooner. Steady-state internal tools with no Enterprise need and current stacks can schedule the move deliberately — but schedule it.
The migration path itself is five steps, and the mechanics are covered in depth in the exit playbook: translate the Procfile to the target's manifest (render.yaml, railway.json, or fly.toml); carry buildpacks or containerize; move config vars without a secrets leak window; rehearse the Postgres cutover with pg_dump and pg_restore until the outage window is minutes; then cut over DNS and keep the Heroku app scaled to zero — not deleted — for one rollback window. Budget a weekend for a standard app, a sprint for anything with review-app pipelines or private-space networking.
What self-hosting reclaims
The fourth destination is not another vendor: it is a box you own. A Hetzner CX22-class machine at roughly €4.51/month with 20 TB of included transfer replaces the entire meter stack above for small fleets, and the deeper win is structural — there is no vendor roadmap to time your migration against ever again. No sustaining-mode announcements, no per-seat repricings, no egress repricing seasons. The platform cannot exit on you because you are the platform.
The honest cost is operations. Backups, Postgres upgrades, Redis persistence, TLS renewal, deploy pipelines, and on-call are a real second bill paid in engineering hours. That bill is fixed-ish while usage bills scale, which is why the crossover math favors self-hosting as fleets grow: one box holds the whole workload above with headroom, three boxes hold a small fleet, and none of them reprice in April. Teams that already run Kubernetes via Cluster API get the best version of this — declarative machine lifecycle, no per-service meter, portable manifests — and teams that do not should be clear-eyed that they are trading a migration project for an operations practice.
The window is open; it will not get wider
Heroku's sustaining-mode announcement changed nothing on the day and everything about the trend line. No new features, no new Enterprise contracts, and a visible pattern of ecosystem lag since — against alternatives that are three to ten times cheaper for the same workload and a self-hosted floor near $5 in hardware. The teams that migrate well in 2026 will do it on a calm schedule they chose, with a rehearsed database cutover and a rollback window. The teams that migrate badly will do it on a deprecation's schedule, in a hurry, after the next stack sunset or CVE lag picks the date for them.
Pick the destination that fits — Render for the shortest path, Railway for usage-shaped velocity, Fly.io for the edge, owned hardware for the exit from exit risk — and start this quarter.
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.
