Nuxt 5
Update
Nitro 3
Integration
SEO & Accessibility
Improvements
Request, Response, Headers and URL primitives, with Rolldown-powered builds and the Vite Environment API underneath. That is a big enough change to justify its own major version, which is exactly the reasoning behind the two-release split. What has changed since I first wrote about this is the timing, and the fact that a surprising amount of the work has landed in 4.x minors instead.compatibilityVersion: 4, and Nuxt 5 carrying the Nitro 3 upgrade and the remaining infrastructure changes.server/tasks/ with defineTask(), then trigger them manually via API endpoints, programmatically with runTask(), or on a cron schedule in your Nitro config. In development, a CLI and a /_nitro/tasks endpoint let you list and run them directly.vercel.json config generated for you at build time. Other targets, Netlify included, aren't supported yet. The task definition is portable; the trigger isn't.crossws — no relation to WebAssembly, which is a mistake I made in the first version of this article — for a unified WebSocket API across runtimes. You enable it with a feature flag and write handlers that follow normal file-based routing, with lifecycle hooks for upgrade, open, message, close, and error.rooms/[room] route therefore gives you isolated broadcast groups for free. And if you only need server-to-client streaming, Server-Sent Events are also supported and considerably simpler to deploy.nitropack is now nitro. Plugins, config helpers, and runtime utilities move with it: defineNitroPlugin becomes definePlugin, and utilities live under subpaths like nitro/cache and nitro/h3. Types come only from nitro/types.jiti.readBody(event) becomes event.req.json(), header helpers become the standard Headers API, createError becomes HTTPError, and defineEventHandler becomes defineHandler. Your existing server/api routes will need attention.swr: false if you want callers to wait for a fresh value. The utilities are also renamed to defineCachedHandler and defineCachedFunction.useAppConfig() on the server. Use a plain file in your server directory instead. This is Nitro's app config, not Nuxt's app/app.config.ts.node becomes node_middleware, the Cloudflare variants collapse into cloudflare_module, vercel-edge becomes vercel with Fluid compute, and edgio is discontinued. Cloudflare bindings also moved to event.req.runtime.cloudflare.Request and Response.experimental.ssrStreaming. Rather than buffering the whole page, Nuxt flushes the HTML shell (head, styles, preload hints, entry scripts) immediately and streams the body as Vue renders it. Streaming is disabled automatically for bots and crawlers, so search engines still get fully rendered HTML, and you can opt individual routes out via route rules.setResponseStatus() in a component, a cookie write in middleware — can't reach the client. Nuxt falls back to buffered rendering for routes with redirect, cache, isr, swr, or ssr: false rules, and warns in development about dropped mutations. Test it against your own response logic before shipping it broadly.compatibilityVersion: 5.useAsyncData and useFetch were reworked in Nuxt 4, and you have them today:getCachedData, which now receives a context object telling you whether the request came from initial load, a manual refresh, or a watcher.data, error, and status refs. Nuxt also drops the data when the last consuming component unmounts, which keeps memory from growing indefinitely.enabled option, added in 4.5, which blocks every execution while false and cancels an in-flight request without clearing existing data. This is the clean answer to dependent and conditional queries.clearNuxtState resets state to its initial value instead of undefined, matching how clearNuxtData already behaves.@nuxt/a11y is out as a public alpha, with support for Nuxt 4.x and 5.x. It also turned out to be a different tool than this article originally predicted, so it's worth describing what actually shipped.@nuxt/a11y is built on axe-core and lives in Nuxt DevTools:nuxt generate or prerendering, the module can write an accessibility report and — this is the useful part — exit with code 1 when violations are found. That makes it a CI gate, not just a dev-time nicety.wcag2a and wcag2aa, for instance) if the full set is noisier than your team can act on.eslint-plugin-vuejs-accessibility covers the other half and integrates with Nuxt's flat config:@nuxt/a11y in DevTools and CI. If you've moved to oxlint, this is one of the few places where it can't replace ESLint yet. oxlint parses the <script> blocks of an SFC but not the template, and the Oxc team has been explicit that this isn't a small gap: eslint-plugin-vue depends on its own compiler and a modified AST, and Vue templates don't expose the JavaScript bindings Oxc's rules need. Since every meaningful a11y rule is a markup rule, oxlint's accessibility coverage in Vue is currently zero. Its jsx-a11y rules apply to JSX only.nuxt/4/migration-recipe codemods cover most of it.future.compatibilityVersion: 5 and see what breaks. This is the single most useful thing you can do, and it replaces the old advice about watching nightly builds. From Nuxt 4.2 onwards it flips a growing set of defaults to v5 behaviour — case-sensitive routing, normalised page component names, typed pages, the Vite Environment API, the Options API compiled out of the client bundle, clearNuxtState resetting to defaults — each individually revertable while you work through them.jiti and relies on Node's native type stripping to load nuxt.config.ts. Update local environments, CI images, and whatever runtime your host is pinned to.server/ against H3 v2, not just "Nitro usage". This is where the actual work is. Body helpers give way to native Request methods, header helpers to the standard Headers API, createError to HTTPError, defineEventHandler to defineHandler. While you're there, check whether you rely on Nitro's useAppConfig() (removed), on a renamed deployment preset, or on event.context.cloudflare (moved).tsconfig per context — app, server, shared, node — so adopt project references and vue-tsc -b before v5 rather than during it. Nuxt 5 then adds noUncheckedSideEffectImports, enables typed pages by default, and drops baseUrl, all of which surface errors at type-check time rather than runtime.node_modules, so a TypeScript entrypoint can't be loaded natively however new the runtime is, and every consumer would have to install jiti to work around it.compatibilityVersion: 5 in a branch, one category of breakage at a time, with the H3 v2 migration budgeted as its own piece of work rather than folded into "the upgrade".baseUrl.@nuxt/a11y is an axe-core scanner in DevTools with a CI report, not a linter. Useful, and no substitute for manual testing with screen readers and keyboards. The built-in SEO module remains a roadmap item.future.compatibilityVersion: 5 lets you adopt v5 behaviour one change at a time from Nuxt 4.2 onward. There are no v5 codemods yet — the team's stated focus after 4.5 is stabilising v5 and building compatibility utilities. In my experience a mid-size production app is a matter of weeks rather than days, driven mostly by how much custom server code you have.