Nuxt Support Lifecycle & Release History

Nuxt Major Release Cadence and OSS Support Windows

Each Nuxt major version receives community OSS support until at least six months after the next major version ships -- after which it reaches end-of-life with no further bug fixes or security patches from the core team.

Nuxt targets a new major release roughly once per year, with minor releases every month or so and patch releases weekly. Unlike frameworks with tiered LTS programs, Nuxt does not distinguish between "active" and "security-only" phases within a major cycle -- support is either on or off. When a major version goes EOL, it goes fully unsupported in one step.

The support model looks like this in practice:

One important nuance: the "six months minimum" language means the EOL date for the current major is only knowable after the next major releases. For the current active major, the EOL date shown in the release table above is TBD until that next major ships. Minor and patch releases within a supported major never introduce breaking changes -- only features marked as experimental are allowed to evolve in breaking ways.

Upgrade paths between every consecutive major release are guaranteed by the Nuxt team, which is a meaningful commitment given how disruptive the jump between older major versions was historically.

References: nuxt.com -- Nuxt 2 EOL announcement -- v2.nuxt.com -- LTS & EOL policy

Vue Runtime Drift and Module Ecosystem Decay in EOL Nuxt Versions

Nuxt is tightly coupled to Vue, and when a Nuxt major goes EOL, it typically pairs with an EOL Vue version -- compounding exposure at both the framework layer and the underlying rendering runtime simultaneously.

The most visible day-to-day pain point is the Nuxt module ecosystem. Community modules -- authentication adapters, image optimization, i18n, CMS integrations -- track the current active major. Once a Nuxt major goes EOL, module authors stop publishing compatible versions. You find yourself unable to update a security-relevant dependency without first upgrading Nuxt itself, which may require a full rewrite depending on how far behind you are.

Nitro, the server engine introduced in Nuxt 3, continues to evolve independently. Deployment targets, edge runtime support, and serverless adapter compatibility are updated in Nitro regularly. An EOL Nuxt version ships a frozen Nitro, which means losing access to newer Cloudflare Workers APIs, updated AWS Lambda behavior, or Vercel Edge improvements -- not because Nuxt itself broke, but because the underlying engine stopped moving.

Browser-side rendering is another vector. Vue's SSR hydration behavior and browser compatibility patches land in Vue core releases. An EOL Nuxt running an EOL Vue receives none of these. In practice, this surfaces as subtle hydration mismatches or broken behavior on updated browser engines -- the kind of bug that is nearly impossible to trace back to its root cause without knowing the support status of your stack.

Post-EOL Freeze: What the Nuxt Core Team Stops Maintaining

When a Nuxt major version reaches end-of-life, the OSS core team stops publishing releases entirely -- the version is frozen at its last patch, available on npm indefinitely but receiving no further changes from official maintainers.

There are no backport releases, no security advisories with accompanying fixes, and no official acknowledgement of CVEs against the EOL version. The GitHub repository remains accessible, and community discussion continues, but there is no obligation for any core contributor to respond to issues filed against an EOL major.

Official Nuxt modules (packages under the @nuxt/ namespace) follow the same cutoff. Compatibility with newer Node.js LTS versions, updated TypeScript releases, or changed Vite internals will not be backported. The EOL version's module compatibility matrix is fixed at whatever it was on the last release day.

Migration Direction

The Nuxt team guarantees an upgrade path between every consecutive major version, so the migration strategy is always incremental: move to the next major, stabilize, then continue. Given the significant architectural changes between some major versions -- including the shift to Vue 3, Nitro, and the Composition API -- migration effort varies substantially by project. The official Nuxt upgrade guide documents breaking changes and migration steps per major. For teams that cannot migrate immediately, commercial extended support is available through HeroDevs NES, which provides continued security patches post-EOL.

Detecting Your Active Nuxt Version via CLI and Runtime Inspection

The fastest way to check your Nuxt version is from your project root using the Nuxt CLI or by reading the lockfile directly.

npx nuxt --version

This outputs the version of Nuxt resolved in your current project context. For a more reliable check that accounts for your exact dependency resolution, read directly from node_modules:

node -e "console.log(require('nuxt/package.json').version)"

Or inspect the lockfile to see what was actually installed:

# With npm
npm list nuxt

# With pnpm
pnpm list nuxt

# With yarn
yarn list --pattern nuxt

Inside a running Nuxt application, the version is also accessible at runtime via the useRuntimeConfig context or through the Nuxt DevTools panel if enabled. For server-side inspection in a deployed environment:

# Check package.json in your deployed build output
cat .output/server/package.json | grep '"nuxt"'

Once you have the major version (e.g., 3.x, 4.x), cross-reference it against the release table above to see whether it is actively supported, approaching EOL, or already past end-of-life.