Turbopack Is Production-Stable: What Developers Need to Know

TL;DR:

• Turbopack is now the default bundler in Next.js 15.3+ for development, and production builds reached stability in 2026
• Cold start times in development are 40-70% faster than webpack in most Next.js projects; hot module replacement is significantly snappier on large codebases
• Migration is mostly seamless for standard Next.js projects, but some less-common webpack plugins and loaders don’t yet have Turbopack equivalents — check the compatibility list before committing

When Vercel announced Turbopack at Next.js Conf 2022, the promises were large: 700x faster than webpack, Rust-based, built for incremental computation. It took a few years and a lot of bug fixes to get there. Production stability arrived with Next.js 15 and has been refined through the 15.x series. If you’re running a Next.js app and haven’t evaluated Turbopack recently, the 2026 version is a meaningfully different experience from the early betas.

What Turbopack Actually Changes

Turbopack replaces webpack as the module bundler for Next.js development and production builds. The core architectural difference is that Turbopack is built around Turborepo’s incremental computation engine: it tracks which modules changed and only recomputes what’s affected, at a finer granularity than webpack’s caching.

In practical terms:

Development cold starts: On a large Next.js application (50+ routes, substantial node_modules), webpack cold starts often take 15-30 seconds. Turbopack typically cuts this to 5-10 seconds. On smaller projects, the difference is less dramatic.

Hot module replacement: This is where the difference is most felt day-to-day. Webpack HMR on large projects can take 2-4 seconds per save. Turbopack HMR is typically under 500ms for most file changes.

Production builds: Turbopack production builds are faster than webpack on large projects but not universally so — webpack with persistent caching has caught up on incremental production builds. Cold production builds (no cache) are faster with Turbopack.

Enabling Turbopack in Your Next.js Project

For development, it’s now the default in Next.js 15.3+. If you’re on an older version or have explicitly set --turbo flags, the current approach:

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

Next.js 15.3+ will use Turbopack for both dev and production builds by default. To explicitly opt out and use webpack:

// next.config.js
module.exports = {
  experimental: {
    turbo: false  // force webpack
  }
}

For production builds specifically on 15.3:

next build  # uses Turbopack by default
next build --no-turbo  # force webpack for production

Configuration That Carries Over

Most next.config.js configuration works without changes. The properties that interact with the bundler:

What works the same:

• env, publicRuntimeConfig / serverRuntimeConfig
• images configuration
• Route rewrites, redirects, headers
• TypeScript and ESLint integration
• transpilePackages
• modularizeImports

What has changed or limited support:

• Custom webpack config via webpack function in next.config.js is ignored when Turbopack is active. This is the main migration hurdle.
• Some webpack-specific loaders (particularly raw-loaders, file-loaders with non-standard configurations, and some SVG processing pipelines) don’t have direct Turbopack equivalents yet

Handling Custom Webpack Configurations

If you have a custom webpack function in next.config.js, it will be silently ignored by Turbopack. Common customizations and their Turbopack equivalents:

SVG imports as React components: The @svgr/webpack loader is commonly added via webpack config. With Turbopack, use the official @svgr/turbopack or handle SVGs as URLs and import them into a wrapper component.

Custom aliases: Webpack resolve.alias maps to Turbopack’s resolveAlias in Next.js config:

// next.config.js with Turbopack support
module.exports = {
  turbopack: {
    resolveAlias: {
      '@components': './src/components',
      '@utils': './src/utils',
    }
  }
}

Custom file extensions for TypeScript path mapping: These generally work automatically via tsconfig.json paths — no custom bundler config needed.

Bundle analyzer: @next/bundle-analyzer has been updated to work with Turbopack builds. If you’re on an older version, update it.

Compatibility Checklist Before Migrating

Run through this before switching a production project:

1. Check next.config.js for a custom webpack function — list everything it does and find Turbopack equivalents
2. Search your package.json and imports for babel plugins beyond @babel/preset-env — Turbopack uses SWC, not Babel
3. Check for any webpack-specific plugins (webpack-bundle-analyzer, copy-webpack-plugin, custom loaders) — each needs individual investigation
4. Run next dev with Turbopack on a feature branch and compare the output of next build between webpack and Turbopack on a sample of pages to catch any behavioral differences
5. Check your CSS pipeline — CSS Modules work fine, but PostCSS plugins with complex configurations occasionally behave differently

The Next.js Turbopack compatibility page maintains the current list of webpack features not yet supported.

Practical Performance Numbers (2026 Projects)

Numbers from open-source Next.js projects and community benchmarks in 2026:

Production build times are more variable and depend on CPU core count — Turbopack parallelises across cores more efficiently.

Should You Migrate Today?

If you’re on Next.js 15+ and your webpack config is minimal (or empty), yes — upgrade now. The DX improvement in development is significant and the migration cost is low.

If you have substantial webpack customization, audit the custom config first. You may need a few hours to migrate loaders and aliases to their Turbopack equivalents. For most teams, this is a one-time cost that pays back in cumulative build time savings within the first week.

If you’re on Next.js 13 or 14, the production-stability story is tied to 15.x. Upgrading Next.js first is the prerequisite — the Next.js 15 migration guide documents the breaking changes, most of which are unrelated to Turbopack.