Heroku ist jetzt im Sustaining-Engineering-Modus, und das ist eine andere Art von Risiko als eine Preiserhöhung

Am 6. Februar 2026 veröffentlichte Herokus Chief Product Officer Nitin T Bhat einen kurzen Beitrag mit dem Titel „An Update on Heroku”, in dem er ankündigte, dass die Plattform zu dem wechselt, was Salesforce ein Sustaining-Engineering-Modell nennt. Der Beitrag ist konkret darüber, was das in der Praxis bedeutet: Enterprise-Account-Verträge werden neuen Kunden nicht mehr angeboten, und der Engineering-Fokus geht fortan in Richtung „Stabilität, Sicherheit, Zuverlässigkeit und Support”, mit der expliziten Aussage, dass das „statt neue Features einzuführen” passiert. Bestehende Kunden, so der Beitrag, sehen keine unmittelbare Änderung: Preise, Abrechnung und der tägliche Service bleiben gleich, und bestehende Enterprise-Verträge werden weiterhin eingehalten und können verlängert werden. Salesforce’ eigene Einordnung des Wandels ist, dass es Produkt- und Engineering-Investitionen in Richtung „Bereiche, in denen wir den größten langfristigen Kundennutzen liefern können” umleitet, konkret Enterprise-KI-Produkte, was der tatsächliche geschäftliche Grund hinter der Änderung ist, klar ausgesprochen statt nur vermutet.

Das ist eine andere Art von Geschichte als die Preisänderungen, die andere Plattformen dieses Jahr vorgenommen haben, und sie verdient eine andere Behandlung. Ein steigender Preis oder ein gekürztes Bandbreiten-Kontingent ist eine Kostenfrage: die Zahlen durchrechnen, entscheiden, ob die neue Zahl noch passt. Software, die aufhört, sich weiterzuentwickeln, ist eine andere, langsamer wirkende Art von Risiko, und es lohnt sich, präzise zu sein, was sich dadurch tatsächlich im Alltag ändert, statt entweder zu „nichts, worüber man sich Sorgen machen muss” oder zu „Heroku ist tot” zu greifen, von denen keines zutrifft.

Was bedeutet „Sustaining Engineering” tatsächlich für Heroku-Nutzer?

Der Begriff selbst ist nicht exotisch. Es ist ein anerkannter Modus in langlebiger kommerzieller Software: Ein Produkt, das seine Wachstumsphase hinter sich hat, bekommt ein kleineres, dediziertes Team, dessen Aufgabe es ist, es korrekt, gepatcht und sicher am Laufen zu halten, ohne das Team, das normalerweise bauen würde, was als Nächstes kommt. Herokus eigener Beitrag ist vorsichtig zu sagen, dass das keine Abschaltankündigung ist. Bereits laufende Apps laufen weiter. Pipelines, Teams und das bestehende Add-on-Ökosystem werden explizit als unbetroffen genannt. Die Abrechnung ändert sich nicht für Kunden, die per Kreditkarte über das Dashboard zahlen. Nichts davon ist Spin; es passt zu dem, was Sustaining Engineering überall sonst bedeutet, wo es genutzt wird, und Herokus Formulierung übertreibt oder untertreibt es nicht.

Was der Beitrag direkt bestätigt, ist der Teil, der für jeden wichtig ist, der die nächsten paar Jahre mit Heroku plant: keine neuen Features. Nicht „weniger” Features, nicht „ein langsameres Tempo”, die angegebene Haltung ist, dass die Entwicklung neuer Fähigkeiten nicht mehr das ist, was das Team macht. Kombiniert mit keinen neuen Enterprise-Verträgen für neue Kunden, liest sich das praktisch so, dass Heroku als Produkt, ab Februar 2026, nicht etwas ist, von dem ein Team erwarten sollte, mit Entwicklungen im breiteren Plattform-Bereich mitzuhalten. Wie das Buildpack-Ökosystem auch in zwei Jahren aussieht, welche Regionen bei konkurrierenden Plattformen hinzukommen, welches Managed-Database-Feature anderswo zum Standard wird, Herokus Antwort auf alles davon ist sehr wahrscheinlich „das bauen wir nicht”, weil das Team, dessen Aufgabe das gewesen wäre, diese Aufgabe nicht mehr macht.

Was das in der Praxis kostet, für ein Team, das heute noch darauf läuft

Für ein Team mit einer stabilen App, moderatem Wachstum und keinen Plänen, neue Arten von Workloads hinzuzufügen, mag das lange Zeit wirklich keine Rolle spielen. Der Beitrag ist ehrlich, dass bestehende Funktionalität weiter funktioniert, und „Stabilität, Sicherheit, Zuverlässigkeit und Support” ist ein echtes Versprechen, kein leeres, vorausgesetzt Salesforce hält sich daran. Sicherheitspatches für den bestehenden Buildpack-Stack, Bugfixes für bestehende Features, diese sind explizit weiterhin im Umfang enthalten.

Die Exposition zeigt sich an ein paar konkreten, vorhersehbaren Stellen. Unterstützung für neue Framework- oder Sprachlaufzeiten ist die erste: Ein Team, das eine neue Version eines Frameworks oder eine Sprachlaufzeit übernimmt, für die Heroku noch keine Unterstützung gebaut hat, hat keinen Grund zu erwarten, dass Heroku das hinzufügt, weil das per Definition neue Feature-Arbeit ist. Neue Regionen sind die zweite: Infrastruktur-Expansion ist Produktentwicklung, und eine Firma im Sustaining-Modus hat keinen genannten Grund, neue Regionen zu bauen, was für jedes Team wichtig ist, dessen Latenzanforderungen oder Compliance-Bedürfnisse sich über die Lebensdauer des Produkts ändern. Der dritte, und der sich leise summiert, ist die Reaktionsfähigkeit auf Bugs, die nicht sicherheitskritisch sind: „Stabilität und Zuverlässigkeit” deckt ab, bestehendes Verhalten korrekt zu halten, aber ein nicht kritischer Bug, der lästig statt gefährlich ist, ist genau die Art von Problem, die ein kleineres, wartungsfokussiertes Team vernünftigerweise nach hinten schiebt, weil genau dafür eine geschrumpfte Roadmap da ist. Keines davon ist für sich allein katastrophal. Zusammen, über zwei oder drei Jahre, beschreiben sie eine Plattform, die still und leise weiter hinter dem Teil der Kategorie zurückfällt, der noch aktiv weiterentwickelt wird, während sie weiterhin korrekt für genau den Workload läuft, den sie am Tag der Ankündigung schon unterstützt hat.

Warum das ein strukturelles Risiko ist, spezifisch für das Mieten des gesamten Stacks

Der tiefere Punkt geht nicht speziell um Heroku, er geht darum, was es bedeutet, vollständig von der Produkt-Roadmap einer einzelnen Firma für die eigene Infrastruktur abhängig zu sein. Auf einer vollständig verwalteten Plattform hat ein Kunde keinen Weg, die Teile des Dienstes, die ihm wichtig sind, weiter voranzutreiben, falls sich die eigenen Prioritäten des Anbieters ändern. Es gibt keinen Server, den man selbst patchen könnte, keine Infrastrukturschicht unter dem Produkt, die der Kunde noch kontrolliert, das Ganze ist die Roadmap des Anbieters, und wenn diese Roadmap neu priorisiert wird, wird die zukünftige Fähigkeit jedes Kunden gleich mit umpriorisiert, ohne eine Möglichkeit, sich davon abzumelden, außer die Plattform ganz zu verlassen.

Das ist das spezifische Risiko, das Sustaining Engineering darstellt, und es lohnt sich, fair gegenüber dem Grund zu sein, warum Salesforce diese Entscheidung getroffen hat: Ein Enterprise-Software-Unternehmen im Jahr 2026, das Investitionen in Richtung Enterprise-KI umleitet, ist angesichts des Marktes eine rationale Geschäftsentscheidung, und Heroku, fast zwei Jahrzehnte alt, ist ein ausgereiftes Produkt mit einer bekannten Form statt einer Wachstumswette. Nichts an der Entscheidung ist unüberlegt oder unehrlich, die Ankündigung selbst ist ungewöhnlich direkt darüber, was sich ändert und warum. Das Risiko ist nicht, dass Salesforce etwas falsch gemacht hat. Es ist, dass jeder Kunde, der vollständig im verwalteten Stack einer Firma steckt, keinen Hebel hat, den er umlegen kann, wenn sich die internen Prioritäten dieser Firma verschieben, weil die Infrastruktur von Anfang an nie ihm gehörte.

Was ein BYO-Server-Modell an diesem spezifischen Risiko ändert

Eine Plattform, die auf Servern läuft, die der Kunde besitzt, kann dieses Risiko nicht vollständig eliminieren, die Control-Plane-Software selbst wird immer noch von einer Firma mit ihrer eigenen Roadmap und ihren eigenen Prioritäten gebaut, die sich verschieben könnten. Aber es ändert, was tatsächlich auf dem Spiel steht, wenn das passiert. Der Server selbst, eine einfache Linux-Box bei DigitalOcean, Hetzner oder Vultr, auf der ein gewöhnlicher Docker-Container hinter einem Standard-Reverse-Proxy läuft, wird nicht altbacken, nur weil sich die Roadmap der Control Plane ändert. Würde Railyard morgen aufhören, neue Features zu liefern, laufen die bereits deployten Apps weiter auf Infrastruktur, die der Kunde schon besitzt und direkt per SSH kontrolliert, ohne Abhängigkeit von Railyards weiterer Entwicklung, um weiter Traffic zu bedienen. Der schlimmste Fall für einen Kunden in diesem Szenario ist, den Zugang zu einem Dashboard und etwas Automatisierungskomfort zu verlieren, nicht die Infrastruktur zu verlieren, auf der die App tatsächlich läuft, weil diese Infrastruktur von Anfang an nie dem Anbieter gehörte.

Das ist die strukturelle Antwort auf „was, wenn die Firma hinter meiner Plattform sie herunterpriorisiert”, und es ist eine bedeutend andere Antwort als alles, was einem Kunden auf einer vollständig verwalteten Plattform zur Verfügung steht. Es erfordert nicht, dass Railyard, oder irgendeine BYO-Server-Plattform, versprechen muss, dass es hier nie passieren wird; es erfordert, dass die Architektur die Konsequenz überlebbar macht, falls es doch passiert, was eine Garantie ist, die ein gemieteter Stack nicht bieten kann, egal wie gut der Anbieter geführt wird.

Die ehrliche Erkenntnis

Herokus Ankündigung vom Februar 2026 ist für niemanden, der heute darauf läuft, eine Krise, und sie ist nicht unehrlich oder schlecht kommuniziert, wenn überhaupt ist sie eine direktere Aussage, als die meisten Firmen geben, wenn sie ein ausgereiftes Produkt herunterpriorisieren. Die eigentliche Lektion betrifft die Risikokategorie selbst: Ein Team, das vollständig von einer verwalteten Plattform abhängt, ist durch die Konstruktion auch vollständig davon abhängig, dass die internen Roadmap-Entscheidungen dieser einen Firma unbegrenzt mit den eigenen Bedürfnissen des Teams übereinstimmen, ohne Fallback, falls sie das nicht mehr tun. Das ist eine echte strukturelle Eigenschaft des Mietens des gesamten Stacks, unabhängig davon, wie gut oder schlecht die Absichten eines bestimmten Anbieters sind, und es lohnt sich, das für sich zu gewichten, getrennt davon, wie die aktuelle Preisgestaltung oder der Feature-Umfang an dem Tag aussieht, an dem sich ein Team anmeldet.

FAQ

Wann ging Heroku in den Sustaining-Engineering-Modus? Herokus Chief Product Officer, Nitin T Bhat, kündigte den Wechsel am 6. Februar 2026 in einem Beitrag mit dem Titel „An Update on Heroku” an.

Schaltet Heroku ab? Nein. Bestehende Apps, Pipelines, Teams und Add-ons funktionieren weiter, und Kreditkarten-Kunden sehen keine Änderung bei Preisen oder Abrechnung. Sustaining Engineering bedeutet keine neuen Features und keine neuen Enterprise-Verträge für neue Kunden, keine Abschaltung.

Wird Heroku neue Features oder Regionen hinzufügen? Die Ankündigung ist explizit, dass neue Feature-Entwicklung künftig nicht der Fokus des Teams ist, was auch bedeutet, dass neue Regionen und neue Framework- oder Laufzeit-Unterstützung nicht zu erwarten sind.

Ist das ein größeres Risiko als eine Preiserhöhung? Es ist eine andere Art von Risiko. Eine Preiserhöhung ist eine Kostenfrage, die man einmal durchrechnen kann. Eine Plattform, die aufhört, sich weiterzuentwickeln, ist ein Risiko, das sich langsam über Jahre summiert, während der Rest der Kategorie weiter liefert und eine eingefrorene Plattform nicht.

Quellen

• Heroku: „An Update on Heroku,” von Nitin T Bhat, Chief Product Officer, veröffentlicht am 6. Februar 2026, Herokus und Salesforce’ eigene primäre Ankündigung
• DeployHQ: „Heroku Enters Sustaining Engineering Mode: What It Means and When to Consider Alternatives”, Analyse der praktischen Implikationen
• DevClass: „Heroku future in doubt as Salesforce freezes features to focus on AI”, unabhängige Berichterstattung über die Ankündigung vom Februar 2026
• Railyards eigene Seite zur Funktionsweise für Details zum Betrieb von Apps direkt auf Infrastruktur, die du kontrollierst

Sieh, wie Railyard konkret für ein Team im Vergleich abschneidet, das einen Umzug evaluiert: Railyard mit Heroku vergleichen, oder sieh wie Railyard auf Servern läuft, die du selbst besitzt.