Next.js Turbopack: Complete Guide to the Default Bundler in Next.js 16 (2026)

Updated: June 10, 2026

Next.js Turbopack is the Rust-based bundler that became the default for both next dev and next build in Next.js 16, replacing Webpack for most projects and delivering 2–10× faster cold starts plus near-instant Hot Module Replacement. I've now run Turbopack across three production apps that I previously built with Webpack, and the build-time wins are real, but there are still loaders and plugins that quietly do not work. This guide covers what's supported, how to migrate, the flags that actually matter, and the failure modes I've hit in real codebases.

• Turbopack is stable for next dev in Next.js 15 and stable for next build in Next.js 16 (October 2026), and is the default for new create-next-app projects.
• Rust-based, built on the Turbo engine, and reuses SWC for JS/TS transforms, so no Babel pipeline is involved and no .babelrc support is provided.
• Webpack config.module.rules and most next.config.js Webpack hooks are NOT supported; you configure loaders via turbopack.rules instead.
• HMR is consistently sub-100 ms on multi-thousand-module apps because Turbopack only re-bundles the changed module graph, not the whole route.
• Production builds use persistent on-disk caching (.next/cache/turbopack), so subsequent CI builds with a warm cache can be 5–8× faster than cold Webpack builds.
• Common blockers in 2026: MDX with custom Webpack loaders, next-transpile-modules (now built-in), and some CSS-in-JS libraries that ship raw Babel plugins.

What is Turbopack and why did Vercel build it?

Turbopack is an incremental bundler written in Rust, designed to replace Webpack in Next.js. It uses the same Turbo engine that powers Turborepo's task scheduler: a function-level memoization layer that tracks every input to every compilation step and reuses results when inputs don't change. The result is that editing one component in a 5,000-module app rebuilds only that component's slice of the graph, not the whole chunk.

Vercel started shipping it in beta in Next.js 13 (October 2022) as next dev --turbo. It became stable for development in Next.js 15 (October 2024). With Next.js 16, the production builder (next build --turbopack, soon to be the default) graduated to stable. The architecture matters for understanding the trade-offs: Turbopack reuses SWC (also Rust) for syntax transforms, so there is no Babel pipeline, no babel-loader, and no support for .babelrc files. If your project relies on a Babel plugin that doesn't have an SWC equivalent, that's the migration blocker you'll hit first.

Honestly, coming from the pages-only era, the mental shift is this: in Webpack, configuration was the extension point. In Turbopack, codemods and built-in features are. The bundler exposes a much smaller surface (turbopack.rules, turbopack.resolveAlias, turbopack.resolveExtensions) and absorbs more functionality into the core. That's good for the 95% case and painful for the long tail of bespoke setups.

How do I enable Turbopack in Next.js 16?

In Next.js 16, Turbopack is the default for next dev in new projects. For next build, you opt in with the --turbopack flag (it becomes default in 16.2). Here's the canonical setup:

// package.json
{
  "scripts": {
    "dev": "next dev",
    "build": "next build --turbopack",
    "start": "next start"
  }
}

For an existing Webpack-based project, run the official codemod first. It rewrites incompatible next.config.js patterns into turbopack equivalents:

npx @next/codemod@canary upgrade latest
npx @next/codemod@canary next-config-turbopack ./next.config.js

Then verify in development:

$ npm run dev

  ▲ Next.js 16.0.0 (Turbopack)
  - Local:        http://localhost:3000
  - Network:      http://192.168.1.10:3000

 ✓ Ready in 412ms
 ✓ Compiled /page in 89ms

The (Turbopack) tag in the startup banner confirms the bundler. If you see (Webpack), your next.config.js probably has a webpack() hook that's forcing the fallback. Next.js silently downgrades when it detects unsupported config rather than crashing. Check the dev server logs for a yellow Falling back to Webpack warning; it tells you which option triggered it.

Turbopack vs Webpack: benchmarks and trade-offs

The headline numbers from Vercel's internal benchmarks against vercel.com (~5,000 modules) match what I've measured on the smaller apps I migrated. Cold dev startup went from ~14 seconds with Webpack to ~1.8 seconds with Turbopack. HMR after editing a leaf component went from ~700 ms to ~60 ms. Production builds with a warm cache dropped from 3 min 40 s to ~28 s. The honest caveat: cold production builds (no cache) are roughly comparable, with Turbopack winning by maybe 20–30%, not 10×. The dramatic wins come from the persistent cache and HMR.

Dimension	Turbopack (Next.js 16)	Webpack (Next.js 14)
Cold dev startup (5k modules)	~1.8 s	~14 s
HMR latency (leaf edit)	~60 ms	~700 ms
Cold production build	~95 s	~120 s
Warm CI build (cache hit)	~28 s	~3 min 40 s
JS/TS transforms	SWC (Rust)	Babel or SWC
Plugin ecosystem	Limited (webpack loaders via shim only)	Mature, 10+ years
Bundle analyzer	@next/bundle-analyzer v15.4+ only	Full support
Custom Webpack hooks	Not supported	Fully supported

Is Turbopack production-ready?

Yes, Turbopack is production-ready for next build as of Next.js 16 (October 2026), and it's been production-ready for next dev since Next.js 15. Vercel itself runs Turbopack builds for vercel.com, v0.dev, and the Next.js Conf site, which is a non-trivial proof point. The conformance test suite Vercel publishes shows Turbopack passing >99.8% of the same integration tests Webpack passes, including the long tail of edge cases (CSS Modules ordering, dynamic imports with webpackChunkName comments, RSC payload format).

That said, "production-ready" is not the same as "drop-in for every project." Roughly 1 in 5 migrations I've done required either a config change or removing a dependency that shipped a Webpack-only plugin. The blockers are predictable (see what does NOT work below), so audit your next.config.js and the README of any custom babel-loader setup before flipping the flag in CI. For greenfield projects starting on Next.js 16, just keep the default; you'll never hit these issues.

If you're authoring middleware-heavy routes, also read my guide on migrating middleware.ts to proxy.ts in Next.js 16, since both migrations land in the same release and you'll usually do them together.

Configuring loaders and aliases in turbopack.rules

Turbopack has its own configuration block in next.config.js. The two things you'll touch most are turbopack.rules (file-type loaders) and turbopack.resolveAlias (module aliases). A common case is loading SVG files as React components. Under Webpack that's @svgr/webpack; under Turbopack you wire the same loader through turbopack.rules:

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  turbopack: {
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
    },
    resolveAlias: {
      '@/components': './src/components',
      '@/lib': './src/lib',
    },
    resolveExtensions: [
      '.mdx', '.tsx', '.ts', '.jsx', '.js', '.json',
    ],
  },
}

module.exports = nextConfig

The shape mirrors Webpack's module.rules but is dramatically narrower. Each rule maps a glob to a list of loaders plus an as hint telling Turbopack what the loader output should be treated as (JS, CSS, raw). You cannot run arbitrary Node functions during compilation, which is the limitation that catches teams off guard. If your old setup transformed asset paths in a custom Webpack plugin, you'll need to move that logic to a build-time script.

For TypeScript path aliases, you no longer need resolveAlias at all (Turbopack reads tsconfig.json's paths field directly). That's one of the small quality-of-life wins.

What does NOT work with Turbopack yet

So, here's the honest list as of Next.js 16.0:

• next.config.js webpack() hook: Custom Webpack mutation is unsupported. Turbopack ignores it silently or falls back to Webpack, depending on which fields you touch.
• Babel plugins: No Babel pipeline at all. Tools that ship babel-plugin-* (older styled-components, some lingui setups, babel-plugin-relay) need SWC equivalents. The official SWC documentation lists current alternatives.
• Custom CSS preprocessors via Webpack loaders: Sass, Less, and PostCSS work out of the box. Stylus and exotic preprocessors require manual loader config and may not work at all.
• next-transpile-modules: Deprecated; use transpilePackages in next.config.js instead. The codemod handles this.
• MDX with custom remark/rehype plugins via a Webpack loader: Use @next/mdx's native config block; it routes through Turbopack correctly.
• require.context: Webpack-specific magic. Replace with import.meta.glob (Vite-style, supported) or an explicit barrel file.
• Module Federation: Not implemented. Stay on Webpack if you depend on it.

Troubleshooting common Turbopack errors

Three errors account for about 80% of the support questions I see when teams migrate. Here's the fix for each.

"Module not found: Can't resolve 'X'" after migrating

Usually means a package was being transpiled by a Webpack loader you didn't know about. Add it to transpilePackages:

// next.config.js
module.exports = {
  transpilePackages: ['some-esm-only-package', '@org/internal-ui'],
}

HMR works but full reload happens on every save

Your component file probably exports a non-component value alongside the component. React Fast Refresh requires that every export from a file is a component. Move constants and utilities to a separate file. I hit this exact bug shipping a settings page where a constants object lived next to the default export, and the full reloads were maddening until I split the file.

CSS Modules class name collisions

Turbopack's CSS Modules hashing is different from Webpack's. If you have e2e tests asserting on generated class names, update them, or better, switch your selectors to data-testid attributes, which I'd recommend regardless.

For more nuanced HMR and Suspense interactions, see my deep-dive on Next.js streaming and Suspense. Turbopack's incremental graph plays nicely with Suspense boundaries but reveals a class of "stale Suspense" bugs that Webpack's slower HMR happened to mask.

Speeding up CI with persistent Turbopack cache

The biggest unlock for CI is the on-disk cache at .next/cache/turbopack. Cache it between runs and warm builds become dramatically cheaper. Here's the GitHub Actions snippet I use:

- name: Cache Turbopack
  uses: actions/cache@v4
  with:
    path: |
      .next/cache/turbopack
      .next/cache/swc
    key: turbopack-${{ runner.os }}-${{ hashFiles('package-lock.json') }}-${{ github.sha }}
    restore-keys: |
      turbopack-${{ runner.os }}-${{ hashFiles('package-lock.json') }}-
      turbopack-${{ runner.os }}-

- name: Build
  run: npm run build

The two-level restore-keys fallback is intentional: the exact-SHA key gives perfect cache hits on retries, the lockfile-keyed fallback recovers most of the cache when a single source file changed, and the OS-only fallback rescues you after a lockfile change. For Vercel deployments, this caching happens automatically (you don't need to configure it). The cache directory is roughly 100–400 MB for a medium-sized app, so make sure your CI runner has the disk budget. If your CI also runs the Docker standalone build pipeline, mount the cache as a build secret so it survives across multi-stage layers.

One last note: don't commit .next/cache. It's already in the default .gitignore generated by create-next-app, but I've seen folks remove it. The cache contains absolute paths and machine-specific data and will cause non-determinism if shared via git. For the official supported feature matrix, the Next.js Turbopack reference is the canonical source.

Frequently Asked Questions

Is Turbopack faster than Vite?

For Next.js apps, yes. Turbopack is generally faster than Vite on both cold start and HMR once your app passes ~1,000 modules, because Turbopack's function-level memoization scales better than Vite's per-module invalidation. For very small projects the difference is negligible. Vite is also not a drop-in option for Next.js, since they're different toolchains, not direct alternatives.

Does Turbopack support Webpack plugins?

No, Webpack plugins (anything that hooks into compiler.hooks) are not and will not be supported, because the underlying compilation model is too different. Webpack loaders, however, are partially supported through turbopack.rules; loaders that only transform source text typically work, but loaders that depend on the Webpack compilation context (like file-loader with custom publicPath logic) often don't.

How do I roll back to Webpack if Turbopack breaks my build?

Remove the --turbopack flag from your build script and add --webpack to next dev as well: "dev": "next dev --webpack". Webpack remains supported in Next.js 16 specifically for migration cases; the official deprecation timeline points to removal in Next.js 18 at the earliest.

Why does my dev server still say Webpack after I enabled Turbopack?

Most often it's because next.config.js contains a webpack() function that Turbopack can't honor, so Next.js silently falls back. Check the dev server startup logs for a yellow warning. Remove or migrate the webpack() hook to a turbopack block, then restart.

Does Turbopack work with tools like Storybook or Jest?

Storybook 9 ships an official Turbopack builder; earlier versions need to stay on Webpack. Jest doesn't use a bundler so the question doesn't really apply, since it uses SWC directly via next/jest. Vitest with the vite-plugin-next integration also works independently of Turbopack.