Nuxt hides most of the build, which is why a senior needs to know what it does: two Vite builds, one Nitro bundling step, and a set of defaults that are right until they are not. The under the hood section covers the pipeline in detail; this page focuses on the tooling knobs you turn in practice.

Know

• Vite 8 (March 2026) runs on Rolldown, a Rust bundler that replaced esbuild and Rollup: one engine for dev pre-bundling and production, Oxc for transforms and minification, faster builds and smaller memory. Vite 7 (June 2025) had made Node 20.19+ and ESM-only the baseline; Vite 8 keeps the Node 20.19+ / 22.12+ requirement, renames build.rollupOptions to build.rolldownOptions, and Nuxt 4.5 made it the default builder (Nuxt 4.4 was still on Vite 7.3).
• Dev: native ESM served on demand, dependency pre-bundling, HMR through the Vue plugin; Nuxt adds the server-side render in dev via Nitro's dev server and the DevTools. nuxt dev --host, --https, --tunnel, --qr for device testing; --profile for startup profiling.
• Production: Nuxt runs a client build (.output/public/_nuxt/* with hashed filenames and a manifest) and a server build (the SSR bundle in .nuxt/dist/server), then Nitro bundles the server with Rollup (Nitro 2) into .output/server for the chosen preset, including the renderer and your server/ routes.
• Chunks: route-based code splitting is automatic (each page is a chunk), plus dynamic imports and lazy components; you influence grouping through vite.build.rolldownOptions.output.codeSplitting (Rolldown's replacement for manualChunks, whose object form Vite 8 removed) and keep entry hashes stable with experimental.entryImportMap. nuxt analyze runs rollup-plugin-visualizer for client and server and prints the largest modules.
• Environment variables: anything read at build time via import.meta.env or process.env in nuxt.config.ts is baked in; anything the running server should read goes through runtimeConfig and the NUXT_* overrides. .env is loaded by nuxt dev/nuxt build (and nuxt preview, with --dotenv), never by the production server, which gets real environment variables.
• Source maps: sourcemap: { server: true, client: 'hidden' } gives stack traces in production and uploads to error tracking without exposing maps publicly; Sentry and similar plugins upload them at build.
• Build performance: nuxt build time is dominated by the two Vite builds and Nitro; wins come from fewer heavy dependencies, optimizeDeps for dev, avoiding giant barrel imports (tree-shaking cannot save you from import { x } from 'huge-lib' when the lib has side effects), vite.build.target matching your browsers, disabling nuxt analyze-only plugins in CI, and caching node_modules and the Nitro output between pipeline steps.
• Migration notes: Vite 7 → 8 removes remaining Rollup-specific plugin hooks in some plugins; check plugins for Rolldown compatibility, the removed manualChunks object form, and CSS minification, which Vite 8 hands to Lightning CSS by default (build.cssMinify: 'esbuild' switches back). Nuxt manages the Vue plugin and Vite version; do not add @vitejs/plugin-vue yourself.
• Alternatives: Nuxt supports builder: 'webpack' and 'rspack' (via @nuxt/rspack-builder) for legacy plugin ecosystems; the default and recommendation is Vite.

How it works

Tuning the client build for stable caching and a smaller entry:

export default defineNuxtConfig({
  sourcemap: { server: true, client: 'hidden' },
  vite: {
    build: {
      target: 'baseline-widely-available', // Vite 7+ default; explicit here
      rolldownOptions: {
        output: {
          // Rolldown: group vendor code so app changes do not invalidate it
          codeSplitting: {
            groups: [
              { name: 'vendor-vue', test: /node_modules\/(vue|@vue|vue-router|pinia)\// },
              { name: 'vendor-charts', test: /node_modules\/(echarts|d3)/ },
            ],
          },
        },
      },
    },
  },
  experimental: { entryImportMap: true }, // keeps entry chunk hash stable across route changes
})

Finding what to cut:

nuxt analyze                    # opens client and server visualisations, prints top modules
NUXT_ANALYZE=1 pnpm build       # equivalent through env in some CI setups

Build-time versus runtime configuration, side by side:

export default defineNuxtConfig({
  // baked at build: changing needs a rebuild
  app: { head: { title: process.env.SITE_TITLE ?? 'Shop' } },
  // read at runtime: NUXT_API_BASE / NUXT_PUBLIC_SITE_URL override per environment
  runtimeConfig: { apiBase: 'http://localhost:4000', public: { siteUrl: 'http://localhost:3000' } },
})

The output you deploy:

.output/
├── public/            static assets, /_nuxt/*.js|css with content hashes (immutable caching), prerendered HTML
├── server/
│   ├── index.mjs      Nitro entry for the preset (node-server here)
│   ├── chunks/        renderer, routes, your server/ code
│   └── node_modules/  externals Nitro decided not to inline
└── nitro.json         preset metadata

Exercise

Be able to say