Heroku 轉入 sustaining engineering 模式，帶來不同於加價的風險

On February 6, 2026, Heroku’s chief product officer Nitin T Bhat published a short post titled “An Update on Heroku,” announcing that the platform was moving to what Salesforce calls a sustaining engineering model. The post is specific about what that means in practice: Enterprise Account contracts will no longer be offered to new customers, and the engineering focus going forward is “stability, security, reliability, and support,” with an explicit statement that this comes “rather than introducing new features.” Existing customers, the post says, see no immediate change: pricing, billing and day-to-day service stay the same, and existing Enterprise contracts continue to be honored and can renew. Salesforce’s own framing for the shift is that it’s redirecting product and engineering investment toward “areas where we can deliver the greatest long-term customer value,” specifically enterprise AI products, which is the actual business reason behind the change, stated plainly rather than inferred.

This is a different kind of story than the pricing changes other platforms have made this year, and it deserves to be treated differently. A price going up or a bandwidth allowance getting cut is a cost question: run the numbers, decide if the new number still works. Software that stops moving forward is a different, slower-moving kind of risk, and it’s worth being precise about what it actually changes day to day, rather than reaching for either “nothing to worry about” or “Heroku is dead,” neither of which is accurate.

What does “sustaining engineering” actually mean for Heroku users?
The term itself isn’t exotic. It’s a recognized mode in long-lived commercial software: a product that’s past its growth phase gets a smaller, dedicated team whose job is keeping it running correctly, patched and secure, without the team that would normally be building what’s next. Heroku’s own post is careful to say this isn’t a shutdown notice. Apps already running stay running. Pipelines, teams, and the existing add-on ecosystem are explicitly called out as unaffected. Billing doesn’t change for customers paying by credit card through the dashboard. None of that is spin; it matches what sustaining engineering means everywhere else it’s used, and Heroku’s wording avoids overstating or understating it.

What the post does confirm, directly, is the part that matters for anyone planning around Heroku for the next few years: no new features. Not “fewer” features, not “a slower cadence,” the stated posture is that new capability development is not what the team is doing anymore. Combined with no new Enterprise contracts for new customers, the practical read is that Heroku the product, as of February 2026, is not something a team should expect to keep up with developments in the broader platform space on. Whatever the buildpack ecosystem looks like in two years, whatever regions get added to competing platforms, whatever managed-database feature becomes standard elsewhere, Heroku’s answer to all of it is very likely “that’s not something we’re building,” because the team whose job that would have been isn’t doing that job anymore.

What that costs in practice, for a team still on it today
For a team with a stable app, modest growth, and no plans to add new kinds of workloads, this genuinely might not matter for a long while. The post is honest that existing functionality keeps working, and “stability, security, reliability and support” is a real commitment, not an empty one, assuming Salesforce holds to it. Security patches for the existing buildpack stack, bug fixes for existing features, these are explicitly still in scope.

The exposure shows up in a few specific, foreseeable places. New framework or language runtime support is the first: a team that adopts a new version of a framework, or a language runtime Heroku hasn’t already built support for, has no reason to expect Heroku to add it, because that’s new feature work by definition. New regions are the second: infrastructure expansion is product development, and a company in sustaining mode has no stated reason to build new regions, which matters for any team whose latency requirements or compliance needs change over the life of the product. The third, and the one that compounds quietly, is responsiveness to bugs that aren’t security-critical: “stability and reliability” covers keeping existing behavior correct, but a non-critical bug that’s inconvenient rather than dangerous is exactly the kind of issue a smaller, maintenance-focused team reasonably deprioritizes, because that’s what a shrunk roadmap is for. None of these are catastrophic on their own. Together, over two or three years, they describe a platform that quietly falls further behind the part of the category that’s still actively built, while continuing to run correctly for exactly the workload it already supported on the day of the announcement.

Why this is a structural risk specific to renting the whole stack
The deeper point isn’t about Heroku specifically, it’s about what it means to depend entirely on one company’s product roadmap for your own infrastructure. On a fully managed platform, a customer has no path to keep the parts of the service they value moving forward if the vendor’s own priorities change. There’s no server to patch yourself, no infrastructure layer underneath the product that the customer still controls, the entire thing is the vendor’s roadmap, and when that roadmap gets reprioritized, every customer’s future capability gets reprioritized along with it, with no way to opt out short of leaving the platform entirely.

That’s the specific risk sustaining engineering represents, and it’s worth being fair about why Salesforce made the call: a 2026 enterprise software company redirecting investment toward enterprise AI is a rational business decision given the market, and Heroku, nearly two decades old, is a mature product with a well-known shape rather than a growth bet. Nothing about the decision is reckless or dishonest, the announcement itself is unusually direct about what’s changing and why. The risk isn’t that Salesforce did something wrong. It’s that any customer fully inside one company’s managed stack has no lever to pull when that company’s internal priorities shift, because the infrastructure was never theirs to begin with.

What a BYO-server model changes about this specific risk
A platform that runs on servers the customer owns can’t fully eliminate this risk, the control-plane software itself is still built by a company with its own roadmap and its own priorities that could shift. But it changes what’s actually at stake if that happens. The server itself, a plain Linux box at DigitalOcean, Hetzner or Vultr, running an ordinary Docker container behind a standard reverse proxy, doesn’t go stale because the control plane’s roadmap changes. If Railyard stopped shipping new features tomorrow, the apps already deployed keep running on infrastructure the customer already owns and controls directly over SSH, with no dependency on Railyard’s continued development to keep serving traffic. The worst case for a customer in that scenario is losing access to a dashboard and some automation convenience, not losing the infrastructure the app actually runs on, because that infrastructure was never the vendor’s to begin with.

That’s the structural answer to “what if the company behind my platform deprioritizes it,” and it’s a meaningfully different answer than anything available to a customer on a fully managed platform. It doesn’t require Railyard, or any BYO-server platform, to promise it will never happen here; it requires the architecture to make the consequence survivable if it does, which is a guarantee a rented stack can’t offer no matter how well-run the vendor is.

The honest takeaway
Heroku’s February 2026 announcement isn’t a crisis for anyone running on it today, and it isn’t dishonest or poorly communicated, if anything it’s a more direct statement than most companies give when deprioritizing a mature product. The actual lesson is about the category of risk itself: a team that depends entirely on a managed platform is also, by construction, depending entirely on that one company’s internal roadmap decisions staying aligned with the team’s own needs indefinitely, with no fallback if they stop being aligned. That’s a real structural property of renting the whole stack, independent of how good or bad any particular vendor’s intentions are, and it’s worth weighing on its own terms, separately from whatever the current pricing or feature set looks like on the day a team signs up.

FAQ
When did Heroku enter sustaining engineering mode? Heroku’s chief product officer, Nitin T Bhat, announced the shift on February 6, 2026, in a post titled “An Update on Heroku.”

Is Heroku shutting down? No. Existing apps, pipelines, teams and add-ons keep working, and credit-card customers see no change to pricing or billing. Sustaining engineering means no new features and no new Enterprise contracts for new customers, not a shutdown.

Will Heroku add new features or regions? The announcement is explicit that new feature development is not the team’s focus going forward, which also means new regions and new framework or runtime support shouldn’t be expected.

Is this a bigger risk than a price increase? It’s a different kind of risk. A price increase is a cost question you can calculate once. A platform that stops moving forward is a risk that compounds slowly over years, as the rest of the category keeps shipping and a frozen platform doesn’t.

Sources
Heroku: “An Update on Heroku,” by Nitin T Bhat, Chief Product Officer, published February 6, 2026, Heroku and Salesforce’s own primary announcement
DeployHQ: “Heroku Enters Sustaining Engineering Mode: What It Means and When to Consider Alternatives”, analysis of the practical implications
DevClass: “Heroku future in doubt as Salesforce freezes features to focus on AI”, independent coverage of the February 2026 announcement
Railyard’s own how it works page for details on running apps directly on infrastructure you control

See how Railyard specifically compares for a team evaluating a move: Compare Railyard to Heroku, or see how Railyard runs on servers you own.