Heroku's Freeze, Six Months In: What 'Still Running' Costs and Where the Refugees Landed

On February 6, 2026, Heroku chief product officer Nitin Bhat published "An Update on Heroku": the platform was moving to a sustaining engineering model — stability, security, reliability, and support, with no new features and no new Enterprise contracts. Six months later, the striking thing about Heroku is how normal it feels. Deploys work, dynos boot, Postgres answers, the changelog still moves.

That is exactly what makes the freeze expensive. Everything works, so no one budgets for the fact that nothing will ever get better. "The platform still works today" is a true statement about the present. "The platform is still developed" is a promise about the future. Heroku now offers only the first one, at prices set when it offered both.

The six-month verdict, in two tables​

Start with money, because it is the part of the freeze you can put a number on. Table A prices two recognizable stacks — a side project and a typical small production setup — at September 2026 list prices across Heroku and the three destinations absorbing its outbound traffic.

The Heroku column is built from current list prices: Basic dynos at $7 per month, Standard-1X at $25, production Postgres starting at $50, and the Key-Value Store floor at $15. The destination columns come from 2026 benchmark roundups pricing the equivalent stack. The pattern holds at both sizes: Heroku's production floor sits north of $100 a month before a single add-on upgrade, while the same shape of app runs $20–60 elsewhere. At side-project scale the gap is a coffee; at production scale it is a second engineer tool budget.

Table B is where the teams behind those numbers went. No provider publishes a Heroku-refugee counter, so treat this as reported signal rather than census data — but the signal from migration guides, benchmarks, and practitioner writeups all points the same three directions.

With the verdict on the table, here is the evidence behind it: what the freeze actually stopped, what it costs to stand still, and what moving really involves.

What the freeze actually froze — and what still ships​

The February terms, as Bhat wrote them and Salesforce confirmed them to the press: no new feature development, no new Enterprise Account contracts (existing Enterprise customers can renew; credit-card customers see no change to pricing, billing, or day-to-day usage), continued security and reliability updates, and engineering investment redirected toward Salesforce's AI priorities. The Register's headline put it less gently: Salesforce had put Heroku "out to PaaSture."

But a freeze is not a shutdown, and the six months since have been a useful demonstration of the difference. Things that still ship: monthly stack updates (the September 2026 changelog covers Heroku-22, Heroku-24, and the new Heroku-26 stack on Ubuntu 26.04, supported through April 2031), language runtime updates, buildpack releases (the Go buildpack alone shipped v228 through v230 between April and June), Valkey 9 going generally available on the Key-Value Store in August, and even small platform polish like fine-grained Team access controls and an x86_64 default for Fir Private Spaces.

Things that will not ship are harder to observe — frozen roadmaps announce nothing — but the gaps are visible where they already existed. The sharpest one: the Fir generation, which reached general availability in April 2025 as Heroku's next-generation runtime, does not support Docker deploys. The Container Registry remains Cedar-only and amd64-only.

On a living platform that is a gap with a fix on the roadmap. On a frozen platform it is a permanent property of the newest runtime: adopt Fir and you give up containers; keep containers and you stay on the older generation. No new capacity types, no new regions, no new runtime features will resolve it.

There is also the calendar. Heroku-22 is deprecated with support ending in April 2027, which means teams still on older stacks face a forced migration onto a frozen platform's newest stack — all of the toil of an upgrade with none of the upside of a platform that improves afterward. Stack maintenance continuing through 2031 is genuinely good news for anyone staying; it is just maintenance, not momentum.

The price of standing still​

Against that backdrop, the Table A numbers read differently. Heroku's prices did not rise with the freeze — Basic dynos still start at $7, exactly as the announcement promised — but the value behind the prices is now fixed while competitors' value compounds monthly. A Standard-1X dyno at $25 buys the same half-gigabyte RAM slice it always did, on a platform whose scheduler, runtimes, and regions will look the same next year. The $25–60 that buys the equivalent production stack on Railway, Render, or Fly.io buys into roadmaps that still move.

The subtler costs are the ones no invoice shows. Add-on providers maintain integrations for platforms with futures; every quarter Heroku stays frozen, the chance that your Postgres, monitoring, or logging add-on treats Heroku as a tier-one target quietly decays. Support still answers, but it answers sustaining-mode tickets — breakage gets fixed, while "can the platform do X" gets a polite no. And there is a hiring signal that compounds: engineers choosing where to work notice which platforms a company builds on, and "we deploy to the frozen PaaS" is a harder sell with every passing quarter, especially to the platform-minded engineers who would otherwise own a migration.

None of this means staying is irrational. Teams deeply embedded in Salesforce (Heroku Connect, AppLink, Agentforce integrations) may find the switching cost genuinely exceeds the freeze cost. Compliance-heavy shops that already cleared Heroku's audit posture face real re-certification work anywhere else. And some teams will rationally pay the zero-ops premium — Heroku at $115 a month is still cheaper than half an engineer — while treating the platform as a deprecating asset with an exit date. The mistake is not staying. The mistake is staying without a date.

Where the refugees landed​

Railway earned its most-common-destination status the straightforward way: it feels like Heroku did when Heroku was the default answer. Deploy-from-git, managed Postgres and Redis as project services, usage-based billing on a $5 Hobby plan that includes $5 of usage credit. The trade-offs to know going in: usage metering can surprise teams used to flat dyno pricing, and Railway's database templates are convenient rather than fully managed, so production Postgres backups and failover deserve a harder look than the one-click setup suggests.

Render is the lowest-drama move, which is why comparison after comparison names it the fastest migration. The mental model ports directly — web services, background workers, managed Postgres, Key-Value store — at flat per-service prices ($7 Starter tiers, $25 Standard) that make the Table A math predictable to the dollar. Its free tier also gives teams a $0 staging ground to validate the migration before cutting over production. The ceiling is lower than Fly.io's, but most Heroku workloads never needed Fly.io's ceiling; they needed Heroku's simplicity with a future.

Fly.io is the destination for the workloads Heroku never served well: multi-region, latency-sensitive, edge-adjacent. Machines with global placement, persistent volumes, and pay-for-what-runs pricing land the Table A production stack around $20–35. The cost is expertise — Fly.io expects a Dockerfile and rewards operators who understand regions, volumes, and networking in a way Heroku deliberately never asked of its users. Teams that outgrew Heroku's single-region simplicity often find Fly.io is the upgrade they actually wanted, not just the escape they needed.

Mechanically, migrations are less scary than the decision to start one. Procfiles port to Railway and Render nearly verbatim; Heroku's own Cloud Native Buildpacks produce standard OCI images that run anywhere; Fly.io wants a Dockerfile, which the more complex half of Heroku apps already have via the Cedar container path. Data moves with the boring tools — pg_dump into managed Postgres, a Redis replica or dump-and-restore — and DNS cutover makes the whole thing reversible until the moment it is not. Budget days for a standard app, weeks for a Salesforce-tangled one, and run the new stack as staging first so the cutover is a decision, not an experiment.

Stay or go: the renewal question​

If your Heroku contract — Enterprise renewal or just the monthly credit-card habit — is up for review, run three checks before you sign. First, the changelog test: look at what shipped for your stack in the last quarter and ask whether any of it was something you needed, versus maintenance you merely consumed. Second, the add-on test: confirm every add-on you depend on still treats Heroku as a supported target with a maintainer who answers. Third, the hiring test: ask whether your next platform hire would see Heroku on your stack as a neutral fact or a smell.

If all three pass and the Salesforce integration or compliance posture genuinely anchors you, staying with a written exit date is a defensible plan. If any of them fails, the question is not whether to migrate but when — and the answer that minimizes cost is almost always "before the Heroku-22 deadline or the next price-sensitive renewal forces it on someone else's schedule." The teams in Table B did not leave because Heroku broke. They left because a platform that will never improve is a platform you are already migrating off, whether you have admitted it yet or not.

Heroku's freeze is also the strongest argument for owning your platform instead of renting your roadmap. Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with no vendor able to freeze the roadmap under you. Star the repo on GitHub or deploy your first app today.