Dora NodaOn February 6, 2026, Heroku announced it was done shipping new features. The platform was moving to a sustaining-engineering model — stability, security, and reliability, with "an emphasis on maintaining quality and operational excellence rather than introducing new features," in the words of the announcement. Seven months later, Heroku shipped a build-system upgrade to its oldest apps: on September 3, 2026, Cloud Native Buildpacks support came to Cedar-generation apps, the dyno lineage that has defined Heroku since 2011.
That contradiction is the whole story. A platform with no roadmap spent some of its last engineering on bringing the Cloud Native Buildpack contract to legacy workloads. Here is the verdict up front, because this post is analysis and analysis should not bury the lede: when even frozen Heroku converges on OCI-via-buildpacks, the industry's build debate is over. The common-denominator contract is detect, build, and emit a portable OCI image — and a git-push platform whose build strategy still defaults to hand-written Dockerfiles is betting against the ecosystem's center of gravity.
What actually shipped
The changelog entry is short and precise. Cloud Native Buildpacks build an OCI image or a slug-compatible OCI layout from your code. Previously available only on the Fir generation, the technology is now available to the Cedar generation. The default stack for each generation is unchanged.
Concretely, Cedar apps use classic buildpacks by default but can opt into a cnb stack:
heroku apps:create <app name> --stack cnb
heroku stack:set cnb -a <app name>Fir-generation apps already default to the cnb stack and require CNBs. The artifact differs by generation: Fir apps get a real OCI image, while Cedar apps get what Heroku's glossary calls a slug-compatible OCI layout — the CNB machinery producing an artifact the Cedar runtime can still consume. Heroku also shipped the supporting docs the same day: a migration guide from classic to CNB, build-time config vars on the CNB stack, and a classic-vs-CNB comparison that is the most honest build-system scorecard a PaaS has ever published about its own tech debt.
That last document deserves a closer look, because Heroku built the comparison table this post's argument rests on.
The comparison that matters
Heroku's comparison table, updated the day the changelog landed, runs eleven rows. Seven of them are parity — auto-detection, multi-language, multi-process, reusability, and no Dockerfile required on either side. Nothing you could do with classic buildpacks is lost. The four deltas are where platform economics change:
| What changes | Classic buildpacks | Cloud Native Buildpacks |
|---|---|---|
| Build artifact | Proprietary slug | OCI-compatible image |
| Base-image updates | Heroku stack upgrades | CNB rebase |
| Bill-of-materials | No | Yes |
| Local reproducibility | No | Yes (via pack CLI) |
Each delta is a structural shift, not a feature checkbox. An OCI image runs anywhere containers run; a slug runs on Heroku. That single row converts every Cedar app that opts in from a platform-captive artifact to a portable one — buildable with the open pack CLI against Heroku's own published heroku/builder:24 builder, runnable on any container runtime.
Rebase changes CVE-day economics. A stack upgrade rebuilds the app against a new base image; a rebase swaps the base-image layers underneath an already-built app without recompiling it. When the next OpenSSL advisory drops, the CNB path patches the foundation and keeps the application layers intact — minutes of layer surgery instead of a full rebuild-and-retest cycle per app.
The bill-of-materials row is about procurement, not developers. Enterprises increasingly require an SBOM for everything they deploy, and a build system that emits one natively clears security review that a slug-based pipeline answers with documentation instead of evidence. And local reproducibility closes the oldest PaaS debugging gap: "works on the platform, fails on my machine" becomes reproducible in both directions, because the same builder runs in both places.
Heroku is telling you, in its own documentation, that its fifteen-year-old build contract loses on portability, patching, compliance evidence, and reproducibility — while matching it on everything else. When a vendor grades its own legacy system this way, believe the grades.
Why a frozen platform spent its last engineering on this
The sustaining-model context makes the changelog entry strange until you think about maintenance surface. Heroku now operates two generations: Cedar, the classic dyno platform, and Fir, the Kubernetes-backed next generation that runs on EKS with CNBs, OCI, and OpenTelemetry throughout. Every build-system divergence between those generations is a cost the sustaining team pays forever — two buildpack implementations to patch, two base-image pipelines to maintain, two sets of language-version updates to ship.
Bringing CNB to Cedar does not add a feature. It deletes a divergence. One build contract — detect, build, emit OCI — across both generations means one builder family, one language-support matrix, and one patching story. The changelog entry even reads like maintenance when you squint: no new capability for Fir, no new languages, no new stacks as defaults. Just the old generation converging onto the new generation's build path.
There is a second, less charitable reading worth naming: portability as retention. An app whose artifact is a slug can only run on Heroku, which sounds like lock-in working as intended — until the platform announces it has no future, at which point lock-in becomes the reason to leave rather than the reason to stay. The September 19 migration playbooks already teach Heroku-20 refugees to reproduce their builds with pack build and carry a portable image elsewhere. By making CNB a first-class Cedar option, Heroku gives staying customers the same portability story without requiring them to migrate generations first. Either reading lands in the same place: the CNB contract is where Heroku's remaining engineering goes, because it is the only build investment that pays off under both staying and leaving.
The ecosystem is converging from every direction
Heroku is the last mover here, not the first. Three data points from the same twelve months show the convergence is industry-wide — plus one honest caveat.
First, Cloud Native Buildpacks graduated from the CNCF on August 11, 2026, three weeks before the Cedar changelog. Graduation is the foundation's highest maturity level: vendor-neutral governance, a public third-party security audit, sustained multi-organization contribution. The detect/build/rebase contract is no longer a Heroku-and-Pivotal convention from 2018. It is governed infrastructure with Bloomberg running 500-plus CNB-built applications in production.
Second, Railway spent 2026 replacing Nixpacks with Railpack as its default builder — Nixpacks went into maintenance mode while Railpack took over auto-detection for new apps. Different engine, same contract: push source, get an image, no Dockerfile required. The new generation of git-push PaaS is converging on detection-first builds even where it does not use the CNB spec directly.
Third, the escape-hatch direction is thriving too. The pack CLI plus a published builder is now a documented migration primitive: Qovery's Heroku migration guide, Control Plane's docs, and community Coolify plans all treat pack build --builder heroku/builder:24 as a standard verb. The builder is infrastructure anyone can invoke, not a platform interior.
Now the caveat, because convergence on a spec is not convergence on every distribution. Paketo — the community builder family that implements the same CNB contract — spent 2026 showing strain: its GCR-hosted images are sunsetting, an RFC on buildpack status notes that maintainers have left without successors stepping up, and shared pipeline tooling is being deprecated. The specification is graduated and stable; individual builder distributions still carry bus-factor risk. A platform betting on CNB must choose its builder the way it chooses its base images — by maintenance evidence, not by brand memory. Heroku's own builders, Google's, and Paketo's are not interchangeable commitments.
The concrete read for a git-push PaaS build strategy
If you operate or are building a git-push platform, the Cedar changelog converts an architectural preference into a market fact. Here is the strategy it implies, stated as decisions rather than vibes.
Default to CNB-spec builds that emit OCI. Detection-first is no longer the convenient option competing against the serious Dockerfile option — it is the option Heroku, the CNCF, and Railway all converged on within the same year. Your default build path should take source and emit a portable image with an SBOM, full stop.
Keep the Dockerfile as an escape hatch, not the default. There will always be apps the detectors cannot express: exotic toolchains, vendored binaries, compliance-mandated base images. Those deserve a supported Dockerfile path. But every tenant on the Dockerfile path is a tenant whose base-image patching, SBOM, and local reproducibility your platform must hand-roll — the exact toil CNB exists to absorb. Measure the escape-hatch share and treat growth in it as a detection gap to close, not a preference to celebrate.
Adopt rebase-based patching as a tenant-facing feature. The CVE-day story — swap base layers without rebuilding app layers — is the sharpest operational wedge CNB gives a small platform team. It turns fleet-wide base-image patching from N rebuilds into N rebases, and it is legible to customers in a way "we upgraded our internal stack" never was. Ship the rebase, then tell tenants the patch window in minutes.
Treat local reproducibility as part of the product. When the same builder runs on a laptop and on your fleet, "works here, fails there" becomes a reproducible bug report instead of a support ticket. Publish your builder, document the pack build invocation, and watch a class of build-environment tickets evaporate.
The through-line: Heroku's sustaining team looked at its remaining maintenance budget and spent it making the old platform build like the new one. Build strategy in 2026 is not a choice between Dockerfiles and magic. It is a choice between the industry's common denominator and a folk build system only your team understands. Pick the denominator.
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.
