Nuxt 4: what changed and why it is worth upgrading

Quick answer

Nuxt 4 is a pragmatic major release. The headline is not a new visual layer or a dramatic rewrite. The useful work is in structure, data fetching behavior, TypeScript separation, and a cleaner boundary between app code, server code, shared code, public assets, modules, and content.

For new Vue projects that need routing, server rendering, static generation, API routes, and deployment flexibility, Nuxt 4 is a strong default. For existing Nuxt 3 projects, the upgrade is worth planning, especially if the codebase is large enough that file structure, watcher performance, and type boundaries already matter.

If you are planning the upgrade now, use the practical Nuxt 3-to-4 migration guide for the implementation sequence, or see how I approach Nuxt and Vue development and migrations for production teams.

If the larger question is whether the project should stay on Nuxt at all, I also built an equivalent 51-page fixture for a Nuxt vs Astro benchmark and architecture comparison.

The new app directory

Nuxt 4 defaults to an app/ directory for application code. Pages, components, layouts, composables, middleware, plugins, assets, and app-level configuration now have a clearer home.

That sounds like housekeeping, but it matters in real projects. Large repositories become easier to scan, editors have less irrelevant filesystem noise, and the split between Vue app code and Nitro server code is more obvious.

A typical Nuxt 4 project now reads more like this:

app/
  components/
  composables/
  layouts/
  pages/
  plugins/
server/
  api/
  routes/
shared/
  types/
  utils/
public/
nuxt.config.ts

The structure is still familiar, but the boundaries are cleaner.

Data fetching is more predictable

Nuxt 4 reorganizes useAsyncData and useFetch behavior around consistency and memory usage. Calls that share a key also share the same data, error, and status refs. Reactive keys are better supported. Data cleanup is more deliberate when components unmount.

The practical takeaway: keys matter more. If a piece of data depends on a route param, user ID, locale, or filter, make that dependency visible in the key.

const route = useRoute();

const { data, status, error } = await useAsyncData(
  `post-${route.params.slug}`,
  () => $fetch(`/api/posts/${route.params.slug}`)
);

That is better than hiding the dependency inside the fetcher and hoping the framework infers what you meant.

TypeScript gets clearer boundaries

Nuxt 4 splits TypeScript configuration across app, server, shared, and build-time contexts. That helps the editor understand which APIs are available where.

This matters because Vue components, Nitro server routes, shared utilities, and build configuration do not run in the same environment. Treating them as one big TypeScript context creates autocomplete noise and can hide mistakes until later.

For teams, the benefit is simple: fewer unclear imports, better refactors, and a cleaner mental model for where code belongs.

Nitro still carries the deployment story

Nuxt remains strong because Nitro keeps deployment flexible. A Nuxt app can target Node, serverless, static hosting, edge-style runtimes, or hybrid setups depending on the adapter and project requirements.

That flexibility is valuable when product needs change. A marketing site might start static. An authenticated dashboard might need server routes. A content-heavy product might need server rendering and caching. Nuxt lets those choices live inside one coherent stack.

Upgrade planning

Start with the official Nuxt 4 upgrade guide. Then treat the migration as a small engineering project, not a blind dependency bump.

Recommended sequence:

1. Upgrade Nuxt and run the official checks.
2. Move app code into app/ if you want the new default structure.
3. Keep server/, shared/, public/, modules/, and content/ at the root.
4. Review all explicit useAsyncData and useFetch keys.
5. Update test, lint, Storybook, and Tailwind paths if they reference old folders.
6. Run type checking and fix real boundary issues rather than suppressing them.
7. Deploy to a preview environment and test routing, data loading, payload size, and caching.

Who should use Nuxt 4

Nuxt 4 is a good fit for:

• Content and product sites that need server rendering or static generation.
• Vue teams that want routing, data fetching, SEO primitives, and deployment handled together.
• Apps that mix public pages, authenticated areas, and server routes.
• Teams that care about TypeScript and long-term maintainability.

It may be unnecessary for small static pages that do not need Nuxt’s routing, server, and data layer. In those cases, simpler tools can be the better engineering decision.

Final thought

Nuxt 4 feels useful because it tightens the parts of the framework teams touch every day. The app structure is clearer. Data fetching is easier to reason about. TypeScript boundaries are more explicit. Deployment remains flexible through Nitro.

That is the kind of major release I like: less drama, better defaults, and improvements that make the codebase calmer six months after launch.

About the author

Written by Tiago Galvão

Full Stack Developer · Portugal | Switzerland

I've been building for the web since 2001. Full stack development across Vue, Nuxt, Astro, TypeScript, C#, .NET, and PostgreSQL, among others, with a habit of writing down what actually worked and what didn't once the dust settles.

More about me →