News

**Nuxt 3 reached its end of life on 31 July 2026.** The announcement came from Daniel Roe, the framework's lead maintainer, in the Nuxt 4.3.0 release of 22 January 2026. If you run a Nuxt 3 application in production, that date has now passed.

The first thing to be clear about is what end of life does **not** mean. Nothing breaks. Your application did not stop working on 1 August, no package was unpublished, and `npm install` still resolves. End of life is a support commitment ending, not a kill switch.

What end of life actually means

What it does mean is that **Nuxt 3 no longer receives security updates or critical bug fixes**. Any vulnerability disclosed from now on will be fixed in the version 4 line and not backported. That is the whole of it, and it is enough: an unpatched framework in the request path of a public application is a liability that grows quietly, on someone else's schedule rather than yours.

There is a detail in this story that deserves more attention than it gets, because it tells you something about the migration itself. **The original end-of-life date was 31 January 2026.** The maintainers opened a discussion to find out how the version 3 to version 4 upgrade was actually going for people, and what they heard led them to extend support by six months, continuing security updates and critical bug fix releases beyond the date they had already announced.

That is a maintainer team behaving well, and it is also a signal worth reading plainly: the upgrade was hard enough, for enough people, to justify moving a published deadline. If you have been putting it off, you are not alone and the project knew it.

The deadline that already moved once

The corollary is less comfortable. **The extension has been used.** A deadline that has already been pushed once, following a public consultation, is not a deadline anyone should expect to move a second time. Planning on that would be planning on goodwill.

• `nuxt/4/file-structure` - the directory layout changes introduced in version 4
• `nuxt/4/default-data-error-value` - the new default value for data and error
• `nuxt/4/deprecated-dedupe-value` - removal of deprecated dedupe values
• `nuxt/4/shallow-function-reactivity` - shallow reactivity for functions
• `nuxt/4/absolute-watch-path` - watch paths become absolute
• `nuxt/4/template-compilation-changes` - changes in template compilation

On the other side of the migration, the current stable release is **Nuxt 4.5.1**. The upgrade itself starts with one command, which the documentation gives for every package manager: `npx nuxt upgrade`, or the `yarn`, `pnpm`, `bun x` and `deno x` equivalents.

That command moves the dependency. It does not rewrite your code, and this is where most of the actual work lives. Nuxt publishes **official codemods** for that part, run through a single migration recipe: `npx codemod@0.18.7 nuxt/4/migration-recipe`. Note the pinned version. The documentation pins it deliberately rather than using `@latest`, so that the transformation you run is the one that was tested against this migration.

The recipe bundles several individual codemods, and they are worth knowing separately, because a large codebase often needs them applied one at a time rather than all at once. They are listed below.

Upgrading: the command and the codemods

None of this makes the migration automatic. Codemods handle mechanical, pattern-matched changes; they do not reason about your application, your modules, or the third-party packages in your dependency tree, which have their own compatibility timelines. Budget time for the parts a tool cannot see. But the mechanical part is genuinely covered, and that is the part people most often assume they will have to do by hand.