Fix Next.js 16 Turbopack Production Build Failures (Disable, Workarounds & Stable Config 2026)
Technology

Fix Next.js 16 Turbopack Production Build Failures (Disable, Workarounds & Stable Config 2026)

Next.js 16 makes Turbopack the default builder. If `next start` crashes or pages 500 after a Turbopack production build, here's the exact way to opt out per-build, per-environment, or per-project — and the symptoms that mean you should.

2026-05-19
8 min read
Fix Next.js 16 Turbopack Production Build Failures (Disable, Workarounds & Stable Config 2026)

If you upgraded to Next.js 16, hit a green next build, then watched next start 500 the first request — you are not alone. This is the single largest source of "Next.js 16 disable Turbopack production build" searches right now, and the fix is one environment variable.

The problem#

Next.js 16 ships with Turbopack as the default production builder, not just the dev compiler. For most apps this is fine. For apps with custom Webpack loaders, non-standard next.config plugins, or specific edge-runtime tweaks, the Turbopack production output and the existing runtime expectations don't match — so next start either:

  • Returns HTTP 500 on the first request with Cannot find module './chunks/...'
  • Hangs indefinitely on startup with no logs after Ready in Xms
  • Throws MODULE_NOT_FOUND for a package that builds fine in dev
  • Reports ENOENT: no such file or directory, open '.next/server/...'

Build logs look perfectly normal. That is what makes this confusing — the failure mode is runtime, not build.

Symptoms#

You're hitting this if all of these are true:

  1. next build exits with code 0.
  2. next start boots but the first request fails (500 or hang).
  3. Reverting to Next.js 15 with the same code works.
  4. Build logs do not contain the line info - using Webpack.

If logs say info - using Turbopack and you have a custom Webpack loader, custom next.config.mjs webpack(config) function, or any third-party plugin that hooks into Webpack — you've hit the loader/runtime mismatch.

Root cause#

The runtime that next start boots looks at .next/server/ and expects a specific module map. Webpack and Turbopack produce different maps. Custom webpack(config) overrides in next.config.mjs are silently ignored under Turbopack — your loader chain never ran, so the bundle is missing transformations your code needs. The build finishes because Turbopack's own pipeline is happy; the server crashes because runtime imports point at modules that the missing transforms were supposed to produce.

This is not a bug — it is the documented gap during the Webpack → Turbopack migration. The fix is to opt that specific build out of Turbopack until your loader chain has a Turbopack equivalent.

The fix — three ways#

bash
NEXT_DISABLE_TURBOPACK=1 next build

On Vercel: open the project, Settings → Environment Variables, add NEXT_DISABLE_TURBOPACK=1, and scope it to Production only. Dev and Preview keep Turbopack speed. Production gets the stable Webpack pipeline.

bash
next build --no-turbopack
next start

The flag is explicit in CI logs — when a teammate scans the log six months later they immediately see why this build skipped Turbopack.

3. next.config.mjs (last resort, project-wide)#

js
/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    turbo: false,
  },
};

export default nextConfig;

Avoid this unless you have a very specific reason. Project-wide disable means you lose Turbopack in dev too. Use the env var or the flag and keep your config clean.

Verify the fallback actually happened#

bash
NEXT_DISABLE_TURBOPACK=1 next build --debug 2>&1 | head -5

You should see:

info  - Linting and checking validity of types
info  - Creating an optimized production build
info  - Using Webpack

If the third line still says Using Turbopack, the env var did not propagate. On Vercel double-check that the variable is scoped to the right environment and that you redeployed after adding it (env-var changes don't apply to existing deployments).

Then start the server and curl it locally:

bash
next start &
sleep 2
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:3000
# Expected: 200

If you still get 500, the issue is not Turbopack — pull the actual stack trace from the next start output and treat it as a regular runtime error.

Debug checklist (in order)#

  1. Read the first line after next start Ready. If it's a 500 with Cannot find module or MODULE_NOT_FOUND, suspect Turbopack first.
  2. Re-run with NEXT_DISABLE_TURBOPACK=1 next build && next start. If the failure disappears — confirmed.
  3. Check next.config.mjs for a webpack(config) function. If present, your loader chain is the missing piece.
  4. Check package.json for non-standard build scripts (custom node wrappers, monorepo orchestrators). Make sure the env var propagates through every layer.
  5. Check for experimental.turbo flags in next.config.mjs — older turbo config keys are renamed in 16; stale flags trigger silent fallback bugs.
  6. If you are on Vercel, look at the build log header. It prints both the Next.js version and the active bundler — Turbopack vs Webpack should match what you set.

Prevention#

  • Don't blindly upgrade to Next.js 16 if you have a custom webpack(config) without first running a --no-turbopack build to confirm parity.
  • Keep dev on Turbopack for the iteration speed. Only disable for build/start.
  • Pin the opt-out per environment, not project-wide. When Turbopack adds support for the loader you need, you flip one env var instead of editing config.
  • Add a CI smoke test that runs next build && next start & and curls / with a 10-second timeout. This catches the "builds fine, crashes on start" regression before it reaches users.
  • Watch the Next.js release notes for "Turbopack loader parity" entries. Each release closes more of the gap; you may be able to remove the opt-out within a few minor versions.

When to not disable Turbopack#

If next start runs fine and your only issue is that the build is slower than expected, do not disable Turbopack — slow builds in 16 are usually caused by a misconfigured experimental flag or an oversized barrel import, not Turbopack itself. Profile with next build --profile first.

Disabling Turbopack is the right move when the build is green and the runtime is broken. For everything else, fix the upstream cause and let Turbopack do its job.

Frequently Asked Questions

|

Have more questions? Contact us