GUIDES · BUILD CONFIGURATION
Next.js 16 build fails with a webpack config: Turbopack is now the default
After the upgrade to Next.js 16, next build stops because next.config has a webpack function. Why Next.js fails on purpose, the three ways out, and what to do when a plugin added the webpack config.
The error
The build stops with ERROR: This build is using Turbopack, with a webpack config and no turbopack config. The Next.js 16 upgrade guide explains why: next build now uses Turbopack by default, and if your project has a custom webpack configuration, the build will fail to prevent misconfiguration issues.
Nothing is wrong with your code. Before Next.js 16 you had to opt in to Turbopack with --turbopack, so the same next.config built with webpack before the upgrade. On Vercel the deployment fails at the build step.
// next.config.ts
const nextConfig = {
webpack: (config) => {
config.resolve.fallback = { fs: false };
return config;
},
};
export default nextConfig;Why Next.js stops instead of ignoring it
Turbopack does not run webpack plugins. It supports webpack loaders, but anything your webpack function adds, such as a plugin, an alias or a fallback, would silently stop applying under Turbopack. Next.js refuses to guess and stops the build so you choose.
Fix 1: keep building with webpack
Add the --webpack flag to the build script. The dev server can keep using Turbopack. This is the safest choice when the webpack function does real work, for example a plugin you depend on.
{
"scripts": {
"dev": "next dev",
"build": "next build --webpack",
"start": "next start"
}
}Fix 2: build with Turbopack and ignore the webpack config
Run next build --turbopack. The upgrade guide describes this as building with Turbopack and ignoring your webpack config. Many apps work under Turbopack with no configuration, but test the app, because whatever the webpack function changed no longer applies.
Fix 3: move the config to Turbopack
The third way the upgrade guide gives is to migrate the webpack config to Turbopack-compatible options under turbopack in next.config. A resolve.fallback that silenced Module not found: Can't resolve fs, for example, becomes a turbopack.resolveAlias that loads an empty module in the browser. The Next.js docs recommend fixing the imports first, so client code no longer pulls in Node.js modules.
// next.config.ts
const nextConfig = {
turbopack: {
resolveAlias: {
fs: { browser: "./empty.ts" },
},
},
};
export default nextConfig;When you never wrote a webpack config
The upgrade guide notes that if the build fails because a webpack configuration was found and you do not define one yourself, a plugin is likely adding a webpack option, such as a wrapper around next.config. Check the plugin for a Next.js 16 or Turbopack release, or use one of the flags above until it has one.
How DeployDoctor catches it
DeployDoctor reads next.config, package.json and vercel.json in the Build configuration check. When the app uses Next.js 16 or later, next.config sets a webpack function and has no turbopack option, and the build command, or the build script it runs, is next build without --webpack, --turbopack or a TURBOPACK or NEXT_RSPACK setting, it reports a failing check that points at the webpack line. Next.js looks for the turbopack option after plugins have run, and plugins such as @next/mdx and next-intl add one when the config loads, so when next.config passes its config through a plugin like withMDX or withNextIntl, a function or a spread, the check is a warning instead. A webpack option that a wrapper plugin adds is not visible in next.config, so that case is not reported. Scan your repository for free on the home page, or run it on every pull request with the GitHub Action.
Updated 2026-10-17