Nuxt Bridge: Is It a Stepping Stone or a Second Migration Nobody Budgeted For?

Bridge earns its keep when there is real Vue 3 learning value to extract from the existing codebase, and when a clean Nuxt 3 cutover would block the team for too long. Concretely, we recommend Bridge in these patterns:

• Large monorepo, small Nuxt slice. Bridge lets the Nuxt app stop fighting Vue 2 issues while the rest of the org migrates. The team learns composables in production code without rewriting routing first.
• Module ecosystem not fully ready. If a critical @nuxtjs/* module you depend on has a Bridge-compatible release but not yet a Nuxt 3–native one, Bridge buys time without forking the module.
• Hard EOL deadline on Vue 2 itself. Bridge uses Vue 3 under the hood, so security questionnaires that ask "are you on a supported Vue version?" can be answered honestly. See supported software clauses.
• SSR is critical revenue. Running Bridge with Vue 3 SFCs gets you most of the runtime perf gains without rewriting Nitro or your hosting setup. Useful when SSR and hydration are tied to a deployment plan you cannot rebuild this quarter.

Bridge becomes the second migration when one of these is true:

• No exit budget. The Bridge phase is funded; the Nuxt 3 cutover is "we'll do it later." Later never gets a sponsor.
• Module choices that pin you. Adopting a Bridge-only auth or i18n shim means you'll rebuild that integration twice.
• Hosting unchanged. If your deployment is still the Node-server-on-EC2 you had in 2020, Nitro's serverless and edge targets are doing nothing for you—Bridge is purely a Vue 3 alibi.
• Org change ahead. If a reorg or platform team is on the way, locking into Bridge now means the new team inherits a pile of shims they didn't choose.

When two or more of those are true, Bridge is more expensive than going straight to Nuxt 3. We have seen teams spend six months on Bridge and then start the "real" Nuxt 3 work—doubling the bill. The never-ending support dynamic is the same shape, just with a different label on the timeline.

The minimal Bridge enablement looks like this:

// nuxt.config.js (Nuxt 2 + Bridge)
import { defineNuxtConfig } from '@nuxt/bridge'

export default defineNuxtConfig({
  bridge: {
    nitro: false,        // start with the legacy server
    vite: true,          // gain dev-server speed
    capi: true,          // unlock Composition API
    typescript: true,
  },
  buildModules: [
    '@nuxt/bridge',
  ],
  // existing modules continue to work
})

Notice nitro: false. Many teams keep the Nuxt 2 server runtime first, prove the Vue 3 + Vite combination is stable, then flip Nitro on as a separate milestone. Doing all four flags at once on day one is the fastest way to a stuck branch.

The single best predictor of a successful Bridge phase is whether the Nuxt 3 cutover has a name, a date, and a line item in the same budget. If the program ends at "we are now on Bridge", it will stay on Bridge. We tell engineering managers to put the off-ramp on the same slide as the on-ramp before the program is approved.

A workable structure is two phases inside one funded program:

1. Phase 1 (Bridge enablement): 4–8 weeks. Goal: Vue 3 SFCs render in production, Vite dev workflow, no Vue 2 CVE exposure for the engine itself.
2. Phase 2 (Nuxt 3 cutover): 8–14 weeks. Goal: Nitro on, modules swapped, Bridge removed. The PR that deletes @nuxt/bridge from package.json is the success criterion.

Treat phase 2 like a real scope-freeze window with named owners. If you cannot fund it now, you probably cannot fund Bridge either—revisit the cost estimate.

Is Bridge supported long-term?

No. It is explicitly a transition tool. Plan exits accordingly.

Can we skip Bridge entirely?

Yes—and many teams should. If your modules have Nuxt 3–native versions and you can afford a 8–14 week focused program, go straight to Nuxt 3. Bridge is for cases where that direct path would block delivery for too long.

Does Bridge fix Vue 2 CVEs?

It moves you onto Vue 3, so the engine-level CVE story is the same as any Vue 3 app. Module-level CVEs depend on which versions you pin. Audit them as part of phase 1.

How do we measure progress on Bridge?

Two simple metrics: percentage of pages rendering with Composition API, and number of Bridge-only shims still in the codebase. The second number should monotonically decrease in phase 2; if it doesn't, the program has stalled.