Nuxt 3's Clock Runs Out July 31, Right As Nuxt 4.5 Ships

Nuxt 3 has eleven days left

Nuxt 3 reaches end-of-life on July 31, 2026, eleven days from today. That deadline lands eleven days after Nuxt 4.5, which the release notes bill as "our biggest release in a while," shipped on July 18 with three upgrades to the build layer (Vite 8, Rspack 2 on a new Rsbuild pipeline), plus an experimental SSR streaming mode.

The two events landing this close together isn't a coincidence worth over-reading: it looks like a maintenance team clearing its plate before a version goes cold. What matters for anyone still running production Nuxt 3 is simpler: the runway to move is now measured in days, not quarters.

The last easy exit window

Alongside 4.5.0, the Nuxt team shipped v3.21.9, described as one of the last few 3.x releases, backporting the compatible bug fixes from this cycle. After July 31, that backport stream stops.

The framework's own messaging is that the v3-to-v4 upgrade has been smooth for most teams who've made it, and the upgrade guide is current, but "smooth" assumes you're doing it before the safety net goes away: patch backports, an actively maintained migration guide, community attention on your specific error. If you're on 3.x today, this week is the version of "later" you've been deferring to.

Vite 8 is a major bump wearing a minor release's clothes

The headline technical change is that Nuxt now runs on Vite 8 by default, bringing faster cold starts and Rolldown-powered internals. Nuxt frames this as "transparent" for most apps, true if your stack doesn't reach past Nuxt's abstraction layer.

If you carry custom Vite plugins, direct vite.config tweaks, or third-party plugins that pin a Vite major, that transparency doesn't hold. Vite 8 is a major version, and major versions break things minor versions don't. Treat this as integration-sensitive, not patch-level safe: the same trap that catches any team assuming semver alone protects them from surprises.

Three concrete items, in the order they'll stop you. First the dumbest and most blocking: nuxt@4.5.0 raises its Node floor to ^22.19.0 || ^24.11.0 || >=26.0.0. An .nvmrc pinned to 20, an engines.node: >=20, or a CI job still on Node 20 fails before it ever reaches Vite. Second, the object form of manualChunks is removed in Vite 8, not deprecated: if your rollupOptions.output.manualChunks is an object naming vendor chunks, it needs rewriting. Third, cssMinify: true switches from esbuild to Lightning CSS, and the migration guide warns CSS size "might increase slightly"; the fallback is cssMinify: 'esbuild'. Add to that: Rolldown now decides chunking. If your splitting config came from a dated Core Web Vitals audit, re-measure rather than assume parity.

The Rspack rewrite nobody using it will notice, until they debug it

More interesting than Vite 8 is what happened to the Rspack builder, because it's a case study in a pattern worth naming. Nuxt moved the builder onto Rspack 2 and rebuilt it on @rsbuild/core, replacing webpack-dev-middleware and webpack-hot-middleware with an Rsbuild-powered dev server running in middleware mode.

The public surface (builder: 'rspack' in your config, the existing rspack:* hooks) stays identical. Everything underneath it changed. Here is the healthy version of a breaking internal rewrite: the team kept the contract stable while gutting the implementation, so teams on the Rspack builder get the upgrade for free and only need to care if the middleware-mode dev server behaves differently than the webpack-based one did.

The quiet groundwork for Nuxt 5

Buried under the two headline upgrades is a lot of plumbing you're not meant to notice: Nuxt moved to unhead v3 and unctx v3, switched its own build to tsdown, and introduced a stable nuxt/* build output contract, a builders-to-framework contract internal to the Nuxt monorepo, with no bearing on application code, laying groundwork for the Vite Environment API.

One caveat is worth stating, because it contradicts the word "plumbing": moving to unhead v3 is an upstream breaking change. content becomes required on name / property / http-equiv meta, type-narrowing tightens on useHead, and useServerHead / useServerSeoMeta are gone. In 4.5 Nuxt registers a legacy plugin shim while compatibilityVersion is 4, so runtime behaviour holds, but the typecheck of a head-dense app does not. An app with forty or fifty head files is a better detector of this release's real cost than any cold-start benchmark.

None of that ships a feature you'll reach for directly. What it buys is a smaller gap between v4 and v5: the team's stated goal is making that next jump "as boring as possible," the same bet that made v3-to-v4 painless for most people who made it. If you want to start surfacing v5's breaking changes early, future.compatibilityVersion: 5 is already available to opt into in 4.5.

Stable error codes: smaller diffs when things break

This release also ships a stable error-code system. Build and runtime errors now carry a fixed, greppable code (NUXT_E1001, NUXT_B5001) with a short explanation and a suggested fix, instead of a wall of prose you re-diagnose from scratch every time it shows up.

A small change, and it pays off exactly when you're least patient: mid-incident, grepping logs. A stable code is something you can pin a runbook to; a paragraph of prose isn't.

SSR streaming is worth testing, with one sharp edge

The genuinely new capability is experimental SSR streaming: instead of buffering a full page render before sending it, Nuxt flushes the HTML shell immediately and streams the body as Vue renders it, which should meaningfully cut time-to-first-byte on content-heavy routes. Streaming is opt-in (experimental.ssrStreaming: true) and automatically disabled for bots and crawlers, so SEO isn't a trade-off you manage by hand.

The edge worth knowing before you flip it on: because streaming commits the response status and headers with the first byte, anything that mutates the response after rendering starts (a setResponseStatus() call, a cookie write mid-render) silently can't reach the client anymore. Nuxt falls back to buffered rendering automatically across a wider set of cases than you'd guess: the redirect, cache, isr, swr, noScripts and streaming: false route rules, routes with ssr: false, prerendered routes, server-side navigateTo() redirects, and fatal errors raised before the shell is flushed. It also logs dropped mutations in dev so failures aren't silent, and you can opt out per route with routeRules: { '/checkout/**': { streaming: false } }.

The safety net is reasonable, but it cuts both ways: on an app already blanketed in isr or swr (the default reflex on Vercel) streaming will apply almost nowhere and your TTFB win will be zero. The real candidates are uncached, content-heavy dynamic routes. Audit your response-mutating logic before turning this on for anything beyond a content page, and remember your modules mutate responses too: nuxt-security (nonce and header injection via the render:html / render:response hooks), nuxt-seo-utils (it minifies the whole document) and @nuxtjs/i18n (detectBrowserLanguage writes a cookie mid-render) are all invisible to a grep of your own app/ directory.

What we're betting on next week

We're turning SSR streaming on for our own content-heavy routes to see what the TTFB gain actually looks like against a buffered baseline. And we're treating any team still pinned to Nuxt 3 past July 31 as carrying unpatched risk by default, not making a stylistic choice.

If you're one of them, the read is this: the ecosystem's attention (plugin compatibility, community fixes, the next round of Stack Overflow answers) moves to v4 the moment the 3.x branch stops shipping. Every week past the deadline makes the upgrade a little less "smooth" than it would've been today.

→ Get in touch — we'll audit your Nuxt 3 app against the v4 upgrade guide and ship the migration before the clock runs out.