Next.js 16.2 shipped a stable Adapter API on March 18, 2026. A week later, Jimmy Lai and JJ Kasper published the story behind it and four commitments: the API, a shared test suite, verified adapters and an ecosystem working group. Engineers from OpenNext, Netlify, Cloudflare, AWS Amplify and Google Cloud co-designed it.
For years, running Next.js at full fidelity outside Vercel meant reverse engineering build output. This release makes that output a documented, versioned contract.
Why hosts needed a contract
A single next start server works anywhere, and the post says hundreds of thousands of teams deploy that way. Trouble starts with a second instance. Cached content has to stay in sync, on-demand revalidation has to reach each instance, and streaming has to survive the load balancer. Add a CDN, edge compute or serverless cold starts, and the surface grows: Server Components, Partial Prerendering, middleware, Cache Components. The docs didn't describe how those pieces interact.
Philippe Serhal at Netlify described what happened when Netlify listed its problems for the Next.js team. About 90% of them traced back to one gap: no documented, stable way to configure and read build output.
OpenNext proved it could work
OpenNext started as a community layer that translated Next.js build output into each provider's primitives. It became a production adapter on AWS first, and Cloudflare and Netlify joined later. The project showed that build output could serve as an interface. In April 2025 the Next.js team published a Build Adapters RFC, formed a working group with those maintainers and the platform engineers, and spent eleven months designing and validating the API.
The API: two hooks and a typed output
An adapter is a module with a name and two optional hooks. You point Next.js at it with the top-level adapterPath, or a platform sets NEXT_ADAPTER_PATH for zero-config deploys.
// my-adapter.js
/** @type {import('next').NextAdapter} */
module.exports = {
name: "my-adapter",
async modifyConfig(config, { phase }) {
return config;
},
async onBuildComplete({ outputs, routing, buildId }) {
for (const page of outputs.prerenders) {
console.log("prerendered", page.pathname);
}
},
};
modifyConfig runs when the config loads. onBuildComplete receives the full description of your app: App pages and routes, Pages Router output, prerenders, static files, middleware, and routing tables split into before-middleware, before-files, after-files, dynamic routes and fallback. A breaking change to that shape requires a new Next.js major version.
Vercel's adapter uses the same public API with no private hooks, and it's open source at nextjs/adapter-vercel. That's the detail that makes the rest believable.
The hook has a use outside hosting, too. This site runs Pagefind after next build through a separate script that finds the prerendered HTML. An adapter's onBuildComplete receives outputs.prerenders as an argument, which is a cleaner place for post-build indexing.
One test suite for all adapters
The Next.js team opened its test suite to adapter authors. It covers streaming, caching, client navigation and the edge cases that bit real apps, and each new feature adds tests. An adapter author runs it and gets a pass or fail per feature. Vercel's adapter runs the same suite, so all adapters clear the same bar.
| Adapter | Status |
|---|---|
| Vercel | Verified, open source |
| Bun | Verified reference adapter for an alternative runtime |
| Netlify, Cloudflare, AWS via OpenNext | In development, expected later in 2026 |
A verified adapter must be open source and pass the full suite. It lives under the Next.js GitHub org and appears in the Deploying to Platforms docs, but the team that builds it keeps publishing rights and release cadence. Providers can also ship closed-source adapters on the same API, without the verified label.
The working group
The Next.js Ecosystem Working Group gives providers and adapter maintainers a standing forum with public meeting notes. The team promises early notice of changes, lead time on breaking changes in proportion to their scope, and cross-platform testing before release. Netlify, OpenNext and Google Cloud published their own posts the same day.
The team also rewrote the platform docs during the project. New guides cover the rendering philosophy, a feature matrix per platform, PPR for platforms, how revalidation works and CDN caching. If you self-host, read the revalidation and CDN guides even if you don't plan to write an adapter.
What to do with it
- Ask your host whether it runs a verified adapter, and for its test suite results. "We support Next.js" now has a measurable meaning.
- If you self-host on more than one instance, read the revalidation guide and check that
revalidateTagreaches each instance. - If you run custom post-build steps, such as search indexing or sitemap uploads, try moving them into an adapter's
onBuildComplete. - Before you choose a host for a new Next.js app, check the Deploying to Platforms matrix for the features you plan to use, starting with streaming and Partial Prerendering.
Volodymyr Chornous