How to Host NextJS Website on Hostinger, Deploy Next.JS App easily 2026

Everything downstream depends on this. A Next.js project builds one of two ways: as an application that needs a Node runtime, or as a static export.

For the static export, set `output: 'export'` in next.config.js. Next.js then writes an `out` folder of plain HTML, CSS, and JS during `next build`, and any web server can serve it.

The trade is a documented list of features that stop working: server actions, cookies, incremental static regeneration, redirects and rewrites from next.config, route handlers that read the request, and `next/image` with the default loader. If your project uses any of those, the static route is closed and you need the Node route in step 4.

Hostinger's plans page offers Web hosting, Cloud, and VPS. A static export is happy on any of them, including the cheapest shared tier, because it is only files.

A Node app is different. Hostinger documents Node.js support on Business web hosting and on the Cloud plans, and separately on VPS and dedicated servers, where you configure it yourself over the command line.

The entry-level shared tiers are not on that list. Buying the cheapest plan and hoping to add Node later is the mistake this step exists to prevent.

Log in at Hostinger's account page with Google, Facebook, or your email and password. That takes you to hPanel, which holds websites, file manager, domains, and the deployment tools. Everything after this point happens there.

In hPanel, open Websites in the sidebar, click Add Website, then choose Deploy Web App. Hostinger accepts a GitHub repository, which rebuilds on every push, a .zip upload, or a deployment pushed from a local IDE through its connector.

The setup screen asks for the framework, usually detected on its own, the build settings, and the output directory, which for Next.js is `.next`. You also pick a Node version from 18.x, 20.x, 22.x, or 24.x.

Two limits are documented and both bite later: a Node.js site has to be created as a new website, so a domain already attached to an existing site must be freed up first, and there is no stop or delete control for the deployment itself. Taking it offline means removing the whole website, which is permanent.

For a static export, open File manager in hPanel and go to public_html, the directory Hostinger serves the live site from. Click Upload and choose File or Folder.

Upload the contents of the `out` folder that `next build` generated. Older versions of this guide pointed at an "assets" directory, which is wrong: `out` is the export target unless you overrode it with `distDir`.

Uploading the folder in one go is quicker than picking files individually, and both end up in the same place. One thing to settle before you build: NEXT_PUBLIC_ environment variables are inlined at build time on your machine, so a wrong API URL means rebuilding locally and re-uploading. hPanel cannot inject them into files that are already static.

Visit the domain and click through the real pages, not just the homepage. Missing styles and broken images almost always trace back to `basePath` or `assetPrefix` in next.config rather than to anything on the server, so the fix is to correct the config, rebuild, and upload again.

Static exports have one more trap. Next.js writes `/blog/post-1.html`, and a request for `/blog/post-1` only resolves if the server tries the `.html` file too.

Next.js's own deployment notes show that rewrite for Nginx. Setting `trailingSlash: true` before you build sidesteps it entirely by emitting `/blog/post-1/index.html`, which every static host resolves without configuration.