Turbopack in Production With Next.js 15: What's Stable, What Isn't, and the Incremental Adoption Path

Turbopack in production with Next.js 15 is not the same conversation it was a year ago. The next dev --turbo flag is now on by default in Next.js 15, and the Vercel team has made "stable for development" mean something real — consistent HMR, reliable Fast Refresh, and cold-start times that make webpack-based dev feel like a different decade. If you spin up a clean Next.js 15 project and run the benchmarks Vercel publishes, the numbers hold up.

A real application is not a clean Next.js 15 project. It has MDX content pipelines, custom webpack loaders for SVG sprites and icon fonts, a Sentry integration that injects build-time release metadata, perhaps a Symfony backend serving JSON through a custom API layer, and a dozen third-party packages that have never been tested against a Rust-based bundler. The confidence curve for adopting Turbopack in that environment is not the same as the demo, and teams that have moved fast have sometimes moved into a broken build pipeline.

This post is the honest state of Turbopack for Next.js applications in mid-2026: what "stable" actually covers, where the remaining gaps are, and the incremental adoption path that extracts real speed without betting your deployment on an incomplete migration.

What "Stable for next dev" Actually Means

When Vercel declared Turbopack stable for next dev in Next.js 15, the scope was precise. The stability guarantee applies to the development server: hot module replacement, Fast Refresh, module resolution, CSS handling, and TypeScript transpilation. These work reliably for the vast majority of projects, and the regression rate for these features is now low enough that Vercel enabled --turbo by default.

Production builds (next build) are a different story. Turbopack's production build path — replacing webpack for next build entirely — is still in active development. As of Next.js 15.x, next build --experimental-turbo exists behind an experimental flag, and Vercel's own guidance is that it is not ready for production workloads with complex configurations. The features that require most of the remaining work are the ones that real applications rely on: custom webpack loader compatibility, plugin APIs for build-time asset transformation, and the full tree-shaking and chunk-splitting behaviour that determines how large your production bundles actually are.

This distinction matters because it changes what the migration question actually is. You are not deciding whether to adopt Turbopack — you are deciding whether to use it for dev mode (yes, with few caveats), for production builds (not yet for most complex apps), or for both (incrementally, with testing at each step).

The Loader and Plugin Compatibility Matrix

The most consequential compatibility question for real applications is webpack loader support. Turbopack does not run webpack loaders natively. Instead, it provides a turbopack.loaders configuration (in next.config.ts) that maps file extensions to either native Turbopack transforms or to webpack-compatible loaders run in a compatibility shim.

The shim works well for simple loaders — babel-loader with a basic preset, ts-loader, style-loader in dev mode. It starts breaking down with loaders that rely on the full webpack compiler API, access this.emitFile, or manipulate the module graph in ways that assume webpack internals.

In practice, the compatibility picture for common tools looks like this. @svgr/webpack works for basic SVG-to-component transformation but breaks when combined with custom SVGO plugins that call webpack utilities. next-mdx-remote with custom remark/rehype plugins is generally fine. Raw MDX with @next/mdx and a complex remark pipeline has been a source of intermittent issues, particularly around plugin ordering and frontmatter extraction. @sentry/nextjs webpack plugin works for production builds via webpack; Sentry SDK for Next.js handles dev-mode Turbopack separately, and source map upload in Turbopack builds requires explicit configuration that is easy to miss.

The practical test: if your next.config.ts has a webpack function with more than five lines of custom configuration, plan for a debugging session when you enable Turbopack dev mode. Most issues are solvable — usually by moving custom loader configuration into the turbopack.loaders block or by finding that a native Turbopack transform already covers the use case. But they are not zero-effort.

Cold-Start Numbers on a Real Codebase

The performance case for Turbopack dev mode is real, and it is most pronounced at the cold start — the time from next dev invocation to the first page being served. On a codebase with 80 pages, a component library of 200 components, and the typical complement of utility packages, the difference is significant.

With webpack, a cold dev-server start on a mid-range developer machine typically takes between 25 and 45 seconds before the first page request completes. With Turbopack, the same codebase reaches first-response in 4 to 8 seconds. Subsequent page navigations benefit even more dramatically because Turbopack compiles on demand rather than bundling eagerly: routes you do not visit do not get compiled at all, which means that in a large application, Turbopack dev mode feels faster throughout the session, not just at startup.

Hot module replacement latency is also materially better. Webpack HMR in a large Next.js codebase can lag noticeably under heavy dependency graphs — a save-to-reflect time of 2 to 4 seconds on a complex page is not unusual. Turbopack typically brings this to under 500 milliseconds and often under 200 milliseconds for files without deep dependency chains.

These are the numbers that make Turbopack dev mode worth the adoption friction. Developer feedback loops of that speed change how code gets written, not just how fast it gets written.

Where Production Builds Still Break

For teams that have experimented with next build --experimental-turbo, the failure modes cluster around a few areas.

Tree-shaking behaviour diverges from webpack in ways that affect bundle size predictably. Turbopack's tree-shaking is more aggressive in some cases and less aggressive in others. Packages that rely on side effects at import time — older utility libraries, some analytics SDKs, any package that registers globals or patches prototypes on import — can be incorrectly eliminated. The sideEffects field in package.json is your primary control here, but not all upstream packages have it set correctly, and fixing it requires either patching the package or adding explicit import preservation hints.

CSS Modules behaviour in production builds has edge cases around class name hashing that can cause style mismatches between dev and production when you compare Turbopack dev builds against Turbopack production builds. This is being tracked upstream, but it has caused painful deployments for teams that tested in dev mode and assumed production parity.

The chunk-splitting strategy in Turbopack production builds is not yet at webpack's level of configurability. If your application has specific code-splitting requirements — vendor chunks, route-based splitting, specific module boundaries — the next build --experimental-turbo output may not match what you have tuned your webpack configuration to produce. The initial JS payload to the browser can be meaningfully different.

Source map quality for production Turbopack builds is also an area where the tooling is catching up. If your error monitoring workflow depends on precise source maps for symbolication in Sentry or Datadog, validate this explicitly before switching production builds.

The Incremental Adoption Path

Given this state of play, the practical adoption strategy has three phases, and stopping at phase one is a valid production choice for the next six to twelve months.

Phase one: Turbopack for development, webpack for production. This is the path of least resistance and the most defensible choice today. Enable Turbopack dev mode by keeping next dev (it is now the default in Next.js 15), resolve any loader compatibility issues in turbopack.loaders, and leave next build on webpack. Your CI pipeline, your production deployments, and your bundle analysis tooling all stay unchanged. You get the dev-mode speed gains — which are the most impactful for developer experience — with zero production risk.

Phase two: Turbopack dev with production validation. Once phase one is stable, add a parallel CI step that runs next build --experimental-turbo on every pull request but does not gate the deployment on it. Treat failures as information — log them, file issues upstream, build institutional knowledge about where the gaps are. This gives you early warning on production build compatibility without actually routing production traffic through Turbopack builds.

Phase three: Turbopack production builds for select workloads. When next build --experimental-turbo has been green in CI for a sustained period — a month without unexplained differences in bundle size or behaviour — consider enabling it for production on a low-risk deployment target. An internal tool, a staging environment serving real traffic, or a feature branch deployment are reasonable starting points. Monitor bundle sizes, error rates, and source map quality before cutting over primary production.

For Symfony-backed Next.js applications specifically, the additional surface area is the build-time integration between Symfony's API structure and Next.js's static generation paths. These integrations typically involve custom data fetching logic at build time, not custom webpack loaders, which means they are generally lower risk for Turbopack compatibility. The friction is more likely to come from your asset pipeline configuration than from the Symfony API boundary.

Worth the Effort

The Turbopack transition for complex Next.js applications is a real engineering investment, not a flag flip. The developer experience gains from dev-mode adoption are large enough to justify that investment — faster cold starts and near-instant HMR change how your team works day to day. The production build path needs more time, and the incremental adoption approach lets you benefit from what is ready without taking on risk for what is not.

If your Next.js codebase has accumulated significant custom build configuration and you want an outside assessment of the Turbopack migration path before you start, Wolf-Tech helps engineering teams with exactly this kind of technical transition planning. We have worked through build pipeline migrations on production Next.js applications with complex dependency graphs, and configuration audits tend to surface issues early. Reach out at hello@wolf-tech.io or visit wolf-tech.io to talk through your setup.