Deploy
Next.js static sites
Export your Next.js app to static HTML and assets, upload the out directory, and publish it globally without running a Node.js server.
Static export support matrix
Before uploading out, make sure the app fits the static export model.
Works well
- Static routes generated at build time
- App Router pages that can be rendered statically
- Pages Router getStaticProps / getStaticPaths
- Client-side data fetching after hydration
- next/link, dynamic imports, CSS Modules, and static assets
Needs another runtime
- API routes and route handlers that need server execution
- Middleware, rewrites, redirects, and custom headers
- getServerSideProps and request-time rendering
- Incremental Static Regeneration
- Default next/image optimization without a custom static strategy
Use Next.js when you want the framework, not the server
Keep the framework, drop the server
Next.js static export lets you keep file-based routing, layouts, metadata, build-time rendering, CSS support, and client-side React where you need it.
The output is still just files. That makes it a good fit for marketing sites, docs, portfolios, product pages, content hubs, and other pages that can be prepared at build time.
Fast like a static asset
Pre-rendered HTML can be cached aggressively and served directly from edge nodes without waiting on a render server.
Less ops overhead
No Node runtime means fewer moving parts, simpler deployment artifacts, and less production drift between builds.
Clear runtime boundary
If the page needs server code, it should not be forced into static export. If it can be built ahead of time, the out directory is a clean artifact to publish.
Common static export blockers
Build fails because of server-only features
Remove request-time APIs from the exported route, move them behind a separate backend, or deploy that part on a server-capable platform.
Images work in dev but fail after export
The default next/image optimizer expects a server. Use images.unoptimized, a custom loader, or regular static image assets.
Dynamic routes are missing
Generate the route list at build time with generateStaticParams in the App Router or getStaticPaths in the Pages Router.
Redirects or rewrites do not apply
Next.js redirects and rewrites are not part of static export. Use static page structure, client-side navigation, or platform-level redirects where available.
Next.js static export checklist
Set output: 'export'
Tell Next.js to emit static HTML during build time instead of expecting next start or a hosted Node runtime.
output: 'export'Build and verify /out
Run the production build and confirm the out directory contains the rendered pages, assets, 404 page, and static files you plan to publish.
npm run buildUpload and test routes
Upload the out directory, then validate nested paths, static assets, and unoptimized images in the deployed site.
Next.js deployment FAQ
Why does the Next.js Image component fail after export?
The default Image optimization pipeline expects a server. For static export, set images.unoptimized to true in next.config.js.
Do API routes or getServerSideProps work here?
No. Static export removes server-side runtime features such as API routes, middleware, and getServerSideProps. Move that logic to a separate backend or serverless service.
Can I use the App Router?
Yes, as long as the route can be rendered statically and does not depend on dynamic server-only APIs such as headers or cookies.
How should I handle dynamic content?
Fetch it at build time when possible, or load it client-side after the page hydrates. Static export works best when the HTML can be prepared ahead of time.
Should I upload .next or out?
Upload out for output: 'export'. The .next directory is an internal build directory for Next.js and is not the static export artifact you want to publish.
Is this a replacement for Vercel Next.js hosting?
It is a fit for static exports, not every Next.js app. If you rely on SSR, middleware, ISR, server actions, or API routes, you need a runtime that supports those features.