How to Deploy a Next.js Site for Free (Static Export)

2026-06-18 · The Snapy team

How to Deploy a Next.js Site for Free (Static Export)

Next.js is built for full web apps, but a lot of Next.js sites are really just content: a landing page, docs, a blog, a portfolio. If that is you, you can export the site to static files and host it for free in seconds, with no Git, no CLI, and no remote build. This guide walks through the whole process, including the config, the router differences, and the errors that catch people out.

First, decide if static export fits your site

Next.js can run in two ways. One needs a live Node server, which powers server-side rendering, API routes, server actions, and incremental static regeneration. The other, static export, turns your site into plain HTML, CSS, and JavaScript with no server in the loop.

Static export fits any site that is fully knowable at build time: marketing pages, docs, blogs, portfolios, and most landing pages. It does not fit a site that has to do work on the server for each request. A quick test: if nothing on the page changes based on the incoming request (no per-user server rendering, no server API routes), static export will work.

If your site does need a server at request time, keep that part on a Node host like Vercel. Everything below assumes the static export path.

Step 1: turn on static export

Static export is off by default. Open next.config.js and add the output option:

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'export',
  images: {
    unoptimized: true,
  },
};

module.exports = nextConfig;

The images: { unoptimized: true } line matters. The Next.js <Image> component normally relies on a server-side optimizer, and a static export has no server. With unoptimized: true, <Image> still handles layout and lazy loading, but it serves your images as-is. Pre-size heavy images before building if file weight is a concern.

Step 2: handle dynamic routes and the router you use

Static export works with both the App Router and the Pages Router, but dynamic routes need a list of every path to generate at build time.

export function generateStaticParams() {
  return [{ slug: 'hello-world' }, { slug: 'second-post' }];
}

The principle is the same in both routers: everything must be resolvable at build time, because no server answers requests after upload.

Step 3: build

npx next build

Next.js produces an out folder containing your whole static site, with index.html at its root.

Zip the contents of the out folder (so index.html is at the root of the zip, not inside a nested folder). Then open the tool for free Next.js static hosting, drop the zip in, and click Get my link. Your site is live on a clean link right away, like docs.snapy.page. There is no account to create, no repo to connect, and no remote build to wait on. Files are up to 100MB each, links persist, and you can add a password, an expiry date, or analytics if you want them.

Troubleshooting common export errors

A static export writes a real HTML file for each page (for example out/about/index.html), so normal navigation and refresh both work. If you build custom client-side routing on top of Next.js, the same caution applies as with any static host: deep links only resolve if a matching HTML file exists. Sticking to Next.js pages and generateStaticParams avoids that entirely.

What works and what does not

Static export covers marketing pages, docs, blogs, and portfolios, plus statically generated dynamic routes and any client-side React you add. What does not run on static hosting: SSR, API routes, route handlers, server actions, ISR, and middleware. Keep those on a server host and put the static pieces on Snapy.

Try free Next.js static hosting now, or for raw HTML files see free HTML hosting. If you use plain React, read how to host a React app free.

Try snapy

Drop a file, get a shareable link in seconds.

Upload a file
Go Pro · $50/year, save ~$10 vs monthly · launch price for the first 100 members.