Deploying Next.js on Hostinger Node.js hosting

This is a field note, not a tutorial. We run several Next.js applications on Hostinger's Node.js hosting, and each time something worked locally and failed on the host, we wrote down why. Your plan, Node version and the host's image may differ from ours, so treat these as things to check, not guarantees.

How the deployment actually works

On this kind of hosting there is no CI pipeline and no git checkout. You upload a zip of the source; the host extracts it, runs npm install and your build command with its own toolchain, and starts a long-running Node process. That last detail matters: the build does not happen on your machine, so a failure can appear only on the server.

1. The compiler that cannot load

Some hosts ship an older C library than Next.js's native compiler expects. Next then falls back to its WebAssembly compiler, and two things break:

• Turbopack has no WebAssembly fallback, so a bare next build can fail. Use webpack explicitly: next build --webpack.
• A TypeScript config file cannot be compiled by the fallback, so keep the configuration as plain JavaScript: next.config.mjs, not next.config.ts.

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

2. "Cannot find module '@tailwindcss/postcss'"

If the host's environment sets NODE_ENV=production while installing, npm skips development dependencies, but the build needs several of them (the Tailwind PostCSS plugin, TypeScript, the type packages). The simplest fix is not to set NODE_ENV in the control panel. A more robust fix is to make the project install them regardless:

# .npmrc
include=dev

As a second safety net, a prebuild script can check that every development dependency is present and run npm install --include=dev if any is missing.

3. The zip that extracts with permission errors

Our first zips were made with PowerShell's Compress-Archive. The upload then failed with EACCES: permission denied, on the folders whose names contain parentheses, such as Next.js route groups like (site). A zip made with Windows Explorer's own Compress to ZIP did not have the problem. Whatever tool you use, test the whole upload once before you need it in a hurry.

4. Files the server reads at runtime

Next.js decides which files to copy into the running app by tracing imports. A package that loads files dynamically (fonts for a PDF library, for example) can be missing in production even though npm install fetched it. The symptom is "Cannot find module" or a missing file only on the host. Two fixes worked for us: list the files in outputFileTracingIncludes, and keep static assets that server code reads from disk under public/, which is reliably deployed.

5. The old process that keeps running

Overwriting files is not the same as restarting the app. After a deploy we saw intermittent 500 errors that turned out to be the previous Node process still serving a half-replaced build. Restart the application explicitly after every deployment, then check a health endpoint that also touches the database.

6. Database connection limits

Shared database users have limits you will not see on a local database: idle connections dropped after a short time, and a cap on how many new connections may be opened per hour. A pool that closes idle connections and reopens them on every visit can exhaust that cap on a quiet site. Keep the pool small, keep its connections open, and ping them every few seconds.

7. Keep uploads outside the application folder

A redeploy replaces the whole application folder. Anything users upload must live somewhere else on the server, referenced by an environment variable, or the next deployment will delete it.

A short checklist

1. Build with next build --webpack; configuration in next.config.mjs.
2. .npmrc with include=dev.
3. Test-extract the zip you will actually upload.
4. Environment variables set in the control panel, never in the zip.
5. Explicit restart, then /api/health.
6. Uploads and backups outside the app folder.
7. A written rollback: the previous zip, and migrations that only ever add.