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.

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. That's 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 so type-checking works without a separate build step.

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.

It's a small change that 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. It's 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 for routes using redirect, cache, isr, swr, or ssr: false, and logs dropped mutations in dev so failures aren't silent. That's a reasonable safety net, but audit your response-mutating logic before turning this on for anything beyond a content page.

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 honest 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.