HomeTechnical answer

Technical answer

Next.js Self-Hosting Compatibility Matrix

A sourced Next.js 16.2 matrix for Node servers, standalone output, and static export covering images, Proxy, ISR, streaming, multi-instance state, and shutdown.

Check deployment readiness Read the resource

By HostNextJS Editorial TeamReviewed by HostNextJS Technical Review Published July 13, 2026Updated July 13, 2026

01Typearticle

02Last reviewedJuly 13, 2026

03Update policyReview within 14 days of a material Next.js self-hosting documentation change and at least every 90 days.

Direct answer

What to know

01A Node.js server and standalone output support the same core runtime features, but standalone packaging has traced-file and static-asset requirements.
02Static export excludes request-time features including Proxy, ISR, Server Actions, dynamic request handlers, and default image optimization.
03Multi-instance operation adds shared cache, invalidation, encryption-key, deployment-ID, and version-skew responsibilities.

Open evidence

Use the source material

Version 2026.1 is an independent synthesis of official Next.js 16.2.10 documentation. It is not a provider certification matrix. Preserve the version, framework version, checked date, and source URLs when reusing it.

Compatibility matrixVersioned metadata and ten feature records for programmatic use.

JSON02

Compatibility tableFlat feature statuses and operator requirements for review or adaptation.

CSV

Self-hosted does not mean unsupported. It means the framework and the operator divide responsibility differently. The matrix distinguishes features that run directly from conditions that require proxy, storage, key, packaging, or rollout work.

Matrix summary

Feature	Node server	Standalone	Static export	Main operator condition
Dynamic rendering	Supported	Supported	Not supported	Run a Node.js server
Standalone packaging	N/A	Conditional	N/A	Copy static assets and verify traces
Runtime image optimization	Conditional	Conditional	Not supported by default	Provide runtime resources or a custom loader
Proxy	Supported	Supported	Not supported	Preserve request behavior
ISR and revalidation	Conditional	Conditional	Not supported	Persist or share cache state
Streaming and Suspense	Conditional	Conditional	N/A	Disable buffering end to end
Multi-instance Server Functions	Conditional	Conditional	Not supported	Share the encryption key
Rolling version skew	Conditional	Conditional	N/A	Set a deployment ID and retain compatible assets
Multi-instance invalidation	Conditional	Conditional	Not supported	Coordinate shared cache tags
Graceful shutdown and `after()`	Conditional	Conditional	N/A	Send termination signals and drain 10-30 seconds

Node server and standalone are runtime peers

Standalone output reduces the deployed file set by tracing runtime dependencies and emitting a minimal server.js. It does not turn the application into a static site. Dynamic rendering, Route Handlers, Proxy, ISR, images, Server Functions, and after() still depend on the Node.js runtime and surrounding infrastructure.

The packaging boundary matters. Next.js does not copy public or .next/static into the standalone directory by default. Monorepos and native libraries can also require an adjusted tracing root or narrow include patterns.

Static export is a different product shape

Static export produces HTML, CSS, JavaScript, and build-time route output for a static web server. It cannot provide request-time cookies, rewrites, redirects, headers, Proxy, ISR, Server Actions, default image optimization, or dynamic handlers that inspect the request.

Use static export when those constraints match the application. Do not choose it only to avoid operating a Node.js server and then rebuild missing server behavior in an untracked collection of edge scripts.

Multi-instance is the meaningful boundary

A single persistent Node.js instance can use the default filesystem cache. Multiple instances need consistent Server Functions encryption, deployment IDs, shared cache storage, tag invalidation, compatible assets, and rollout behavior. These are architecture requirements, not provider checkboxes.

Validate the exact production artifact through every proxy and load balancer. A framework-level supported status cannot detect response buffering, missing traced files, stale cache state, insufficient image memory, or a shutdown path that kills in-flight work.

Methodology

How this resource was produced

We mapped ten production-relevant features from official Next.js 16.2.10 documentation across a normal Node.js server, standalone output, and static export. Supported-with-condition means the framework supports the feature but the operator must provide a documented runtime, proxy, storage, key, or rollout behavior.

Limitations

01
Framework support does not prove a provider, proxy, CDN, container, or application integration behaves correctly.
02
The matrix covers Next.js 16.2.10 documentation and can become stale after a framework release.
03
Supported-with-condition is not a severity score; each condition must be tested against the intended architecture.

Evidence

Sources and review record

Primary documentation checked for the material claims on this page. Product behavior and prices can change after the checked date.

FAQ

Questions about next.js self-hosting compatibility matrix.

No fog. Just the practical details developers need before moving a production app.

Does standalone output support all Next.js server features?

It uses a minimal traced Node.js server and supports the core server model, but public and static assets need copying or separate delivery, and tracing can require adjustment for monorepos or native assets.

Can static export use ISR?

No. Official static-export documentation lists Incremental Static Regeneration as unsupported because it requires server behavior after build time.

Next step

Turn the resource into a deployment decision.

Check deployment readiness