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.
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_FOUNDfor 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:
next buildexits with code 0.next startboots but the first request fails (500 or hang).- Reverting to Next.js 15 with the same code works.
- 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#
1. Environment variable (recommended for CI/Vercel)#
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.
2. CLI flag (recommended for local debugging)#
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)#
/** @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#
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:
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)#
- Read the first line after
next startReady. If it's a 500 withCannot find moduleorMODULE_NOT_FOUND, suspect Turbopack first. - Re-run with
NEXT_DISABLE_TURBOPACK=1 next build && next start. If the failure disappears — confirmed. - Check
next.config.mjsfor awebpack(config)function. If present, your loader chain is the missing piece. - Check
package.jsonfor non-standard build scripts (customnodewrappers, monorepo orchestrators). Make sure the env var propagates through every layer. - Check for
experimental.turboflags innext.config.mjs— olderturboconfig keys are renamed in 16; stale flags trigger silent fallback bugs. - 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-turbopackbuild 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.
Related reading#
Frequently Asked Questions
Continue Reading
Next.js 15 vs 14: Real Benchmarks and Whether to Upgrade (2026)
Side-by-side benchmarks on real apps — build time, bundle size, runtime perf, and the breaking changes that hurt. The honest verdict on whether the upgrade is worth it.
Next.js + Supabase Performance: 7 Fixes That Cut Load Time 70%
The 7 optimizations that took a sluggish Next.js + Supabase app from 4.2s LCP to 1.1s — RLS indexes, ISR config, image pipeline, and the connection-pooler trap on Vercel.
I Tanked My Core Web Vitals Score With Next.js Images Here's How I Fixed It
Added images to my Next.js app and watched my Core Web Vitals tank. After debugging for days, here are the 7 fixes that brought my CLS score back to green.
Browse by Topic
Find stories that matter to you.