Next.js-Entwickler in Nürnberg

#Next.js aktuell halten: Versionen, Support und Sicherheitsreleases

Ich bin Mariusz Szatkowski, Einzelentwickler aus Gdynia, und arbeite seit 2006 mit WordPress, inzwischen auch mit Next.js. Ich arbeite remote und schriftlich: Sie schildern Ihr Vorhaben, meine Rückfragen und der vereinbarte Umfang landen in einem Dokument. Besuche bei Ihnen und Anrufe gibt es nicht.

Diese Seite behandelt eine Frage, die erst nach dem Livegang beginnt: Wie lange bekommt eine Next.js-Version Sicherheitsfixes, und wie plane ich den Wechsel auf die nächste? Grundlage sind die Support-Seite, die Upgrade-Anleitungen und der Blog auf nextjs.org sowie die npm-Registry, abgerufen am 11. November 2026. Die Registry führte an diesem Tag 16.4.6 als aktuelle Version, veröffentlicht am 9. November 2026.

#Wie lange eine Next.js-Version Sicherheitsfixes bekommt

Die Support-Seite kennt zwei Phasen. Solange der nächste Hauptrelease fehlt, ist eine Version Active LTS und bekommt neue Funktionen, Fehlerbehebungen und Sicherheitspatches. Danach folgt Maintenance LTS: nur noch kritische Fehlerbehebungen und wesentliche Sicherheitsupdates, zwei Jahre ab dem Erscheinen der Version. Für Next.js 15 wurde diese Phase über das ursprüngliche Ende am 21. Oktober 2026 hinaus verlängert. Sicherheitsreleases für 15 erscheinen nach der Seite bis zum 31. Januar 2027.

Zwei Zeilen der Seite sind für die Planung wichtig. Updates der Maintenance-Phase erscheinen als Minor-Versionen, auch wenn sie inkompatible Änderungen enthalten. Und außerhalb der Policy patcht das Team nur in seltenen Fällen, je nach Schwere des Fehlers. Wer auf 14 oder älter läuft, plant also nicht mit einem Fix, sondern mit dem Wechsel.

Foto: Diego Delso, CC BY-SA 3.0, Wikimedia Commons.

#Der 31. Januar 2027 und die Spielwarenmesse

Die Spielwarenmesse 2027 ist laut ihrer Webseite (Stand 11. November 2026) für den 2. bis 6. Februar 2027 in Nürnberg angesetzt. Das Ende der Sicherheitsreleases für Next.js 15 liegt zwei Tage davor. Wer für Aussteller, Handel oder Zulieferer eine Anwendung auf Version 15 betreibt, sollte den Wechsel auf 16 abgeschlossen haben, bevor Katalogseiten, Terminbuchung und Anmeldeformulare unter Last stehen. In der Messewoche selbst ändere ich an einer laufenden Anwendung nichts, was sich vermeiden lässt.

Rückwärts gerechnet heißt das: Staging-Zweig im Dezember anlegen, schriftliche Abnahme im Januar, Livegang mit Abstand zum Termin. Weil die Seite das Datum schon einmal verschoben hat, plane ich nicht mit einer weiteren Verlängerung.

#Wie oft eine neue Next.js-Version erscheint

Einen festen Takt für Feature-Versionen gibt es nicht. Die Zeitstempel der npm-Registry zeigen für Version 16 Abstände von 57 bis 138 Tagen:

Bei den Minor-Versionen von 15 lagen zwischen 15.0.0 und 15.5.0 jeweils 42 bis 82 Tage. Patch-Versionen kommen dichter: Zwischen 16.4.0 am 6. Oktober und 16.4.6 am 9. November 2026 liegen sechs Patch-Releases in 34 Tagen. Für den Betrieb folgt daraus: Neue Funktionen zwingen selten zum Upgrade, Sicherheitsfixes schon. Ich plane deshalb den Kalender um die Sicherheitsreleases herum, nicht um die Feature-Versionen.

#Sicherheitsreleases: Ankündigung, Inhalt, Reaktion

Seit dem Beitrag vom 13. Juli 2026 gibt es ein formales Programm. Etwa einmal im Monat erscheint auf dem Blog eine Vorankündigung mit Zeitplan und der höchsten erwarteten Schwere, damit sich Updates planen lassen. Dringende Lücken und solche, die schon ausgenutzt werden, bekommen weiter außerplanmäßige Patches.

Ein Blick auf die letzten Wochen zeigt, was das für die Praxis heißt:

• 14. Oktober 2026: Das Update in 16.4.1 und 15.5.28 behob zwei als kritisch eingestufte Probleme, beide mit Remote Code Execution ohne Anmeldung: eines bei use cache-Funktionen, die mehrere typisierte Arrays zurückgeben, eines in der Bildoptimierung bei SVG unter glibc-Linux. Für das erste nennt der Beitrag keine Umgehung. Für das zweite nennt er als Behelf sharp ab 0.35.5. Dazu kam ein Denial of Service in App-Router-Anwendungen mit mindestens einer Server Action, hohe Schwere. Pages-Router-Anwendungen sind davon laut Beitrag nicht betroffen.
• 27. Oktober 2026: Die Ankündigung sprach von sieben Problemen mittlerer Schwere für den 3. November.
• 3. November 2026: Das Release in 16.4.5 und 15.5.29 führt sieben Advisories auf, davon eines mit hoher Schwere: Cache Components mit gleichzeitigem Aufruf einer Funktion direkt und über unstable_cache kann Inhalte zwischen Mandanten vermischen. Die übrigen sechs sind mittel, darunter Probleme nur bei Selbsthosting und bei Edge-Routen.

Zwei Folgerungen für meinen Ablauf. Die angekündigte Schwere ist eine Erwartung, ich lese immer das veröffentlichte Advisory. Und jedes Advisory nennt Voraussetzungen: Router, Cache Components, Selbsthosting, Edge-Runtime. Ob eine Lücke Ihre Anwendung trifft, entscheidet dieser Abschnitt, nicht die Überschrift. Beim React2Shell-Advisory CVE-2025-66478 vom Dezember 2025 etwa waren nach der Aussage des Beitrags Next.js 13, stabile 14er-Versionen, der Pages Router und die Edge-Runtime nicht betroffen, und für jede betroffene Minor-Linie von 15.0 bis 16.0 gab es eine eigene Fixversion.

Die Beiträge vom Oktober und November nennen je Hauptversion genau eine Minor-Linie. Ich plane Sicherheitsupdates deshalb als Wechsel auf die genannte Linie und nicht als Rückportierung auf eine ältere.

So gehe ich mit einer Ankündigung um:

1. Das Veröffentlichungsdatum kommt in den Kalender, mit freiem Zeitfenster für den Tag.
2. Am Veröffentlichungstag lese ich die Advisories und prüfe die Voraussetzungen gegen Ihre Konfiguration.
3. Die installierte Version lese ich aus dem Lockfile und mit npm ls next, nicht aus der package.json.
4. Das Update läuft auf dem Staging-Zweig: Build, Tests, Durchklicken der betroffenen Bereiche.
5. Live geht es nach Ihrer schriftlichen Freigabe. Bei einer Lücke, die laut Next.js-Team bereits ausgenutzt wird, hat sie Vorrang vor allem anderen in meinem Kalender. Eine feste Frist nenne ich nicht zu.
6. Empfiehlt ein Advisory, Zugangsdaten zu tauschen, ist das ein eigener Punkt im Umfang.

#Minor und Patch: ein Befehl, danach den Diff lesen

Der offizielle Weg ist ein Codemod. Er hebt Next.js, React und React DOM an und führt passende Codemods aus:

git switch -c upgrade/next-patch
npx @next/codemod upgrade patch
git diff package.json package-lock.json
npm run build

Statt patch akzeptiert der Befehl minor (der Standard bei stabilen Versionen), major, ein Dist-Tag oder eine genaue Version wie 16. Ist die Zielversion nicht höher als die installierte, passiert nichts. Wer React nicht mitziehen will, setzt --skip-react-upgrade.

Ein Detail aus der Codemod-Dokumentation halte ich für wichtig: Läuft der Befehl in einer CI oder einer anderen Shell ohne Terminal, nimmt er jede Voreinstellung an, darunter ein React-Upgrade über Version 18 hinaus und das Einschalten von Turbopack. Ich lasse ihn deshalb lokal auf dem Zweig laufen und lese das Ergebnis, bevor etwas auf den Server geht.

Seit 16.4 erinnern next dev und next build an Upgrades. Die Option experimental.agentUpgrade kennt laut Ankündigung von 16.4 die Werte security (Standard, meldet nur Upgrades gegen bekannte Lücken), latest und false. Sie ersetzt keine Planung, ist aber ein zusätzlicher Hinweis.

#Von 14 über 15 auf 16: was jede Hauptversion verlangt

Die Anleitungen auf nextjs.org beschreiben je einen Schritt. Für die Planung ziehe ich daraus diese Übersicht:

Beim Schritt auf 16 verlangt die Anleitung, zusätzlich den Codemod für die asynchronen Request-APIs auszuführen, weil der Upgrade-Befehl nicht jede Migration abdeckt:

npx @next/codemod@latest next-async-request-api .
npx next typegen

next typegen erzeugt seit 15.5 die Typhilfen PageProps, LayoutProps und RouteContext für die asynchronen Parameter. Wo der Codemod nicht automatisch migrieren kann, setzt er Kommentare mit @next-codemod-error und kurzzeitig Casts wie UnsafeUnwrappedCookies. Beides gehört vor dem Abschluss weg, ich zähle diese Stellen im Diff.

Fünf Stellen, an denen ein Upgrade auf 16 nach der Anleitung hakt:

• Eigene webpack-Konfiguration: next build nutzt jetzt Turbopack und bricht bei einer gefundenen webpack-Konfiguration ab. Es bleiben --turbopack, eine Migration der Konfiguration oder --webpack. Manchmal setzt ein Plugin die Option, ohne dass Ihr Projekt eine hat.
• Edge-Middleware: proxy läuft auf Node.js und kann nicht auf die Edge-Runtime umgestellt werden. Die Checkliste der Anleitung sagt ausdrücklich, Edge-Middleware sei nicht blind umzubenennen.
• Bilder: images.minimumCacheTTL steigt von 60 Sekunden auf 4 Stunden, lokale Bilder mit Query-String brauchen images.localPatterns.search, und Weiterleitungen sind auf drei begrenzt.
• Linting: next lint ist entfernt, der Codemod next-lint-to-eslint-cli stellt auf die ESLint-CLI um. eslint-config-next@16 verlangt ESLint 9 oder neuer.
• Entfernte Flags: experimental.dynamicIO und experimental.useCache sind weg. Jeder verbliebene Verweis in der next.config ist ein Fehler.

#React-Version und Abhängigkeiten

Die Anleitung für Version 15 nennt React und React DOM 19 als Mindestversion und rät, @types/react und @types/react-dom mitzuziehen. useFormState ist durch useActionState ersetzt. Der App Router in Next.js 16 nutzt laut Anleitung React Canary mit den Funktionen von React 19.2, und Next.js 16.4 liefert React 19.3 mit.

Die npm-Registry zeigt allerdings ein anderes Bild: Die Peer-Abhängigkeiten von next 15.5.29 und 16.4.6 erlauben weiterhin ^18.2.0 oder ^19.0.0. Beides stimmt nebeneinander. Die Checkliste in der Anleitung fragt nach den React-Anforderungen für den Router der jeweiligen Anwendung, und ich lese sie pro Projekt, nicht aus dem Peer-Bereich.

Meistens scheitert ein React-Upgrade an Drittpaketen, die React 18 als Peer festschreiben. Die Anleitung empfiehlt dann, react, react-dom, die Typen und react-is auf den früheren Stand zu setzen, soweit die Zielversion von Next.js und der Router das tragen, und die Installation mit --skip-react-upgrade zu wiederholen. Ich prüfe vorab, welche Pakete im Lockfile React 18 verlangen, damit das keine Überraschung auf dem Zweig wird.

#So plane ich einen Upgrade-Zweig auf Staging

Die Anleitungen schließen mit einer Checkliste, deren letzter Punkt für mich der wichtigste ist: Ein grüner Build allein schließt Laufzeitbefunde nicht ab. Mein Ablauf:

Fehlen Tests, schreibe ich nicht nachträglich eine Suite für das ganze Projekt. Ich benenne die Pfade, an denen ein Fehler teuer wäre, und prüfe diese von Hand auf der Vorschau. Ob daraus ein eigener Testauftrag wird, entscheiden Sie schriftlich.

#Patch-Management und das BayLDA

Artikel 32 der DSGVO verlangt geeignete technische und organisatorische Maßnahmen unter Berücksichtigung des Stands der Technik und, unter anderem, ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung ihrer Wirksamkeit. Ich gebe keine Rechtsberatung, und für Next.js-Anwendungen kenne ich keine veröffentlichte Prüfung. Auf der Seite zu den Datenschutzprüfungen führt das Bayerische Landesamt für Datenschutzaufsicht (BayLDA) aber Prüfungen zum Patch-Management auf, die zeigen, welche Frage die Behörde stellt.

Eine Prüfung zu WordPress lief laut Seite vom 8. Februar bis zum 29. August 2018 bei 172 Websites, mit den Prüfgrundlagen § 9 BDSG a. F. und Art. 32 DSGVO. Eine Prüfung zu Magento-Shops begann am 30. Oktober 2018: Aus 100 zufällig gewählten bayerischen Shops wurden die 20 mit Magento näher kontrolliert, auch darauf, ob ein geregelter Prozess zum Patch-Management und zum Umgang mit Sicherheitsverletzungen besteht. Die Seite zeigt Prüfungen aus 2018, sie sagt nichts über heutige Schwerpunkte.

Für Ihre Next.js-Anwendung folgt daraus kein Rechtsrat, aber eine Arbeitsweise: Ich halte je Update die Version vorher und nachher, das Datum, die Prüfung auf Staging und Ihre Freigabe schriftlich fest. Ob das für Ihr Unternehmen genügt, klärt Ihre Datenschutzberatung.

#Was ich vor einem Upgrade-Projekt von Ihnen brauche

#So läuft ein Upgrade aus Nürnberg bei mir

1. Ihre Anfrage. Sie schicken Adresse, Version, Hoster und Wunschtermin.
2. Meine Rückfragen, schriftlich. Meist zu Router, Node.js, Middleware und Abhängigkeiten.
3. Umfang als Dokument. Leistungen, Ausschlüsse und Annahmen stehen darin. Ich beginne nach Ihrer schriftlichen Bestätigung; zusätzliche Wünsche schätze ich getrennt ein.
4. Staging-Zweig. Sie sehen jeden Stand auf einer Vorschau-URL.
5. Abnahme gegen den Umfang. Offene Punkte kommen als Liste zurück.
6. Danach. Auf Wunsch spiele ich Patches und Sicherheitsreleases weiter ein, im Rahmen der Wartung in Nürnberg. Nicht genutzte Stunden eines Monats gehen nicht in den nächsten über.

Was Sie mitbringen: Ein Upgrade ändert das Aussehen nicht. Brauchen Sie neue Ansichten, liefern Sie Gestaltung, Mockups und Wireframes oder lassen sie von Ihrer Agentur erstellen; ich setze sie als responsives Frontend um und entwerfe nichts selbst. Zugang zu Repository, Hosting und, falls vorhanden, CMS brauche ich ab dem Start.

#Verwandte Seiten für Nürnberg

• Wartung und Support in Nürnberg: für laufende Updates mit schriftlichem Monatsbericht.
• Migration von Next.js zu Astro in Nürnberg: wenn die Anwendung eigentlich eine Inhaltsseite ist und weniger Framework genügt.
• Astro Entwickler in Nürnberg: für Seiten ohne viel Interaktion.
• WordPress Entwickler in Nürnberg: wenn WordPress die Inhalte liefert.
• Headless CMS Entwickler: wenn Inhalte und Frontend getrennte Systeme sind.

#Fragen aus Nürnberger Anfragen

#Wie lange bekommt Next.js 15 noch Sicherheitsupdates?

Nach der Support-Seite von nextjs.org bis zum 31. Januar 2027. Das ursprüngliche Ende der Maintenance-Phase war der 21. Oktober 2026 und wurde verlängert. Version 14 und älter sind laut Seite nicht mehr unterstützt. Ich plane den Wechsel auf 16 deshalb vor dem 31. Januar und nicht danach.

#Muss ich bei jedem Sicherheitsrelease sofort aktualisieren?

Zuerst lese ich die Veröffentlichung und prüfe, ob die genannten Voraussetzungen Ihre Anwendung treffen, etwa App Router, Cache Components, Selbsthosting oder Edge-Routen. Bei kritischen Lücken ohne Umgehung, wie im Oktober 2026 bei den zwei als kritisch eingestuften Problemen, hat das Update Vorrang. Bei mittleren Problemen, die Ihre Konfiguration nicht berühren, kann es mit dem nächsten Staging-Zyklus laufen.

#Kann ich von Next.js 14 direkt auf 16 springen?

Die Upgrade-Anleitungen von nextjs.org beschreiben je einen Schritt, 14 auf 15 und 15 auf 16. Ich gehe deshalb eine Hauptversion nach der anderen, mit Build und Prüfung dazwischen. Das ist nicht aufwendiger als ein Sprung, nur sauberer zu lokalisieren, wenn etwas bricht.

#Muss mit dem Upgrade React 19 kommen?

Die Anleitung für Version 15 nennt React 19 als Mindestversion. Die Peer-Abhängigkeiten von next 15.5.29 und 16.4.6 in der npm-Registry lassen weiterhin auch React 18.2 zu. Die Checkliste der Anleitung fragt nach den React-Anforderungen des jeweiligen Routers. Ich entscheide deshalb pro Projekt und prüfe, welche Bibliotheken noch an React 18 hängen.

#Kann ich middleware.ts einfach in proxy.ts umbenennen?

Nur wenn die Datei nicht auf der Edge-Runtime laufen muss. Laut Anleitung für Version 16 unterstützt proxy die Edge-Runtime nicht, sie ist dort Node.js. Wer die Edge-Runtime braucht, behält middleware. Der Codemod middleware-to-proxy benennt Datei und Funktion um, die Prüfung der Laufzeit bleibt Handarbeit.

#Was schicke ich Ihnen für eine erste Einschätzung?

Die Next.js-Version aus der package.json, ob Pages Router oder App Router, die Node.js-Version beim Hoster, die Adresse der Anwendung und einen Termin, der nicht kollidieren darf. Ein Lockfile und Zugang zum Repository beschleunigen die Einschätzung, sind für die erste Antwort aber nicht nötig.

#Ihr Next.js-Upgrade in Nürnberg

Läuft Ihre Anwendung noch auf Version 14 oder 15, steht ein Termin wie die Spielwarenmesse an, oder wollen Sie einfach wissen, wo Sie stehen: Schreiben Sie mir über das Kontaktformular. Nennen Sie die Adresse der Anwendung, die Version aus der package.json, den Router, den Hoster und den Termin, bis zu dem es erledigt sein soll. Meine Antwort kommt an Werktagen schriftlich; die erste Einschätzung ist kostenlos.