Export static Next.js before hosting: routes and limits

A Next.js application working on localhost does not determine what hosting it needs. You need to check the build output and which functions it expects to run when a request arrives. A static export delivers files; an application that needs server logic requires a service capable of running it.

This diagnostic uses an original example with a completed local trial and approved independent review. It helps you inspect the artefact before choosing hosting. It does not demonstrate native Next.js delivery on Hostbrid, SSR support, all framework features, authentication or databases.

If you built the app with v0 and want to run it outside Vercel, follow the guide to hosting a v0 app, which separates static Next.js output from features that need Node.

Distinguish exporting files from running an application

The official static export documentation describes output: 'export': the build produces the files that a static server publishes. This is not equivalent to output: 'standalone', which prepares an application to run with Node.

The presence of Server Components alone does not demonstrate that you need a server for each request. In a compatible export, they can run during the build and produce HTML. What matters is whether the application requires information or work that cannot be resolved during that build.

Make an inventory before changing the configuration: routes whose set is unknown at build time, user cookies, server actions, handlers that read the request, incremental regeneration and image optimization using the default loader. The official documentation identifies specific restrictions for these features. Disabling them to obtain a passing build can remove necessary behaviour; a passing build does not demonstrate that your application preserves what it did.

An exported route has its own document

A typical SPA may have a single HTML file that the router interprets in the browser. A Next.js export generates documents for each route. If every request is indiscriminately rewritten to the homepage, /about can return a 200 and display the wrong page.

A real question about publishing on cPanel describes this symptom when reloading a route. The question shows the friction; its answers do not replace current documentation or a test of your configuration.

Check how the routes are laid out in the exported folder. trailingSlash changes the file layout: do not copy rules from another website without looking at the output. Test direct navigation, navigation from another page and reloading. In each case, verify the content and page identity as well as the HTTP status. A nonexistent route should remain a verifiable error, not a homepage disguised as success.

Decide which routes exist during the build

Exported dynamic routes need parameters that allow their documents to be generated during the build. If your application discovers new identifiers only when a request arrives, adding an invented list to silence the error is not enough: you must decide whether you can regenerate and publish the set or need another architecture.

The example generates /notes/orbita/ and checks that an unknown slug returns a real 404. Removing generateStaticParams() from the dynamic route made the build exit with code 1 and the specific Next.js error indicating incompatibility with output: export. Installation had passed; a network or dependency failure would not have counted as that control.

Local experiment results

The trial pins Next.js 16.4.0, React 19.3.0, Node 22.23.3 and npm 10.9.9. It generated three different documents: the homepage, /about/ and /notes/orbita/. Their bytes were checked over HTTP, along with six Chrome cases at 390 and 1280 pixels, DPR 2, with direct navigation and a reload fetching a new document. CSS, SVG and JavaScript loaded; a counter went from 0 to 1 on clicking and returned to 0 on reloading. That counter only has in-memory state: it does not demonstrate persistence.

The negative control returned the exact homepage bytes with HTTP 200 when requesting /about/. The same verifier that accepted the correct page rejected that incorrect identity. This checks a failure that a review based only on the HTTP status would have missed.

The first run failed because the trial’s local server did not decode a chunk URL containing brackets. The server was corrected and a new run completed. That trial failure is preserved as evidence; it does not demonstrate a defect in the hosting product.

The local tests identify the exportable artefact and its restrictions. They do not evaluate publication of the project on Hostbrid or validate an application that needs a server. Before moving your application, check the features it uses and the identity of its routes on your chosen hosting separately.

If your app needs a Next.js server instead of static files, read the guide to hosting Next.js on a VPS. To check another Node or Docker process, use the port and health guide and verify the product’s actual capabilities before purchasing hosting. If your frontend uses an external backend, inventory that service separately: exporting the frontend does not migrate its data or credentials.

Reproduce the verified revision

The original MIT-licensed example contains the application and the trial. These commands pin the reviewed revision. You need Node 22.23.3 with npm 10.9.9 and Chrome on macOS; consult the README and use a new directory to preserve the evidence.

git clone https://github.com/ocentelles/hostbrid-example-next-static-export.git
cd hostbrid-example-next-static-export
git checkout 5033d51146fa992b1deb8c6080696ed3cc8da91d
node --version
node scripts/run-essay.mjs /tmp/my-next-export-evidence