Next.js 16.2 shipped a stable Adapter API on March 25th, giving hosting providers a public, typed contract for deploying Next.js applications on their own infrastructure. Vercel's own adapter now uses that same contract, with no private hooks. It is open source.
This is a concession years in the making, and it matters. But the fine print from Netlify and Cloudflare tells a more complicated story than Vercel's announcement lets on.
What actually shipped
The Adapter API gives platforms two hooks: modifyConfig, which runs when the Next.js config loads, and onBuildComplete, which fires after the full build output is ready. On build, Next.js now produces a versioned manifest describing routes, prerenders, static assets, runtime targets, caching rules, and routing decisions. An adapter reads that manifest and maps it onto whatever infrastructure the platform provides.
Breaking changes to the API require a new major version of Next.js. That is a real commitment, and one that platform providers have been asking for since at least 2022, when OpenNext started as an SST project to reverse-engineer Vercel's deployment process for AWS Lambda.
Two adapters ship today: the Vercel adapter and a Bun adapter that serves as a reference implementation. Adapters for Netlify, Cloudflare, and AWS (through OpenNext) are, in Vercel's careful phrasing, "in active development, with expected releases later this year."
Why this took so long
The vendor lock-in criticism has dogged Vercel for years. The complaint was never that Next.js wouldn't run on other platforms. Hundreds of thousands of apps run via next start on plain Node.js servers without issues. The problem was scaling: cache synchronization across instances, on-demand revalidation propagation, streaming behavior with Server Components. None of this was formally specified. Providers had to reverse-engineer Vercel's internal behavior, and it broke with every release.
Philippe Serhal, an engineer at Netlify, put it bluntly in Netlify's companion post: when the Next.js team reached out to discuss their challenges, 90% of the issues traced back to one thing. No documented, stable mechanism to read build output. That was it.
OpenNext filled the gap starting in late 2022. What began as an AWS Lambda adapter grew into a multi-platform effort after Cloudflare and Netlify joined in late 2024. The collaboration led to a Build Adapters RFC published in April 2025, an alpha implementation in Next.js 16 that October, and the stable release this week.
The governance piece
Alongside the API, Vercel announced the Next.js Ecosystem Working Group, a permanent forum with public meeting notes where hosting providers get early visibility into upcoming framework changes. The March 2025 middleware security incident (CVE-2025-29927, CVSS 9.1) made the case for this kind of coordination pretty vividly. Vercel patched their own platform and published a blog post framing the vulnerability as something their firewall had "proactively protected" against before even contacting Netlify. They later rewrote the post after being called out on social media.
The working group is supposed to prevent that kind of thing from happening again. We'll see.
Here is the problem nobody is celebrating
Netlify's blog post runs about 3,000 words, and the most revealing section is the one labeled "Beyond adapters." Three specific architectural challenges remain, and each one essentially requires bespoke CDN infrastructure that, as far as Netlify can tell, only Vercel currently has.
Partial Prerendering, the hybrid rendering strategy where a static HTML shell gets stitched together with a dynamic response stream into a single HTTP response, needs the CDN to concatenate two streams transparently. No standard CDN can do this. No other framework requires it. Astro's closest equivalent, Server Islands, simply has the browser fetch the dynamic content separately.
Cache revalidation requires atomic updates to groups of coupled cache entries (an HTML response and its corresponding RSC payload, for instance). There is no HTTP caching mechanism for this. It is not a web standard. And on-demand revalidation, where any prerendered route can be invalidated at any time via revalidatePath or revalidateTag, means platforms cannot safely serve any Next.js content as immutable CDN assets. Every request has to go through a mutable cache layer because any page could change at any moment.
Netlify's Philippe Serhal is direct about this: no other framework behaves this way. Astro, SvelteKit, and Nuxt all provide explicit prerender opt-ins that adapters can treat as immutability guarantees.
So who won?
The open-source community, mostly. OpenNext proved that platform portability was viable, and three years of pressure forced Vercel's hand. The Adapter API is well-designed. The test suite (9,000+ end-to-end tests, shared across all adapters including Vercel's) creates a genuine level playing field for functional correctness. And the documentation overhaul, which removed Vercel-specific assumptions and added platform integration guides, was long overdue.
But Vercel still has structural advantages that the Adapter API does not erase. PPR, the framework's most ambitious rendering feature, was designed in tandem with Vercel's CDN. The caching model assumes infrastructure that only Vercel provides. And adapters for the three biggest alternative platforms (Netlify, Cloudflare, AWS) won't ship until later this year, meaning months where the stable API exists but the implementations don't.
James Daniels from Google Cloud's Firebase team captured the tension well in his companion post: the adapter API is an important milestone, not the finish line. Getting all of Next.js's features working behind a traditional CDN has been, in his words, close to impossible.
The Adapter API solves the build output problem. It does not solve the architecture problem. And until Next.js either documents paths to full-fidelity deployment on commodity CDN infrastructure or introduces explicit immutability guarantees like its competitors, "deploy anywhere" will come with an asterisk.
Netlify expects to ship its verified adapter later this year. Cloudflare and AWS through OpenNext are on the same timeline. All three will be open source. The OpenNext team says its aims "may evolve in the near future" now that the official API exists, which sounds like the beginning of a conversation about whether the project still needs to exist in its current form.
The adapters are coming. Whether they can actually deliver full feature parity with Vercel is a different question, and one that Netlify, to their credit, is answering honestly: not yet.
