Next.js runs on Netlify through an open-source adapter, OpenNext, that Netlify maintains and tests against every Next.js release, and the current adapter marks App Router, server components, Server Actions, Incremental Static Regeneration, middleware and image optimization as fully supported. The one documented limitation is middleware execution order: headers and redirects evaluate after middleware on Netlify, which differs from Next.js running standalone. For nearly all apps that is a non-issue; for a handful of edge-case routing setups, it is worth testing before you rely on it.
Older posts and forum threads about Next.js on Netlify describe a platform that could not do ISR or middleware properly, and that description is out of date. The adapter has matured, and Netlify’s own compatibility table now marks most features as fully supported. The useful question today is not can Netlify run Next.js but where does the adapter’s one real limit actually bite, and when is a Node-runtime host still the simpler choice.
Table of contents
- How the adapter actually works
- What has full support today
- The one limitation worth knowing
- Static export vs the runtime adapter
- Configuration that actually matters
- When a Node-runtime host is the simpler fit
- How this fits the rest of the stack
- FAQ
How the adapter actually works
Netlify does not run Next.js as a persistent Node server the way a container or VM would. The OpenNext adapter compiles your Next.js build into Netlify’s own primitives: static pages become CDN assets, server-rendered routes and Server Actions become serverless or edge functions, and middleware runs as an Edge Function ahead of the request.
This is transparent day to day: you deploy a normal Next.js project, Netlify detects the framework, and the adapter’s transformation happens during the build with no config beyond having a next.config.js that does not fight it.
The practical consequence worth internalizing is that a server-rendered route is now a function invocation, not a warm process. The first request after a period of inactivity pays a cold start, typically well under a second for a lean route but noticeable for one with heavy dependencies. This is the same trade-off every serverless-function-based host makes, not something specific to Netlify’s implementation.
What has full support today
- App Router and Server Components run as documented, including the mixed server/client component model.
- Incremental Static Regeneration works, with pages regenerated on the schedule or on-demand trigger you set, stored in Next.js’s own route cache.
- Server Actions and streaming responses are supported, so form mutations and progressively rendered UI both work.
- Image Optimization runs through Netlify’s own image pipeline rather than requiring a separate service.
That list covers what most Next.js apps actually use. The gap between Netlify supports Next.js and Netlify supports every Next.js feature identically to running it yourself has narrowed to nearly nothing for standard app patterns.
The one limitation worth knowing
Netlify’s own docs name it directly: middleware execution order differs from standalone Next.js, because headers and redirects are evaluated after middleware runs, not interleaved with it the way Next.js’s own runtime handles it. If your middleware sets a header that a redirect rule then depends on, or vice versa, the order Netlify applies can produce a different result than local development shows.
This surfaces rarely, mostly in apps doing unusual things with middleware-based rewrites combined with netlify.toml redirect rules on the same path. Test the specific interaction if your app does both; for middleware used for auth checks or simple header injection, which is most uses, it does not apply.
Static export vs the runtime adapter
Next.js also supports output: export, which produces pure static HTML with no server runtime at all, no API routes, no Server Actions, no ISR. That mode works on any static host, Netlify included, and sidesteps the adapter entirely because there is no server behavior to adapt.
The choice is not static export is worse, it is a different application shape. A marketing site or documentation set with no personalization is a fine static export. An app with authenticated routes, forms that mutate data, or content that regenerates on a schedule needs the runtime adapter, because none of that exists in a static export build.
Configuration that actually matters
Beyond the framework auto-detection, two settings are worth checking explicitly rather than trusting the default.
[build]
command = "next build"
[[plugins]]
package = "@netlify/plugin-nextjs"The plugin is installed automatically for detected Next.js projects on newer Netlify accounts, but pinning it explicitly in netlify.toml avoids surprises if the auto-detection ever misses a monorepo or unusual directory layout. Environment variables prefixed NEXT_PUBLIC_ still follow Next.js’s own client-bundling rule regardless of host.
For a monorepo, set the base directory to the app’s own folder rather than the repository root, so the build command and the plugin both resolve relative to the actual Next.js project instead of a workspace root that has no package.json of its own. This is the most common source of a build that works locally and fails only on Netlify.
When a Node-runtime host is the simpler fit
The adapter model is a genuine translation layer, and translation layers have edges. An app that needs a long-running WebSocket connection, a background job that outlives a single request, or a very large in-memory cache warmed once and reused across requests is fighting the serverless-function shape that the adapter maps onto, regardless of host.
For that shape, a host that runs Next.js as an actual Node process is the more direct fit, with no adapter translation between the framework’s assumptions and the runtime. Next.js on RunxBuild runs the build as a service directly: a build log, a live route, environment variables and rollback, with the process staying warm rather than resolving through function cold starts.
How this fits the rest of the stack
Whichever runtime model fits, the sizing question is the same one: how much the service needs at idle and under load, and whether a database sits beside it. Put those together in the RunxBuild hosting calculator before committing to a plan. Next.js on RunxBuild describes the build-from-repository path when a Node process, not a function-mapped adapter, is what the app actually wants, and the dashboard is where the repository connects either way.
Useful related references:
- Django on Netlify: Why It Does Not Work, and What To Do Instead
- Branch Deploy on Netlify: How It Works and When to Use One
- Netlify Templates: What Starter Templates Give You and What They Do Not
- Next.js services on RunxBuild
FAQ
Does Netlify support Next.js ISR?
Yes, fully. Incremental Static Regeneration works through the OpenNext adapter, with pages stored in Next.js’s own route cache and regenerated on the schedule or on-demand trigger the app defines, matching the behavior documented for standalone Next.js.
Can I use Next.js middleware on Netlify?
Yes, middleware runs as an Edge Function. The one documented limitation is execution order relative to headers and redirects, which evaluate after middleware rather than interleaved with it. This affects a narrow set of apps combining middleware rewrites with netlify.toml redirects on the same path.
Is Vercel required to deploy Next.js?
No. Vercel created Next.js and its adapter is tightly integrated, but Netlify’s OpenNext adapter supports the same core features, App Router, ISR, Server Actions, image optimization, and any Node-capable host can run a Next.js build directly without an adapter at all.
Should I use static export or the Netlify runtime adapter for Next.js?
Static export fits a site with no server behavior: no API routes, Server Actions, or ISR. Anything with authenticated routes, form mutations, or scheduled regeneration needs the runtime adapter, because static export has no server to run that logic.
When should I not use Netlify for a Next.js app?
When the app needs a long-running process the serverless-function model does not fit well: a persistent WebSocket connection, a background job spanning multiple requests, or a large warm in-memory cache. A host running Next.js as a continuous Node process avoids the adapter’s translation layer entirely.