Minimum requirements to run Next.js
To run Next.js, your platform needs a Node.js server. A single `next start` process handles every Next.js feature correctly: Server Components, ISR, PPR, Cache Components, Server Actions, Proxy, and `after()`. Streaming support is needed for features like PPR and Server Components to deliver content progressively. Additional infrastructure (CDN caching, edge compute, shared cache) primarily improves performance and multi-instance consistency. The only additional dependency is the `sharp` package, which is required for Image Optimization.
Functional fidelity vs Performance fidelity in deployment
Functional fidelity means every Next.js feature works correctly. The adapter test suite is the contract: if a platform's adapter passes the tests, it supports Next.js. Performance fidelity means features achieve their optimal performance characteristics. Examples include PPR's static shell served at CDN latency rather than origin latency, or ISR serving stale content instantly with sub-second revalidation propagation. A platform that achieves functional fidelity is a fully supported deployment target for Next.js.
Feature Support Matrix for deployment
Server Components: Streaming Required, Shared Cache No, Edge Stitching No. ISR (time-based): Streaming No, Shared Cache Recommended, Edge Stitching No. ISR (on-demand): Streaming No, Shared Cache Recommended, Edge Stitching No. Partial Prerendering: Streaming Required, Shared Cache Recommended, Edge Stitching Optional. Cache Components (`use cache`): Streaming Required, Shared Cache Recommended, Edge Stitching No. Proxy/Middleware: Streaming No, Shared Cache No, Edge Stitching No. Server Actions: Streaming Required, Shared Cache No, Edge Stitching No. `after()`: Streaming No, Shared Cache No, Edge Stitching No.
Streaming Required definition in deployment
Streaming Required means the platform must support chunked transfer encoding or HTTP/2 streaming and must not buffer the response before sending it to the client.
Shared Cache Recommended for multi-instance deployments
Shared Cache Recommended means multiple server instances benefit from shared cache backends to coordinate. For ISR and server response caching, use `cacheHandler`. For `'use cache'` entries, use `cacheHandlers`. Without shared cache, each instance maintains its own cache independently — features still work correctly on each instance, but revalidation events don't propagate across instances.
CDN Infrastructure Compatibility mapping
Cloudflare: Edge Compute=Workers, Key-Value/Tags=KV, Blob Storage=R2, PPR Resuming=Yes (worker). Akamai: Edge Compute=EdgeWorkers, Key-Value/Tags=EdgeKV, Blob Storage=Object Storage, PPR Resuming=Yes (worker). Amazon CloudFront: Edge Compute=Lambda@Edge, Key-Value/Tags=KeyValueStore, Blob Storage=S3, PPR Resuming=Yes (Lambda). Fastly: Edge Compute=Compute, Key-Value/Tags=KV Store, Blob Storage=Object Storage, PPR Resuming=Yes (WASM). Azure: Edge Compute=Functions, Key-Value/Tags=Managed Redis, Blob Storage=Blob Storage, PPR Resuming=Yes (server). Google Cloud: Edge Compute=Cloud Run, Key-Value/Tags=Various KV, Blob Storage=Cloud Storage, PPR Resuming=Yes (server).
Adapters overview and API
Next.js provides a Deployment Adapter API that lets platforms customize how Next.js applications are built and deployed for their infrastructure. Adapters run at build time and produce platform-specific output from the standard Next.js build. Anyone can build an adapter using the public API with no special access required. The adapter API plus Next.js caching interfaces form the complete platform integration surface. The adapter handles build-time output, while `cacheHandler` (singular) covers server cache paths like ISR, route handlers, patched `fetch`/`unstable_cache`, and image optimization. `cacheHandlers` (plural) configures `'use cache'` directive backends.
Verified adapter requirements
A verified adapter meets two requirements: 1) Open source—the adapter source code is publicly available so the community and the Next.js team can inspect, contribute to, and verify it. 2) Runs the compatibility test suite—the platform provides a way to run the full Next.js compatibility test suite against their adapter. Verified adapters are hosted under the Next.js GitHub organization, listed as supported deployment targets in the Next.js documentation, and maintained by their respective platform teams. There are no private framework hooks or integration paths: Vercel's adapter uses the same public API as every other adapter.
Next.js team commitments for verified adapters
For verified adapters and platforms working toward verified status, the Next.js team commits to: Coordinated testing—before major releases, working with platform teams to run the compatibility test suite and surface issues early. Early access—adapter authors receive early access to API changes during RFCs and release candidates. Direct support—when the adapter contract needs updating, working directly with adapter teams.
Closed-source adapters and verification
Platforms can build closed-source adapters on the same public API and test suite. However, closed-source adapters will not be listed as verified, since the Next.js team cannot verify what it cannot inspect.
Edge Stitching is a performance optimization
Edge Stitching is a performance optimization, not a correctness requirement. All features work correctly from a single origin server. Edge Stitching is a performance fidelity optimization that platforms can choose to implement to improve performance, but it is not necessary for functional fidelity.