Am 5. Oktober 2026 hat das Nuxt-Team Version 4.6.0 veröffentlicht – nach eigener Aussage eines der größten Minor-Releases in der Geschichte des Frameworks, mit über 420 Commits seit 4.5.2. Im Zentrum steht eine strukturelle Weichenstellung: Nuxt wird server-agnostisch. Hinzu kommen eine runderneuerte CLI, ein zentrales Application-Secret für Sessions, experimentelle Interop mit Vue 3.6s Vapor Mode und ein neu gebautes, deutlich sparsameres typisiertes Fetch-System.
Inhaltsverzeichnis
Key Takeaways
- Nuxt 4.6.0 erschien am 5. Oktober 2026 mit über 420 Commits seit 4.5.2.
- Neue Import-Quelle
nuxt/serverentkoppelt Server-Code von h3 und nitropack – Code dafür soll unverändert auf Nuxt 5 (Nitro v3, h3 v2) laufen. - Die neue CLI v4 ist 73% kleiner, hat 56% weniger Abhängigkeiten und startet 6,6x schneller.
- Ein zentrales
runtimeConfig.appSecretermöglicht abgeleitete Secrets, unter anderem für cookie-basierte Sessions ohne Serverspeicher. - Vue Vapor Mode lässt sich per Komponenten-Attribut aktivieren, während die App-Wurzel im virtuellen DOM bleibt.
- Typisiertes Fetch senkt den Speicherverbrauch bei 3000 Routen von 946 MB auf 140 MB.
- Nuxt 3 ist seit 31. Juli 2026 End-of-Life, es gibt kein begleitendes 3.x-Release mehr.
Server-agnostische Architektur: die zentrale Änderung in Nuxt 4.6
Bislang importierte serverseitiger Code in Nuxt-Anwendungen direkt aus den Paketen h3 und nitropack. Das klingt nach einem Implementierungsdetail, hatte in der Praxis aber spürbare Folgen: Jedes neue Major-Release von h3 oder nitropack schlug durch das gesamte Ökosystem durch, weil Typen, Handler-Signaturen und Utilities direkt an diesen Unterbau gebunden waren. Modul-Autoren und Projektteams mussten bei jedem großen Upstream-Sprung mitziehen, ob sie wollten oder nicht.
Mit 4.6 löst Nuxt dieses Problem an der Wurzel. Das Framework definiert jetzt eigene Typen für Request-Events, Route-Regeln und typisiertes $fetch und stellt sie über eine neue Import-Quelle namens nuxt/server bereit. Handler, Middleware und Server-Utilities werden künftig gegen diese Nuxt-eigene API geschrieben statt direkt gegen h3 oder nitropack.
Der Clou: Laut Team läuft Code, der auf Nuxt 4.6 gegen nuxt/server geschrieben wurde, unverändert auf dem kommenden Nuxt 5 – obwohl dieses intern auf Nitro v3 und h3 v2 wechselt. Die Abstraktionsschicht soll also genau die Bruchstellen abfedern, die bislang bei großen Versionssprüngen im Unterbau entstanden sind.
Nitro bleibt dabei die Standard-Implementierung für den Server-Build. Parallel führt das Team eine experimentelle Alternative namens @nuxt/vite-server ein, die den Server stattdessen mit Vites Environment API baut. Die Release Notes markieren diesen Ansatz jedoch ausdrücklich als stark experimentell – für Produktionsprojekte also vorerst nichts, worauf man sich verlassen sollte.
Neue CLI v4: kleiner, schneller, interaktiver
Parallel zur Architektur-Änderung hat das Team @nuxt/cli in Version 4 veröffentlicht – ein Rewrite mit Fokus auf Installationsgröße und Startzeit. Die vom Team selbst gemessenen Zahlen fallen deutlich aus:
- Installationsgröße: 13,1 MB -> 3,5 MB (-73%)
- Abhängigkeiten: 70 -> 31 (-56%)
- Erster Paint von
nuxt dev: 330 ms -> 50 ms (6,6x schneller) - Speicherbedarf im Ruhezustand unter Linux: 630 MB -> 440 MB (-30%)
Sichtbarster Unterschied im Alltag: nuxt dev bringt jetzt eine interaktive Terminal-UI mit, die Panels für Error-Logs, Routen und Netzwerk-Requests direkt im Terminal anzeigt – ohne dass man ständig zwischen Terminal und Browser-Devtools wechseln muss.
Eine weitere, auf den ersten Blick unscheinbare Neuerung dürfte für KI-gestützte Entwicklungsworkflows relevant werden: Eine Lock-File im .nuxt/-Verzeichnis erlaubt es einem zweiten nuxt dev-Prozess – etwa gestartet von einem KI-Coding-Agenten im Hintergrund -, den laufenden Dev-Server entweder zu übernehmen oder sich zurückzustellen, statt in einen Portkonflikt oder einen doppelten Watch-Prozess zu laufen. Angesichts der wachsenden Zahl an Agenten, die parallel an Codebasen arbeiten, ist das ein praktischer Baustein gegen kollidierende Dev-Server-Instanzen.
Zusätzlich spendiert die CLI drei neue Befehle: nuxt curl, nuxt task und nuxt docs, die häufige Handgriffe – Request gegen eine Server-Route absetzen, projektdefinierte Tasks ausführen, Dokumentation nachschlagen – direkt ins Terminal holen.
Ein zentrales App-Secret für Sessions
Nuxt 4.6 führt ein neues Root-Secret ein: runtimeConfig.appSecret, gesetzt über die Umgebungsvariable NUXT_APP_SECRET. Aus diesem einen Secret können Module über eine Funktion namens deriveSecret zweckspezifische Unter-Secrets ableiten, statt dass jedes Modul sein eigenes Geheimnis mitbringen und verwalten muss.
Der erste konkrete Anwendungsfall dafür sind neue Session-Helper. Sie verschlüsseln Sessions mit der Bibliothek iron direkt in ein Cookie – ohne serverseitigen Speicher wie Redis oder eine Datenbanktabelle. Für viele kleinere bis mittlere Anwendungen fällt damit eine komplette Infrastrukturkomponente weg, die bislang für simple Login-Sessions vorgehalten werden musste.
Beim Secret-Handling selbst hat das Team auf unterschiedliche Umgebungen geachtet: Im Dev-Modus generiert Nuxt automatisch ein Secret, warnt dabei aber in der Konsole, damit niemand versehentlich mit einem Zufalls-Secret in Produktion geht. Bei echten Builds generiert Nuxt dagegen nie automatisch ein Secret – wird NUXT_APP_SECRET dort nicht gesetzt, muss das Team es bewusst nachtragen, statt sich auf eine unsichere Standardeinstellung zu verlassen.
Vue Vapor Mode Interop
Ein weiterer Baustein von 4.6 betrifft die Interop mit Vues neuem Compilation-Modell. Vue 3.6 führt den sogenannten Vapor Mode ein, der Komponenten ohne virtuelles DOM kompiliert und direkt reaktive DOM-Updates erzeugt. Nuxt 4.6 erlaubt es jetzt, einzelne Komponenten oder Seiten gezielt in diesen Modus zu versetzen: Ein vapor-Attribut auf <script setup> genügt, während die App-Wurzel selbst weiterhin im klassischen virtuellen DOM läuft.
Das erlaubt einen inkrementellen Umstieg: performancekritische Komponenten können schon jetzt von Vapor profitieren, ohne dass die gesamte Anwendung migriert werden muss. Wichtig für die Praxis: Die Funktion erfordert Vue 3.6.0-rc.2 oder neuer. Vue 3.6 selbst ist zum Zeitpunkt des Nuxt-Release noch kein stabiles Release – der aktuelle Stand liegt bei rc.10. Wer die Interop ausprobieren will, bewegt sich also bewusst auf Release-Candidate-Terrain und sollte das bei Produktionsentscheidungen entsprechend einordnen.
Typisiertes Fetch neu gebaut auf fetchdts
Die vierte größere Neuerung betrifft die Typsicherheit von $fetch-Aufrufen gegen Server-Routen. Das Feature wurde komplett neu auf der Bibliothek fetchdts aufgebaut. Statt Typen bei jedem Aufruf gegen die komplette Liste aller Server-Routen aufzulösen, kompiliert Nuxt die Routen jetzt in einen Routen-Baum. Die Auflösungskosten skalieren dadurch mit der Anzahl der Call-Sites im Code, nicht mehr mit der Gesamtzahl der Routen im Projekt.
Der Unterschied ist bei größeren Projekten erheblich: Bei einem Testprojekt mit 3000 Routen und 200 Call-Sites sank der gemessene Spitzenspeicherverbrauch von 946 MB auf 140 MB. Gerade bei großen Monorepos oder API-lastigen Anwendungen mit vielen Server-Routen war der alte Mechanismus ein spürbarer Flaschenhals für die TypeScript-Sprachserver-Performance in der IDE – dieses Problem adressiert der Neuaufbau direkt.
In Nuxt 4 ist typisiertes Fetch weiterhin ein Opt-in-Feature, aktivierbar über experimental.routeTypedFetch. Mit Nuxt 5 soll es zum Standardverhalten werden.
Sicherheitsfixes in 4.6
Neben den größeren Architektur-Themen enthält 4.6 auch gezielte Sicherheitsverbesserungen: Die interne Error-Route ist nur noch über das Error-Rendering selbst erreichbar und lässt sich nicht mehr direkt von außen ansprechen. Außerdem werden keine ungehandhabten Error-Daten mehr ungefiltert an die Error-Seite weitergereicht – eine Härtung gegen ungewolltes Leaken interner Fehlerinformationen an Nutzer.
Upgrade-Pfad: Voraussetzungen und Vorgehen
Für das Upgrade auf 4.6 ist eine aktuelle Node.js-Version Pflicht: unterstützt werden ^22.22.3, ^24.15.0 oder 26 und neuer. Das Team empfiehlt, das Upgrade mit
npx nuxt upgrade --dedupedurchzuführen, damit doppelte beziehungsweise veraltete transitive Abhängigkeiten im Zuge des Upgrades direkt bereinigt werden.
Wichtig für Teams, die noch auf Nuxt 3 unterwegs sind: Nuxt 3 erreichte bereits am 31. Juli 2026 End-of-Life. Es gibt kein begleitendes 3.x-Release zu 4.6 und auch keine weiteren Sicherheitsupdates für die 3er-Linie mehr – der Umstieg auf Nuxt 4 ist an dieser Stelle keine Kür, sondern mittelfristig Voraussetzung für sichere Betriebsfähigkeit.
Fazit
Nuxt 4.6 ist mehr als ein gewöhnliches Minor-Release. Die Entkopplung von h3 und nitropack durch nuxt/server ist eine strukturelle Vorbereitung auf Nuxt 5 und soll dafür sorgen, dass große Unterbau-Wechsel künftig nicht mehr automatisch zu Breaking Changes im Anwendungscode führen. Die schlankere, schnellere CLI und das agent-freundliche Lock-File-Verhalten zahlen direkt auf den Entwickleralltag ein, während App-Secret-Ableitung, Vapor-Interop und das neu gebaute typisierte Fetch zeigen, in welche Richtung sich das Framework technisch weiterentwickelt. Wer produktiv mit Nuxt arbeitet, sollte das Upgrade auf 4.6 angesichts des Nuxt-3-End-of-Life nicht unnötig aufschieben – und dabei prüfen, welche der neuen, teils noch experimentellen Features (allen voran Vapor-Interop und @nuxt/vite-server) schon für das eigene Projekt infrage kommen.
