Nuxt 4.5: Vite 8, Rspack 2, and SSR Streaming Explained

Nuxt 4.5 ships three build-layer changes at once: Vite 8 is now the default bundler, the Rspack builder has been rebuilt on Rsbuild, and SSR streaming is available behind an experimental flag. If you are still running Nuxt 3, the EOL date passed July 31 — you are on unsupported software. This release gives you a concrete reason to upgrade now rather than later.

SSR Streaming: The Feature Worth Enabling This Week

Vue developers have watched React ship Suspense-based streaming for years. Nuxt 4.5 closes that gap. Instead of buffering the entire server-rendered page before sending a single byte, Nuxt now flushes the HTML shell immediately and streams the body as Vue renders it.

The numbers are hard to ignore. One developer measured a streamed TTFB of 16 milliseconds against 2,518 milliseconds buffered — the same total render time, but the browser can start parsing and fetching assets 156 times sooner. Another developer reported a 2-second LCP improvement from a single config change.

Enabling it takes one line in nuxt.config.ts:

// nuxt.config.ts
export default defineNuxtConfig({
  experimental: {
    ssrStreaming: true
  }
})

Nuxt automatically disables streaming for bots and crawlers, so your SEO signals stay intact. For routes where streaming causes problems — anything that mutates response headers, status codes, or cookies after the shell is sent — opt out per-route:

routeRules: {
  '/checkout/**': { streaming: false }
}

This is experimental for a reason. Test it in staging against your full middleware stack before shipping to production. But it is ready to evaluate today, and the TTFB gains are real.

Vite 8: What Changes and What Breaks

Vite 8 — which went stable in March 2026 — is now the Nuxt default. The headline change is that Rolldown, a Rust-based bundler, replaces both esbuild (dev transforms) and Rollup (production builds). Oxc, another Rust toolchain, now handles TypeScript stripping and JSX lowering where esbuild used to.

For most Nuxt apps, this is a transparent upgrade with faster builds. A 19,000-module monorepo benchmark shows Rolldown completing in 1.61 seconds versus Rollup’s 40 seconds. Smaller apps see 2-5x improvements. The upgrade command handles the dependency tree:

npx nuxt upgrade --dedupe

The --dedupe flag matters. Nuxt 4.5 bumps unhead to v3 and unctx to v3, and without it you risk deduplication conflicts that produce subtle runtime errors.

Where developers get caught is custom Vite plugins and configuration. Vite 8 deprecated several esbuild and Rollup-specific options that Nuxt users commonly configure:

• vite.optimizeDeps.esbuildOptions → use vite.optimizeDeps.rolldownOptions
• build.rollupOptions → use build.rolldownOptions
• vite.esbuild → use vite.oxc

Vite converts these automatically for now, but removal is coming. Plugins that reach into Rollup or esbuild internals directly will break without automatic conversion. If you maintain custom Vite plugins, review the Vite 8 migration guide before upgrading. Node 20.19+ or 22.12+ is now required, and the package is ESM-only.

Rspack 2 and Rsbuild: Same API, New Internals

If you use builder: 'rspack', nothing changes on the surface. Under the hood, the Rspack builder has been rebuilt on @rsbuild/core. The webpack-dev-middleware and webpack-hot-middleware that powered the dev server are gone, replaced by Rsbuild’s middleware mode. A new Rspack-specific Vue loader ships with it.

Teams with standard Rspack setups need no changes. Teams with custom Rspack configuration should review it against Rsbuild conventions before upgrading — the API surface differs even though the config entry point is the same. If you are on the default Vite builder, skip this section entirely.

Nuxt 3 Is Now Unsupported

The July 31 EOL date has passed. Nuxt 3 no longer receives security patches. Any CVE disclosed after that date has no upstream fix in the 3.x line. Running Nuxt 3 in production now means accepting that risk indefinitely.

For most apps, upgrading to Nuxt 4 is straightforward. The team designed the migration with compatibility opt-in from Nuxt 3.12 forward, and codemods handle most of the mechanical changes. The biggest unknown is third-party module readiness — run npx nuxt upgrade and see what breaks before writing a single line of migration code.

If you cannot upgrade yet, commercial extended support options exist. But “wait for Nuxt 5” is not a plan without a support contract — it is accumulating security debt with a vague exit date.

What Else Landed in 4.5

A few additions worth noting. The useLayout composable returns the resolved layout for the current route as a computed ref, removing boilerplate reactivity code. Named views now work through a file convention: sidebar@view.vue renders into <NuxtPage name="sidebar" />. The enabled option on useFetch and useAsyncData gates fetching reactively and cancels in-flight requests when set to false. Errors now carry stable codes like NUXT_E1001 for greppable debugging.

The CLI gains nuxt module remove for clean module uninstalls, a non-interactive nuxt init for CI pipelines, and nuxt typecheck with Golar as a vue-tsc alternative. Tracing channels for nuxt.render, nuxt.island, nuxt.data, and nuxt.plugin are available behind tracingChannel: true.

What to Do Now

On Nuxt 4.x: run npx nuxt upgrade --dedupe, check your Vite plugin compatibility, then spend twenty minutes testing SSR streaming on a staging branch. The config is one line. The TTFB improvement potential is significant.

On Nuxt 3: the official Nuxt 4 upgrade guide is the right starting point. Most teams complete the migration in a day. The longer you wait, the more unpatched CVE exposure you carry. The full Nuxt 4.5 release notes cover everything that shipped in this release.