Heroku Enters Sustaining-Engineering Mode: The Buildpack Survives, Here's What It Costs to Leave

On February 6, 2026, Heroku published a blog post called "An Update on Heroku". Buried in polite corporate language is the sentence that matters: "Enterprise Account contracts will no longer be offered to new customers." Salesforce is done investing in the platform that invented git-push deployment. It isn't shutting Heroku down — but it isn't building it forward either.

Here's the number that actually matters if you're one of the teams still paying Heroku's dyno bill: replicating a real two-dyno web+worker formation — $50 to $100 a month on Heroku — costs roughly $6 to $12 a month in equivalent compute on a self-hosted box today, even after Hetzner raised its own cloud prices twice in 2026. The gap didn't open because Heroku got worse. It opened because the buildpack contract Heroku invented in 2011 — the thing that turns git push into a running app — never actually needed Heroku to survive. It runs identically on infrastructure you own.

What Actually Freezes, and What Doesn't​

Heroku's post is specific about scope, and the specifics are worth quoting directly rather than trusting the "Heroku is dead" headlines that followed it:

That's a genuinely narrower cut than "Heroku is dead." Nobody's app stops running on February 7. No dyno gets shut off. If you're on a self-serve plan, nothing in your workflow changes today.

But there's no official end-of-life date attached to any of this either — which means the honest framing isn't "a forced-migration clock starts now," it's a compounding risk with no visible countdown. A platform in sustaining mode still ships security patches, but historically, feature-frozen infrastructure falls behind on runtime currency (new Node/Python/Ruby major versions) and integration work with wherever the ecosystem moves next. None of that is catastrophic in month one. It's the kind of thing that becomes a problem in month eighteen, after the team that understood the migration path has moved on. Salesforce's own strategic redirection, echoed across the reporting that followed the announcement, points at where the investment is actually going instead: Agentforce and Salesforce's AI product line, not the PaaS it acquired in 2010.

The Buildpack Lineage Heroku Seeded — and Then Let Go​

The reason Heroku's freeze doesn't strand its users the way a database vendor's freeze would is that Heroku already gave away the one piece of technology that actually matters: the buildpack.

In 2011, Heroku shipped the original buildpack API — three scripts, detect, compile, release, that took a git push and turned it into a running slug without a Dockerfile in sight. It spread fast: Cloud Foundry, Google App Engine, GitLab, Knative, and Dokku all built their own dialects of the same idea, which meant a buildpack written for Heroku didn't necessarily work anywhere else.

In January 2018, Heroku and Pivotal fixed that fragmentation by co-founding Cloud Native Buildpacks (CNB) — a formal, versioned spec for the same detect/build/run contract, built from both companies' years of running it in production. CNB joined the CNCF as a Sandbox project that October, and was promoted to Incubation in November 2020. As of mid-2026 it's still at Incubation status — not graduated, but a stable, multi-vendor, foundation-governed spec rather than one company's internal tool.

That governance structure is exactly why the freeze on Heroku-the-platform doesn't freeze the buildpack. Heroku stopping investment in its own product roadmap says nothing about whether the CNB spec, or the independent implementations built on it, keep moving. They do — and it's checkable today, not a theoretical "open source outlives its creator" argument.

The Receipts: This Contract Is Actively Maintained Right Now​

• heroku/buildpacks, Heroku's own CNB implementation, was pushed to as recently as July 6, 2026 — the day before this research was pulled.
• buildpacks/pack, the CNB CLI, shipped v0.40.7 on June 23, 2026. buildpacks/lifecycle shipped v0.21.13 the same day.
• Paketo Buildpacks, the Broadcom/VMware-backed CNB implementation, was pushed to as recently as July 3, 2026, with release notes across its Tomcat, Gradle, Maven, and Azul Zulu buildpacks dated April 2026.
• Heroku itself published a blog post on March 17, 2026 — six weeks after the sustaining-engineering announcement — titled "Behind the Scenes: How Maintaining Cloud Native Buildpacks Powers Platforms Like Heroku." It discloses 27 releases shipped across CNB projects in 14 months, more than 65 community pull requests reviewed, and a stated goal of shipping critical security fixes "within days." Contributors named include Heroku, Google Cloud, Red Hat/OpenShift, and VMware Tanzu — evidence that CNB's maintenance was never a one-company effort, so Heroku's own commercial slowdown doesn't remove the other three.

Railway's own history makes the same point from a different angle. Railway dropped platform support for Heroku Buildpacks and Paketo in February 2025, replacing them with its own Nixpacks tool — and then, by March 2026, moved on again from Nixpacks to a new Go/BuildKit-based tool called Railpack (claiming roughly 38% smaller base Node images and 77% smaller base Python images), because Nix's caching and image-size behavior wasn't working for a long tail of its users. Two builder swaps in thirteen months, and in both cases the thing that stayed constant for Railway's users was the git-push contract itself. The builder underneath is replaceable. That's the entire point of the spec.

What It Actually Costs to Leave​

Here's the comparison the announcement forces on every team still paying a Heroku bill — not a vague "self-hosting is cheaper" gesture, but the same dyno formation, priced both ways, at two different scales.

Scenario A — hobby/small production app: one web dyno + one worker dyno, both Standard-1X ($25/month each = $50/month on Heroku).

Scenario B — heavier production app: one web dyno + one worker dyno, both Standard-2X ($50/month each = $100/month on Heroku).

Now the self-hosted side. It's worth being upfront that Hetzner — the usual "cheap VPS" answer — raised Cloud prices twice in 2026: once in April (up to 37%), citing rising infrastructure and hardware costs, and again in June for new orders and rescales. Its performance-oriented CPX/CCX lines jumped roughly 120–175%, so the old "€10 gets you a real box" line no longer holds for those SKUs. But Hetzner's shared-vCPU CX and ARM-based CAX lines rose far less by comparison:

A single CX23 or CAX11 — 4 GB of RAM for roughly $6/month — already out-specs a Heroku Standard-1X dyno (0.5 GB) by 8x, with room to run both the web and worker process on one box. Scale up to a CAX21 for Scenario B, and 8 GB comfortably covers two Standard-2X-equivalent (1 GB each) processes with headroom to spare, at roughly $11.50/month against Heroku's $100.

That's not a cherry-picked flagship instance — it's the plain "cost-optimized" tier Hetzner sells today, after both of its own 2026 price increases, still running the identical processes. The honest caveat: you're trading Heroku's managed dyno isolation, autoscaling, and add-on marketplace for a box you patch yourself. The point isn't that self-hosting is free of tradeoffs — it's that the buildpack contract that builds your app doesn't care which side of that tradeoff you're on.

Making It Real: Same Buildpack, Owned Box​

The mechanical piece that makes this work is that pack build — the CNB CLI — produces the same OCI image whether it's pointed at Heroku's builder, Paketo's builder, or run in your own CI:

pack build myapp --builder heroku/builder:24
docker run --env-file .env -p 8080:8080 myapp

That's Heroku's own open-source Cloud Native Buildpacks — the same detection logic that runs on git push heroku main — producing a standard container image that runs anywhere: a Hetzner box, a Kubernetes cluster, your laptop. The image doesn't know or care where it ends up. That's what "the contract outlives the vendor" means in practice: point the exact same buildpack at a different host and get the exact same app, with no Dockerfile to hand-write and no rewrite of your deploy process.

This is the gap Bex.co is built to fill: an open-source, AI-native Render-style platform where a git push to a repo on infrastructure you own triggers buildpack detection, build, and a running HTTPS service — no managed database lock-in, no closed SaaS control plane, just the same detect/build/run contract Heroku shipped in 2011, running on a box you control. For a team watching Heroku's roadmap freeze and doing the Hetzner math above, that's the practical version of "the buildpack survives the vendor": the workflow your team already knows doesn't change, only where it runs does.

The Freeze Is Information, Not a Verdict​

Sustaining-engineering mode isn't Heroku disappearing overnight — existing contracts are honored, self-serve signups stay open, and security patches keep shipping. But a platform that's stopped investing in its own roadmap is telling you, plainly, where it thinks its future isn't. The teams with real leverage right now aren't the ones panic-migrating off a stable dyno; they're the ones who already know that the thing they actually depend on — a git push that turns into a running app — was never Heroku's alone to freeze. It was open, foundation-governed, and actively shipping releases as recently as this week. Whether you leave in month one or month eighteen, the workflow travels with you.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, using the same buildpack contract this post is about. Star the repo on GitHub or deploy your first app today.

Sources​

• Heroku — "An Update on Heroku" (Feb 6, 2026)
• Heroku — "Behind the Scenes: How Maintaining Cloud Native Buildpacks Powers Platforms Like Heroku" (Mar 17, 2026)
• Heroku Dev Center — Buildpacks
• buildpacks.io
• Heroku — "Buildpacks Go Cloud Native"
• CNCF Blog — "TOC Approves Cloud Native Buildpacks from Sandbox to Incubation" (Nov 18, 2020)
• Heroku Pricing
• Heroku Dev Center — Dyno Sizes
• Hetzner — Statement on Price Adjustment
• Hetzner Docs — Price Adjustment
• Tom's Hardware — "Hetzner to raise prices by up to 37 percent from April 1"
• Railway Blog — "Introducing Railpack"
• Railway Station — Heroku Buildpacks/Paketo deprecation notice