Next.js 16.2 shipped a stable Adapter API last week. On the surface that sounds like an internal refactor. It's not. It's the result of two years of collaboration between the Next.js team, OpenNext, Netlify, Cloudflare, AWS Amplify, and Google Cloud, and it means one concrete thing: Next.js now has a typed, versioned, public contract that any platform can implement to run your app correctly.
What the Adapter API actually is
When Next.js builds, it produces a description of your application: routes, prerenders, static assets, runtime targets, dependencies, caching rules, and routing decisions. The Adapter API makes that output a stable interface that adapters consume and map onto a provider's infrastructure.
Adapters implement two hooks: modifyConfig when configuration loads, and onBuildComplete when the full output is available. Breaking changes require a new major version of Next.js. The contract is public, versioned, and open source, Vercel's own adapter uses this same public contract with no private hooks.
How we got here
The story starts with Netlify's engineering team spending significant effort working around undocumented assumptions in Next.js build output. When the Next.js team reached out to understand their pain points, a common thread emerged in 90% of the issues: there was no documented, stable mechanism to configure and read build output.
OpenNext had already filled this gap for AWS, Cloudflare, and Netlify by translating Next.js build output into something each platform could consume. That experience showed the Next.js team that the build output could serve as a stable interface. The collaboration that followed produced the RFC published in April 2025, which led directly to the stable Adapter API in 16.2.
What changes for developers
If you deploy to Vercel, nothing changes, it works exactly as before. If you deploy elsewhere, the situation improves significantly. OpenNext, Netlify, Cloudflare, AWS Amplify, and Google Cloud all implement this same contract, meaning Next.js features like streaming, Server Components, Partial Prerendering, middleware, and on-demand revalidation should work correctly on all of them.
The Next.js ecosystem working group, including representatives from all five platforms, will coordinate future changes to prevent the kind of divergence that made cross-platform support difficult in the first place.
The practical upside
For framework authors and platform teams, the Adapter API means you no longer need to reverse-engineer Next.js internals to support it properly. For developers choosing a platform, it means the framework itself makes a commitment about how your app will behave, not just the hosting provider.
tldr
- Next.js 16.2 ships a stable, public Adapter API, a typed contract between the framework and deployment platforms
- OpenNext, Netlify, Cloudflare, AWS Amplify, and Google Cloud all implement the same contract; Vercel uses it too (no private hooks)
- The ecosystem working group formed across all five platforms means future Next.js changes will be coordinated, not silently breaking
faq
- Do I need to change anything? If you're on Vercel, no. If you're deploying elsewhere, your platform will update its adapter to use the new API.
- What about Next.js 15 apps? The Adapter API is available now; check your platform's adapter for compatibility details.
- Is this related to the OpenNext project? Yes, OpenNext maintainers co-designed the Adapter API and it replaces OpenNext's role as an unofficial compatibility layer.
