Why my Next.js 16 build failed on shared hosting, and the one-flag fix

I upgraded this site to Next.js 16 and pushed it to my host. The deploy failed after about 21 seconds with this line in the build log:

Error: Turbopack is not supported on this platform (linux/x64) because native
bindings are not available. Only WebAssembly (WASM) bindings were loaded, and
Turbopack requires native bindings.

The site built fine on my own machine, so it took a moment to see what was actually wrong. The fix turned out to be one flag, but the reason is worth understanding.

What was happening

Next.js compiles your code with a compiler written in Rust. It ships that compiler as a native binary for each operating system. A few lines above the error, the build log had this warning:

Attempted to load @next/swc-linux-x64-gnu, but an error occurred:
/lib64/libm.so.6: version `GLIBC_2.29' not found

That means the server's C library (glibc) is older than the version the native compiler needs. Shared hosting often runs an older Linux than you would pick yourself. When the native binary cannot load, Next falls back to a WebAssembly build of the same compiler. That works, but it is slower and has limits.

One of those limits is the problem. Next.js 16 uses Turbopack as its default bundler for next build, and Turbopack needs the native binary. So on a server that can only load the WebAssembly fallback, the default build stops with the error above.

The fix

The error message itself names it: build with Webpack instead. In package.json:

"scripts": {
  "build": "next build --webpack"
}

With that one change, the same server built the site and deployed it. The build step took about a minute and a half, and the whole deploy, including installing dependencies and restarting the app, about two minutes. The glibc warnings still appear in the log, many times over because each build worker tries the native binary first. They are noise once you know why they are there.

How I tested it before pushing

I did not want to find out by deploying again, so I reproduced the failure locally. Next has two environment variables that force the WebAssembly compiler: NEXT_TEST_WASM=1 and NEXT_TEST_WASM_DIR, which points at the unpacked @next/swc-wasm-nodejs package. You can download that package with npm pack @next/swc-wasm-nodejs@16.4.3 (use your own Next version). These are internal test switches, not documented features, so they may change in a later release. They worked on 16.4.3.

With them set:

• the old build script reproduced the exact error from my host;
• next build --webpack built all the pages.

That is a much shorter feedback loop than pushing, waiting, and reading logs.

Should you stay on Turbopack instead?

Turbopack builds are generally faster, and if your host can load the native compiler, there is no reason to leave it. The options when it cannot:

• Build with Webpack, as above. For a small site the difference is seconds, and Webpack is the older, well-tested path.
• Build somewhere else (for example in CI) and deploy the output, if your host supports that.
• Move to a host with a newer system library.

For a portfolio, the flag is the proportionate answer.

A checklist for the next failed deploy

1. Read the whole build log, not just the last line. The cause was a warning several lines earlier.
2. Run the production build locally (npm run build), not only the dev server. They use different code paths.
3. When the error is about the platform, look at what the host actually runs, then reproduce that condition locally if you can.

If you are planning a Next.js project and want someone who has debugged this kind of deployment problem, see my web development services or get in touch.