The fix that worked for mine Next.js 16.3.5 deployment: Rename next.config.ts to next.config.mjs. Remove the TypeScript type import and replace const nextConfig: NextConfig = with const nextConfig =. Preserve all existing settings and export default nextConfig. Change the build script in package.json: Commit and push both changes, then redeploy. Keep Hostinger's build command as npm run build, output directory as .next, and Node.js selection as 22.x.
The .mjs configuration avoids TypeScript transformation during configuration loading. Webpack allows the build to proceed with the available SWC WASM fallback. No webpack: true setting, Next.js downgrade, or manual glibc upgrade was needed.
While deploying the website to Hostinger, I ran into a build failure that initially looked like a broken Next.js configuration file.
The project built locally. On Hostinger, the log mentioned a missing temporary configuration module, along with an error about GLIBC2.29. Changing the configuration format got the build further, but it took a second change to get past the actual compiler limitation.
The working combination was: Use next.config.mjs instead of next.config.ts. Run the production build with next build --webpack.
The website uses Next.js App Router, TypeScript, React, and CSS Modules. The relevant versions and deployment settings were:
| Setting | Value | | --- | --- | | Next.js | 16.3.5 | | React | 19.2.8 | | Local operating system | Windows | | Local Node.js | 22.20.0 | | Local npm | 11.6.1 | | Hostinger Node.js selection | 22.x | | Hostinger build command | npm run build | | Root directory | ./ | | Output directory | .next |
The exact Node.js patch version and npm version used by the remote builder were not established. The versions above distinguish what was checked locally from what was selected in Hostinger's deployment panel.
The original build attempted to load next.config.ts and failed. These were the useful parts of the log, with account-specific paths omitted:
A later message referred to a missing generated configuration module. Hostinger's automated analysis suggested deleting a corrupted temporary configuration file.
That explanation did not account for the earlier native-library errors. A generated filename alone was not evidence that the configuration had become corrupted, and clearing the Next.js cache would not provide the missing system-library interface.
SWC is the compiler used by Next.js to transform application code. Its native binaries depend on the operating system they run on.
glibc is the GNU C Library, a foundational library used by many Linux programs. The reported failure involved its math library, libm.so.6. The SWC binary needed the versioned interface named GLIBC2.29, which the loaded library did not provide.
This confirmed the library version in the SSH session. It did not prove that the deployment builder and SSH session were identical environments, but the build log independently confirmed the missing interface in the builder.
Neither changing the project's npm dependencies nor selecting a newer Node.js version necessarily upgrades the Linux libraries underneath them. Manually replacing glibc in a managed hosting account was not an appropriate fix.
These are excerpts illustrating the conversion. I preserved the real configuration body, including its security headers and conditional Docker output setting.
The .mjs extension identifies a JavaScript module that Node.js can load without transforming TypeScript syntax. The JSDoc comment retains editor type information. Next.js supports this configuration format. Next.js configuration documentation.
Only the configuration file changed language. The application remained TypeScript.