Wartung und Update-Strategie für Next.js-Projekte: Wie Sie das nächste Support-Ende nicht verpassen

Ein Mittwoch im Oktober 2026. Irgendwo in einem deutschen KMU läuft eine Next.js-Website seit zwei Jahren zuverlässig – oder so scheint es. An diesem Tag endet still und ohne Banner die offizielle Maintenance-LTS-Phase von Next.js 15. Kein Alarm, keine automatische E-Mail von Vercel. Wer nicht weiß, dass es die Support-Policy gibt, und wer keinen Prozess hat, der solche Termine überwacht, erfährt davon schlimmstenfalls erst beim nächsten Sicherheitsvorfall.

Das ist keine Panikmache. Es ist ein strukturelles Problem im Betrieb von Webanwendungen: Nach dem Launch gilt die Aufmerksamkeit selten dem Framework-Lebenszyklus. Dabei unterscheidet sich Next.js von klassischem WordPress in einem entscheidenden Punkt – es gibt keinen One-Click-Update-Button und keine eingebaute Erinnerungsfunktion. Updates erfordern Entwicklerwissen, Testumgebungen und manchmal erheblichen Anpassungsaufwand. Wer das zu lange aufschiebt, zahlt dafür.

Dieser Artikel erklärt, wie die Support-Policy von Vercel aufgebaut ist, was das konkret für Ihren Betrieb bedeutet, und welche Bausteine eine tragfähige Update-Strategie ausmachen – damit Next.js-Wartung kein Notfallprojekt bleibt.

Was die Next.js Support-Policy wirklich bedeutet

Die offizielle Support-Policy von Next.js kennt genau zwei Phasen für jede Major-Version:

Active LTS ist die Phase, in der eine Major-Version aktiv weiterentwickelt wird. Sie erhält neue Features, reguläre Bugfixes, Performance-Verbesserungen und Security-Patches. Diese Phase endet, sobald die nächste Major veröffentlicht wird.

Maintenance LTS beginnt mit dem Release der Nachfolger-Major. In dieser Phase liefert Vercel nur noch kritische Bugfixes und wesentliche Sicherheitsupdates. Die Maintenance-Phase dauert zwei Jahre nach dem ursprünglichen Release-Datum der jeweiligen Major.

Daraus ergibt sich für Next.js 15 folgende Rechnung: Release war der 21. Oktober 2024. Zwei Jahre später, am 21. Oktober 2026 (einem Mittwoch), endet die Maintenance-LTS-Phase nach der Policy-Definition. Die Policy-Seite selbst nennt dieses Enddatum nicht ausdrücklich und bezeichnete 15.x am 23. Oktober 2026 noch als „Supported version" mit Status „Maintenance LTS". Drittquellen wie endoflife.date führen den 21. Oktober 2026 als Ende des Security-Supports. Vercel selbst hat das Datum nicht mit einem Blogpost kommuniziert.

Wichtig zu verstehen: Ab dem Ende der Maintenance-Phase sind laut Policy keine Sicherheitsupdates mehr zugesagt. Eine explizite Ausnahme hält die Policy fest – bei besonders schwerwiegenden Lücken kann Vercel auch Versionen außerhalb der LTS-Policy patchen. Das ist jedoch nicht planbar und keine verlässliche Grundlage für den Betrieb.

Aktuelle Versionen im Überblick (Stand 23. Oktober 2026)

Was daraus folgt: Wer heute noch Next.js 14 oder älter betreibt, erhält definitiv keine Sicherheitsupdates mehr. Wer auf 15.x ist, hat nach der Policy seit dem 21. Oktober 2026 keinen zugesagten Patch-Support mehr. Wer auf 16.x ist, sollte die Maintenance-Updates aktiv verfolgen und den Migrationszeitpunkt für die nächste Major im Blick behalten.

Warum das Risiko im Betrieb systematisch unterschätzt wird

Next.js hatte zwischen Mai und Oktober 2026 eine außergewöhnlich hohe Frequenz an Security-Releases – Patches im Mai, Juli, August, September (teilweise Out-of-Band) und Oktober. Mehrere davon wurden als kritisch eingestuft:

• Oktober 2026 (14.10.): GHSA-2464-fhr4-w9xw / CVE-2026-96889 – kritische Remote Code Execution in der Image Optimization API bei SVG-Dateien; betroffen alle Versionen ab 10.0.0 bis einschließlich 15.5.27, gepatcht in 15.5.28.
• August 2026 (25.08.): GHSA-2xp9-vwfh-vxw4 – ebenfalls RCE in der Image Optimization API, diesmal bei AVIF-Dateien; gepatcht in 15.5.24.
• August 2026 (25.08.): GHSA-p293-qw3h-jr36 / CVE-2026-75604 – RCE auf Windows-gehosteten Servern; gepatcht in 15.5.24.
• Mai 2026: Mehrere Middleware- und Proxy-Bypässe, darunter CVE-2026-44575 und CVE-2026-45109, gepatcht in 15.5.16 bzw. 15.5.18.

Das Muster ist eindeutig: Wer die Maintenance-Releases nicht zeitnah einspielt, hat über Wochen hinweg bekannte, öffentlich dokumentierte Sicherheitslücken im produktiven Betrieb. Bei kritischen RCE-Lücken ist das kein akademisches Risiko.

Erschwerend kommt hinzu, was viele nicht wissen: Updates in der Maintenance-LTS-Phase erscheinen als semver-minor, können aber Breaking Changes enthalten. Die Policy sagt das ausdrücklich. Das bedeutet, dass ein Update von 15.5.16 auf 15.5.18 im schlimmsten Fall Verhaltensänderungen einführt, die in einem ungetesteten Deployment sichtbar werden. Kleine Versionsnummern sind kein Freibrief für fehlende Tests.

Die Bausteine einer tragfähigen Next.js Update-Strategie

Eine sinnvolle Next.js-Wartung besteht aus mehreren Ebenen, die zusammenspielen müssen. Keine davon ist optional.

Regelmäßige Minor- und Patch-Updates

Minor- und Patch-Updates sollten in einem festen Rhythmus eingespielt werden – nicht nach Gefühl, sondern nach Kalender. Ein monatlicher Update-Slot ist für die meisten Projekte sinnvoll. Dabei wird geprüft, welche neue Version vorliegt, was sich im Changelog geändert hat, ob die Änderungen Auswirkungen auf eigene Funktionalität haben, und nach dem Einspielen werden automatisierte Tests durchgeführt.

Diesen Rhythmus konsequent einzuhalten ist anspruchsvoller, als er klingt. Wer das intern kaum schafft, schiebt Updates typischerweise auf – bis aus drei Versionssprüngen fünf werden und ein Update zum Kleinstprojekt mutiert.

Security-Releases zeitnah einspielen

Security-Releases folgen keinem regelmäßigen Rhythmus. Sie erscheinen, wenn eine Lücke bekannt wird und gepatcht ist. Die GitHub Security Advisories des Repositories vercel/next.js sind die maßgebliche Quelle. Wer diese nicht aktiv überwacht, erfährt von einem kritischen Patch oft erst verzögert – wenn überhaupt.

Vercel hat im Juli 2026 einen formalen Security-Release-Prozess eingeführt. Das ändert nichts daran, dass die Überwachung aktiv erfolgen muss. GitHub bietet für Repositories die Möglichkeit, Security-Advisory-Benachrichtigungen zu aktivieren – das ist eine Mindestvoraussetzung.

Bei Out-of-Band-Releases, wie sie im September und Oktober 2026 vorkamen, ist Reaktionszeit entscheidend. Eine kritische RCE-Lücke ist nach dem Advisory-Erscheinen öffentlich. Die Zeitspanne, in der ein System ungepatcht ist, ist die Angriffsfläche.

Testautomatisierung und Staging-Umgebung

Ohne eine Staging-Umgebung und automatisierte Tests ist jedes Update ein Blindflug. Das gilt besonders für Next.js, weil das Framework tief mit der Anwendungslogik verzahnt ist – serverseitige Komponenten, Middleware, Image-Optimierung, Routing und Build-Konfiguration sind alle Framework-abhängig.

Eine minimale Testbasis für ein Next.js-Projekt umfasst:

• End-to-End-Tests für die wichtigsten Nutzer-Flows (Startseite, Kontaktformular, Checkout, Loginprozess), idealerweise mit Cypress oder einem vergleichbaren Tool
• Build-Validierung im CI-Prozess – ein fehlgeschlagener Build auf dem Staging-Server ist kein Produktionsausfall
• Lighthouse-Checks auf kritischen Seiten, um Performance-Regressionen durch Framework-Updates zu erkennen
• Visuelle Regressionstests für designintensive Seiten, wenn das Budget es erlaubt

Wer diese Basis hat, kann Security-Releases schnell einspielen – weil der Testprozess in Minuten läuft, nicht in Stunden manueller Durchklick-Tests.

Node.js-Version des Hostings mitpflegen

Next.js 16 setzt Node.js 20.9.0 oder höher voraus. Wer auf Next.js 15 war und auf 16 migriert, muss sicherstellen, dass die Hosting-Umgebung diese Mindestversion erfüllt. Das klingt trivial, wird aber regelmäßig vergessen – besonders wenn Hosting und Entwicklung in verschiedenen Händen liegen.

Node.js selbst hat einen eigenen LTS-Zyklus. Wer Next.js pflegt, muss die Node.js-Version im Blick behalten und rechtzeitig aktualisieren, bevor eine Node-Version unsupported wird und das Hosting-Update ein separates Projekt wird.

GitHub Security Advisories aktiv beobachten

Die GitHub Security Advisories für vercel/next.js sind die primäre Quelle für Sicherheitsmeldungen. Sie sind über die API abrufbar und lassen sich in Monitoring-Systeme oder Benachrichtigungsdienste einbinden. Mindestens sollte das Team, das für Next.js-Wartung verantwortlich ist, Repository-Watch mit Security-Advisory-Benachrichtigungen aktivieren.

Eine Übersicht über aktuelle Advisories gibt es unter https://github.com/vercel/next.js/security/advisories. Die Einträge enthalten betroffene Versionen, Patch-Versionen und – wo vorhanden – Workarounds.

Major-Upgrades: Rechtzeitig planen, nicht unter Druck umsetzen

Der Schritt von Next.js 15 auf 16 ist kein Routine-Patch. Er enthält Breaking Changes, die je nach Projektgröße und -komplexität erheblichen Anpassungsaufwand bedeuten.

Die wichtigsten Änderungen, die beim Upgrade auf 16.x berücksichtigt werden müssen:

Turbopack ist Standard. Ab Version 16 nutzen next dev und next build standardmäßig Turbopack. Wer eine eigene webpack-Konfiguration hat, muss damit rechnen, dass der Build fehlschlägt. Der Ausweg ist entweder die Migration auf Turbopack oder die explizite Nutzung des --webpack-Flags. Eine bestehende Webpack-Konfiguration einfach mitzunehmen funktioniert nicht mehr.

Async-only für Request-APIs. Synchroner Zugriff auf cookies(), headers(), draftMode(), params und searchParams wurde vollständig entfernt. Alle diese APIs sind jetzt ausschließlich asynchron nutzbar. Das betrifft auch Metadaten-Generatoren für opengraph-image, twitter-image, icon und apple-icon. Projekte, die diese APIs synchron nutzen, laufen nach einem naiven Upgrade nicht mehr.

middleware wurde zu proxy umbenannt. Die Middleware-Datei und der Middleware-Export sind deprecated. proxy läuft außerdem nur noch auf Node.js, nicht mehr auf dem Edge-Runtime. Wer Middleware für Authentifizierung oder Redirects nutzt, muss diesen Bereich explizit migrieren.

next lint entfernt. Das eingebaute Lint-Kommando wurde aus Next.js herausgelöst. ESLint-Flat-Config ist jetzt Standard. Wer next build bisher automatisch linten ließ, muss das in der CI-Pipeline neu konfigurieren.

Node.js-Mindestversion: 20.9.0. Node 18 wird nicht mehr unterstützt. Das muss vor dem Upgrade im Hosting geprüft werden.

TypeScript-Mindestversion: 5.1.0.

Vercel stellt für den Großteil dieser Änderungen automatische Codemods bereit:

npx @next/codemod@canary upgrade latest

Der Codemod deckt die häufigsten Migrationspunkte ab – stellt die Config auf Turbopack um, migriert next lint und bereinigt experimentelle Flags. Für den asynchronen Request-API-Zugriff gibt es einen separaten Codemod:

npx @next/codemod@canary next-async-request-api .

Codemods nehmen Arbeit ab, ersetzen aber keinen vollständigen Test-Durchlauf auf einer Staging-Umgebung. Manuelle Überprüfung bleibt notwendig.

Praxisbeispiel: Hypothetischer Upgrade-Ablauf für ein mittelgroßes Next.js-Projekt

Nehmen wir ein hypothetisches KMU-Projekt: Eine Next.js 15-Unternehmenswebsite mit Kontaktformular, CMS-Integration über eine Headless-API und einem einfachen Authentifizierungsbereich. Das Team plant den Upgrade auf 16.x drei Monate vor dem Policy-Ende.

Woche 1 – Analyse: Abhängigkeiten prüfen, Breaking Changes gegen den eigenen Code abgleichen, offene Risiken dokumentieren. Node.js-Version im Hosting prüfen (läuft 18.x? → muss vor dem Next.js-Upgrade auf 20.x angehoben werden).

Woche 2 – Staging-Upgrade: Codemods ausführen, Build auf Staging prüfen, manuelle Durchklick-Tests auf Kernflows, automatisierte E2E-Tests ausführen. Erwartetes Problem: Die eigene Middleware für Login-Redirects nutzt synchronen cookies()-Zugriff → manuell umschreiben.

Woche 3 – Bugfixes und Retest: Identifizierte Probleme beheben, erneuter Testlauf, Performance-Check via Lighthouse.

Woche 4 – Produktions-Deployment: Deployment im Wartungsfenster, Monitoring für 48 Stunden aktiv, Rollback-Möglichkeit vorbereitet.

Dieser Ablauf ist keine Garantie für reibungslose Upgrades, zeigt aber: Wer drei Monate Zeit hat, kann methodisch vorgehen. Wer erst handelt, wenn das Policy-Ende bereits überschritten ist, macht das gleiche Projekt unter Druck – und mit erhöhtem Risiko.

Rollen und Verantwortung klar definieren

Eines der häufigsten Probleme in der Next.js-Wartungspraxis ist nicht fehlendes Know-how, sondern ungeklärte Zuständigkeit. Nach dem Launch ist oft unklar, wer welche Verantwortung trägt:

• Wer überwacht die GitHub Security Advisories?
• Wer entscheidet, ob ein Security-Release innerhalb von 24 Stunden oder innerhalb einer Woche eingespielt wird?
• Wer führt das Update durch und wer testet es ab?
• Wer informiert den Auftraggeber?

Ohne klare Antworten auf diese Fragen passiert das, was in der Praxis häufig passiert: Updates werden verschoben, weil niemand explizit zuständig ist, bis ein Incident den Anlass erzwingt.

Ein Wartungsvertrag für Next.js-Projekte löst dieses Problem strukturell. Er definiert Reaktionszeiten für Security-Releases, legt Update-Zyklen fest, stellt Testkapazität bereit und macht klar, wer informiert und wer entscheidet. Das ist kein bürokratischer Overhead – es ist der Unterschied zwischen planbarer Wartung und ungeplantem Notfallaufwand.

Wie solche Vereinbarungen kostenstrukturell aufgebaut sind, erklärt unser Artikel zu Software-Wartungsvertrag Kosten – der Next.js-spezifische Umfang geht darüber hinaus, weil Framework-spezifisches Know-how und Testing-Infrastruktur einkalkuliert werden müssen.

Was nach dem Policy-Ende passiert – und was nicht

Eine verbreitete Fehlannahme: Nach dem Ende der Maintenance-Phase bricht die Website sofort zusammen. Das stimmt nicht. Next.js 15.5.28 funktioniert am 22. Oktober 2026 genauso wie am 20. Oktober 2026.

Was sich ändert: Sicherheitslücken, die ab diesem Zeitpunkt entdeckt werden, bekommen laut Policy keinen 15.x-Patch mehr zugesagt. Vercel behält sich in seltenen Fällen vor, auch Versionen außerhalb der LTS-Policy zu patchen – aber das ist eine Ausnahme, keine Regel.

Die Frage ist also nicht, ob die Website aufhört zu funktionieren, sondern wie lange das Risikofenster offen bleibt. Die Frequenz der Security-Releases in 2026 – mehrere kritische CVEs allein zwischen August und Oktober – zeigt, dass Next.js eine aktiv angegriffene Angriffsfläche ist. Wer auf einer unsupported Version läuft, hat keine zugesagte Patch-Versorgung mehr.

Daneben wächst mit der Zeit der technische Abstand. Bibliotheken und Abhängigkeiten entwickeln sich weiter, Node.js LTS-Versionen wechseln, Hosting-Umgebungen aktualisieren. Wer zu lange auf 15.x bleibt, macht den späteren Upgrade auf 16.x nicht einfacher – er macht ihn größer und riskanter, weil sich Abhängigkeiten und Breaking Changes akkumulieren.

Der Artikel Next.js 15 End of Life: Was das Support-Ende für Unternehmen bedeutet und was jetzt zu tun ist beschreibt ausführlich, was das konkrete Support-Ende für laufende Projekte bedeutet und welche Schritte jetzt prioritär sind.

Abgrenzung: Wann reicht interne Wartung – wann nicht?

Für Teams mit einer erfahrenen JavaScript/TypeScript-Entwicklerin und einer CI-Pipeline, die Next.js-Builds abdeckt, ist viel von dem Beschriebenen intern umsetzbar. Der nötige Zeitaufwand für einen geregelten Update-Zyklus beträgt bei einem mittelgroßen Projekt erfahrungsgemäß zwei bis vier Stunden pro Monat für Minor/Patch-Updates – zuzüglich deutlich mehr für Major-Upgrades.

Intern wird es dann schwierig, wenn:

• kein Entwickler dauerhaft für Framework-Updates verantwortlich ist
• keine Staging-Umgebung existiert oder Tests fehlen
• Security-Advisories nicht aktiv beobachtet werden
• das Projekt nach dem Launch an eine Agentur übergeben wurde, die keinen laufenden Wartungsvertrag hat
• ein Major-Upgrade ansteht, aber die notwendige Testkapazität fehlt

In diesen Fällen ist ein externer Wartungsvertrag keine Komfortleistung, sondern eine Betriebsvoraussetzung. SW Business Solutions betreut Next.js-Projekte im laufenden Betrieb: Update-Management, Security-Monitoring über die GitHub Advisories von vercel/next.js, automatisierte Tests auf Staging und geplante Major-Upgrades mit Analyse, Codemod-Ausführung und Testabnahme.

Wenn Sie mehr darüber wissen möchten, was technische Betreuung für Webanwendungen strukturell umfasst, lohnt ein Blick auf unseren Artikel zur Website-Wartung und technischen Betreuung für KMU – und auf die Perspektive, die DevSecOps für Webanwendungen auf Abhängigkeiten und Schwachstellen im laufenden Betrieb eröffnet.

Unsere Projekterfahrung mit Next.js-Projekten – darunter die MobiKart Buchungswebsite – Next.js (MobiKart Funracing GmbH), die HPS Pitbike Website – Next.js Marketing & Booking (Motorradcenter Stralsund GmbH) und die Website der Bootssattlerei Götze & Karowski GbR – zeigt, dass Next.js-Projekte nach dem Launch keine Plug-and-forget-Systeme sind. Der Framework-Zyklus läuft unabhängig davon weiter, ob jemand ihn beobachtet oder nicht.

Nächste Schritte: Was jetzt zu tun ist

Wenn Sie ein Next.js-Projekt betreiben und noch keinen strukturierten Wartungsprozess haben, sind das die sinnvollen ersten Schritte:

1. Version prüfen: Welche Next.js-Version läuft produktiv? package.json oder npx next --version geben Auskunft.
2. Node.js-Version prüfen: Welche Node-Version nutzt das Hosting? Deckt sie die Mindestanforderungen der genutzten Next.js-Version?
3. Letzte Patch-Version vergleichen: Ist die produktive Version die aktuellste Patch-Version des jeweiligen Minor-Zweigs? Wenn nicht, warum nicht?
4. GitHub Security Advisories aktivieren: Repository-Watch auf vercel/next.js mit Security-Advisory-Benachrichtigung einschalten.
5. Staging-Umgebung und Tests bewerten: Gibt es eine Testumgebung? Gibt es automatisierte Tests, die einen Next.js-Update-Lauf validieren?
6. Verantwortlichkeiten klären: Wer ist für Update-Management zuständig? Gibt es eine Vereinbarung mit einem externen Dienstleister?

Wenn Sie diese Fragen nicht sicher beantworten können oder wenn die Antworten zeigen, dass Lücken bestehen – sprechen Sie uns an. Wir analysieren den Status Ihres Next.js-Projekts und zeigen Ihnen, was ein realistischer Wartungsprozess für Ihr Setup bedeutet.

Next.js für Unternehmen erklärt zudem, wann sich das Framework für welche Projekttypen eignet – eine sinnvolle Grundlage, wenn ein Relaunch oder eine Neuentwicklung ansteht und Sie technologisch auf dem richtigen Pfad bleiben wollen.