Nuxt 3 End of Life —
EOL, Risk & Migration to Nuxt 4

Nuxt 3 reaches end of life on July 31, 2026. From that date the 3.x line receives nothing further from the Nuxt project — no security patches, no critical bug fixes, no compatibility updates. Nuxt 3.21.10, released on July 27, 2026, was the last release before the date. One trailing patch followed: 3.21.11 shipped 2026-08-05 with bug fixes only, and its release notes say it plainly — “Nuxt v3 is now end-of-life. Please upgrade to Nuxt v4.” Treat 3.21.11 as the final 3.x release and the project’s own closing statement, not as a sign the line is still maintained.

The detail most coverage misses: this deadline has already moved once. Nuxt 3's original end-of-life date was January 31, 2026 — six months after Nuxt 4 shipped, per the project's standard policy. In the v4.3.0 release notes on January 22, 2026, project lead Daniel Roe extended it by a further six months after gathering community feedback on the v3-to-v4 upgrade experience, committing to "continue to provide security updates and critical bug fix releases beyond the previously announced end-of-life date." July 31, 2026 is the end of that extension, and there is no indication a second one is coming.

This page is the reference for Nuxt end-of-life: every version's EOL date and EOL Risk Score™, exactly what stopped being maintained on that date, why upgrading to Nuxt 4 does not buy you a known runway, and the extended-support options if you cannot migrate yet.

Key Dates at a Glance

• Nuxt 3: active support ends 2025-07-16; end of life 2026-07-31
• Nuxt 2: active support ends 2022-11-16; end of life 2024-06-30
• Nuxt 1: active support ends 2018-09-21; end of life 2019-09-21

Nuxt Version EOL Schedule

Nuxt's policy is to support each major version for a minimum of six months after the next major ships. With Nuxt 3 having reached EOL on July 31, 2026, Nuxt 4 is the only maintained generation. Scores below are live EOL Risk Scores™ — click any to see the full breakdown.

What Actually Stopped Shipping

"Nuxt 3 is EOL" understates the blast radius, because Nuxt is not a single package. The end-of-life boundary covers the framework and the server stack underneath it. Since July 31, 2026, no 3.x-line fixes have been issued for:

• 01
  Nuxt 3 itself The framework core — routing, rendering, the module system, and the build pipeline.
• 02
  Nitro, the server engine This is the part teams forget. Nitro is the server that actually runs your application in production — it handles routing, request handling, and deployment adapters. A vulnerability here is a server-side vulnerability, not a browser-side one, and it will not be patched on the 3.x line.
• 03
  h3, the HTTP layer The request/response primitives Nitro is built on. Same reasoning: this is code sitting directly on the network edge.
• 04
  Official modules and bundled dependencies The first-party module ecosystem pinned to Nuxt 3, and the dependency versions the 3.x line locks you to.

That combination is what makes this a different kind of front-end EOL. A pure client-side framework going unsupported exposes your users' browsers. Nuxt going unsupported exposes your server too — Nitro and h3 terminate real HTTP requests. Any team treating this as "just a front-end upgrade we'll get to next quarter" has mis-scoped the risk. For the wider pattern, see why EOL software is a blind spot for CVE scanners.

The Catch: Nuxt 4 Has No Fixed EOL Date

The obvious move is to upgrade to Nuxt 4. It is the right move — but be clear-eyed about what it buys you, because the honest answer is an unknown runway.

Migrating from Nuxt 3 to Nuxt 4

The good news: Nuxt 4 was deliberately a stability-focused release, and the 3-to-4 migration is far smaller than the Vue-2-to-3 or Nuxt-2-to-3 jumps were. Most of the work is mechanical, and the Nuxt team ships codemods that automate the largest piece.

• 01
  Get current on Nuxt 3 first Move to 3.21.11, the final 3.x release, before attempting the major upgrade. This gets you every deprecation warning and compatibility fix the team shipped in preparation, so you are migrating from the cleanest possible starting point.
• 02
  Run the migration codemods The Nuxt team partnered with Codemod to automate the bulk of the upgrade. Run the full recipe with npx [email protected] nuxt/4/migration-recipe, or apply them individually — nuxt/4/file-structure, nuxt/4/default-data-error-value, and nuxt/4/deprecated-dedupe-value.
• 03
  Adopt the new app/ directory structure Nuxt 4 defaults to an app/ folder as the source root. Move assets/, components/, composables/, layouts/, middleware/, pages/, plugins/, utils/, and app.vue into it. Leave nuxt.config.ts, content/, layers/, modules/, public/, shared/, and server/ at the project root. This is what nuxt/4/file-structure automates.
• 04
  Check your data fetching for shared keys useAsyncData and useFetch now use a singleton pattern: calls sharing a key share unified data, error, and status refs. If two call sites used the same key with different options, that previously worked and now needs reconciling. This is the change most likely to cause a subtle runtime bug rather than a build error — review it by hand.
• 05
  Use the compatibility flags to stage the work You do not have to take every change at once. srcDir: '.' keeps the old directory layout, experimental.granularCachedData: false restores the previous data-fetching behaviour, and experimental.normalizeComponentNames: false keeps the old component naming. Ship the upgrade behind these flags, then remove them one at a time.
• 06
  Expect stricter TypeScript Nuxt 4 enables noUncheckedIndexedAccess by default and generates separate tsconfigs for app, server, node, and shared contexts. This surfaces real latent bugs, but it will produce type errors in code that compiled cleanly under Nuxt 3. Budget time for it rather than being surprised by it.

Extended Support If You Can't Upgrade Yet

For a large Nuxt 3 application — especially one with heavy Nitro customisation, custom deployment adapters, or a long tail of community modules that have not been updated for Nuxt 4 — migration is a real project. That is a legitimate reason it has not happened yet. It is not a reason to run an unpatched HTTP server in production while it proceeds.

Extended (post-EOL) support closes that gap. Specialist vendors maintain security-patched builds of end-of-life lines — backporting fixes for newly disclosed vulnerabilities — so your application stays protected while you migrate on a realistic timeline rather than an emergency one. Coverage for Nuxt currently spans the 2.x and 3.x lines, and more than one vendor operates in this market, which is worth knowing before you accept the first quote you are offered.

Frequently Asked Questions