On 14 October 2026 Heroku published a post titled "Improved Static Website Support on Heroku with Front-End Web Cloud Native Buildpack". The feature is straightforward: an official buildpack for sites made of HTML, CSS and JavaScript, with the conveniences a static host is expected to have — a not-found fallback for client-side routing, response headers, custom error pages, redirects, clean URLs, basic auth before launch, and a build command for static site generators. In Heroku's words, "With the new Front-End Web Cloud Native Buildpack (CNB), you get a complete static web deployment solution", and it "is now available for all Heroku customers".
The sentence worth a closer look is a different one: "If you're one of many who currently run static web apps on Heroku using existing community buildpacks, consider migrating to this new CNB."
The polite sentence with a cost attached
Static sites on Heroku are not new. As the post itself says, "Since the beginning, developers have been finding ways to deploy static websites on Heroku" — through community buildpacks such as heroku-community/nginx and the create-react-app buildpack, both of which the post links migration guides for. Those sites work today. Their owners did nothing wrong; they used the tools the ecosystem offered, and the platform now offers a better one.
That is the shape of every "we made the unofficial thing official" announcement, and it is worth naming what it hands to the people who were already there. "Consider migrating" means: somebody has to open a build that currently works, change how it is built, and retest it — routing fallbacks, headers, redirects, caching behaviour, the error page nobody has looked at since 2023. For a one-page marketing site that is an afternoon. For a fleet of static front-ends across a company it is a project, and it is a project whose only visible output, if everything goes right, is that nothing changed.
None of that is a criticism of the feature. It is the cost that comes with promoting a community pattern to a platform primitive, and platforms that do it well owe their users three things.
What you owe users when you make the unofficial thing official
A path. A migration guide per community buildpack, not a general "it's easy now". Heroku's post links two, for the two most common ones. That is the right unit: the person migrating is coming from a specific setup, and the guide should start from that setup, not from a blank project.
A reason. Not "it is official now", which is a statement about the platform, but what the user gains: in this case, the list of built-in behaviours above, versus hand-maintained nginx config or a buildpack that somebody else maintains in their spare time. If the honest answer is "nothing you can see, but we can support it properly", say that; it is still a reason.
A clear statement of what breaks if they do nothing. This is the one most announcements skip, and it is the one that decides whether "consider migrating" is advice or a countdown. Will the community buildpacks keep working? For how long? Is there a date? Heroku's post attaches no deadline and no deprecation date to the ask, and says the new support "is exclusively available as a Cloud Native Buildpack" without saying anything about retiring the old paths. Read plainly, that means: the sites that work today keep working, and the migration is the owner's call on the owner's schedule. That is to Heroku's credit. It is also exactly the sentence a user wants to see written down rather than inferred — because the absence of a deadline today is not a promise about next year, and "consider" is doing a lot of work in that paragraph.
If you run a static site on Heroku through a community buildpack, the practical reading is: nothing is forcing your hand, the official path is better maintained, and the cheapest time to migrate is a quiet week of your choosing rather than the week after a buildpack you depend on stops being updated. Put it on the list; do not treat it as an incident.
The smaller point: "sustaining" is not "stopped"
This is also a data point against the "Heroku is dead" framing, including the version of it that has appeared on this blog. On 6 February 2026 Heroku moved to a sustaining-engineering model (the post is an-update-on-heroku on Heroku's blog), which it described as "an emphasis on maintaining quality and operational excellence rather than introducing new features". Since then it has shipped a Team Authorizations release on 30 September, a roundup on 7 October and this buildpack on 14 October.
The honest reading is narrower than either slogan. Feature work has not stopped; it has narrowed. What ships is the kind of thing that makes the existing platform more reliable, more secure, or more complete for the workloads it already runs — a buildpack that formalises a pattern people were already using fits that description exactly. What does not appear is expansion into new ground. The claim that Heroku has stopped shipping is false at the primary source, and so is any suggestion that the February change was cosmetic; the February post also made clear that existing enterprise contracts are "fully honored and may renew as usual", with the closure applying to new enterprise customers. Both halves are true at once, and a reader deciding whether to stay or move is better served by both than by either.
Where this leaves a static site, generally
A static site is the simplest thing a host can serve: files in a directory, a web server in front of them. Every layer a platform adds on top — a buildpack, a build step, a configuration format — is a convenience that also becomes something to migrate when the platform changes its mind about how the convenience should work. That is not an argument against the conveniences. It is an argument for knowing which layer you are depending on, so that when a vendor's post says "consider migrating", you already know what in your setup the sentence refers to.
For what it is worth, on DeployBase a static site is simply the PHP app type: an Apache container serving whatever is in the app directory. There is no buildpack to choose and no build step unless you add one, so there is nothing of that kind to migrate off; the trade-off is that you also get none of the buildpack conveniences unless you configure them yourself, in an .htaccess file or in your own build. Different layer, different thing to depend on — which is the point.