Next.js 16.2 Finally Gets Self-Hosting Right

TL;DR

• Next.js 16.2 ships a stable Adapter API — hosting providers now get a typed, versioned contract for the build output.
• Vercel’s own adapter uses the same public API as everyone else. No private hooks, no special paths.
• Netlify, Cloudflare, AWS (via OpenNext), and Google Cloud are building on it. Bun already shipped a reference adapter.
• next start now handles every feature: Server Components, ISR, PPR, Cache Components, Server Actions, after() — all of it.
• The criticism about vendor lock-in was valid. This release is Vercel’s most concrete answer to it.

The Lock-In Problem Was Real

For years, the community called out Next.js for making self-hosting harder than it should be. Vercel built the framework and sold the hosting. The incentives were misaligned, and the codebase reflected it.

The build output format was undocumented. Hosting providers like Netlify and Cloudflare had to reverse-engineer Next.js internals to support it — building on top of APIs that could break in any patch release. Netlify dedicated a full engineering team  just to keep up.

Then there was minimalMode — an undocumented configuration that Vercel used internally. It disabled core features like middleware handling, which Vercel reimplemented in their own closed-source edge infrastructure. Other providers had to figure this out on their own.

Brandon Bayer from Flightcontrol wrote about the “secret knowledge”  needed to self-host Next.js in production. Eduardo Boucas from Netlify published a detailed breakdown of everything you should know  before choosing the framework. Both posts resonated because they described what many developers had experienced firsthand.

I had the same frustrations. Setting up Next.js on a VPS meant reading through GitHub issues, stitching together partial solutions, and hoping nothing broke on the next update.

What Was Actually Broken

Here’s the thing — you could self-host Next.js. next start worked. But “works on a single server with no CDN and no image optimization” is a far cry from production-ready. The gap between what Vercel got out of the box and what everyone else got was massive.

Image optimization was the first wall most people hit. next/image required manually installing sharp, which had native dependencies that broke across platforms. The configuration was poorly documented, and the behavior didn’t match what Vercel’s optimized pipeline delivered. Many teams just gave up and used a third-party image CDN.

ISR broke at scale. Incremental Static Regeneration stored its cache on the local filesystem. One server? Fine. Two or more behind a load balancer? Each instance had its own cache, serving different versions of the same page. There was no built-in support for shared cache stores like Redis or S3. You had to write your own cache handler using an undocumented API that could change without notice.

Cache-Control headers got overwritten. Next.js injected its own Cache-Control values on responses, ignoring whatever you set. If you had a CDN in front of your deployment — which most production setups do — your caching strategy was broken by default. You couldn’t control how your own pages were cached.

Middleware didn’t run the same way. Because of minimalMode, middleware behavior outside Vercel was different. Vercel’s edge infrastructure handled middleware separately, so the framework assumed things about the runtime that weren’t true for anyone else. Features that worked on Vercel would silently fail or behave differently on a VPS or container.

after() and instrumentation.js were experimental or broken. Server lifecycle hooks and post-response callbacks — features you’d expect in any production framework — were either gated behind experimental flags or didn’t work at all outside Vercel’s runtime.

The serverless output mode disappeared. Next.js had a target: 'serverless' option that produced Lambda-compatible output. In October 2022, it was removed without replacement . The official React docs still claimed Next.js could deploy to “any serverless hosting,” but no documentation existed for how to actually do it.

The build output was a moving target. No spec, no versioning, no stability guarantee. Hosting providers built on internal APIs that could break in any patch release. This is why Netlify needed a full team just to maintain Next.js support — and why smaller hosting companies couldn’t support it at all.

The narrative online was often “Next.js can’t be self-hosted.” That wasn’t technically true. The more accurate version: Next.js couldn’t be self-hosted at production quality without significant engineering effort and tribal knowledge that wasn’t in any official docs.

What Changed

Next.js 15: The First Step

Next.js 15 (October 2024) was the first release that explicitly addressed self-hosting. sharp installed automatically for image optimization. Cache-Control headers stopped being overwritten. Custom cache handlers became simpler to configure. The after() API and instrumentation.js worked out of the box with next start.

Lee Robinson published a tutorial showing Next.js on a $4 VPS  with Docker and Nginx. It was a clear signal that Vercel was taking the criticism seriously.

The Adapter API RFC

In April 2025, the Next.js team published the Build Adapters RFC  after private discussions with the OpenNext team. The idea: give hosting providers a stable, typed interface to the build output instead of forcing them to parse undocumented internals.

Next.js 16.2: The Stable Release

On March 25, 2026, the Adapter API shipped as stable in Next.js 16.2. The official announcement  laid out the details.

On build, Next.js now produces a typed, versioned description of your application — routes, prerenders, static assets, runtime targets, dependencies, caching rules, and routing decisions. Adapters hook into two points:

• modifyConfig — when configuration loads
• onBuildComplete — when the full output is ready

Breaking changes require a new major version of Next.js. That’s the commitment hosting providers needed.

Vercel Eats Its Own Cooking

The part that matters most: Vercel’s adapter uses the exact same public contract. It’s open source . No private hooks. No undocumented code paths.

This was the core ask from the community for years. Not just “let us self-host” but “stop giving yourself an unfair advantage.” The stable Adapter API with Vercel on the same footing addresses that directly.

The Ecosystem Response

The announcement came with coordinated posts from multiple providers:

• Netlify: “The Next.js Adapter API Just Shipped” 
• OpenNext: “3 Years of OpenNext” 
• Google Cloud / Firebase: “A Bright Future for Next.js on Google Cloud” 

Philippe Serhal from Netlify put it well:

“When the Next.js team reached out, we started compiling a laundry list of specific issues. But it quickly became clear that the common thread among 90% of these was simply the lack of a documented, stable mechanism to configure and read build output.”

OpenNext deserves credit here. What started as a community workaround for deploying Next.js to AWS Lambda grew into the foundation for the official API. Their collaboration with the Next.js team turned a hack into a standard.

Vercel also opened 9,000+ end-to-end tests to adapter authors — the same suite they use for their own adapter.

The Cloudflare Factor

I think Cloudflare’s vinext  project accelerated all of this. In February 2026, a single Cloudflare engineer rebuilt 94% of the Next.js API surface using Vite — in one week, for $1,100 in AI costs. Builds ran up to 4x faster with 57% smaller client bundles.

When a competitor can replicate most of your framework in a week, making your build output proprietary stops being a competitive advantage and becomes a liability. The Adapter API is the smarter play.

Self-Hosting Today

If you’re on Next.js 16.2, self-hosting is no longer a second-class experience. A single next start process now handles every feature:

For Docker deployments, set output: 'standalone' in next.config.ts to get a self-contained build in .next/standalone. Pair it with Nginx (disable buffering for streaming with X-Accel-Buffering: no) and you’re good.

My Take

The criticism was deserved. Next.js made it too hard to run outside Vercel for too long, and the community was right to push back. But I also think this release is exactly the right response — not just documentation improvements or blog posts, but a structural change that puts every hosting provider on equal footing with Vercel itself.

The Ecosystem Working Group (with engineers from Netlify, Cloudflare, Google Cloud, AWS Amplify, and OpenNext) and the open test suite suggest this isn’t a one-time gesture. It’s a new operating model.

I deploy this blog on Vercel — and I’m fine with that choice. But the point of the Adapter API is that it’s a choice now, not a dependency. If I ever need to move, the path is documented, stable, and tested. That wasn’t true a year ago. If you’ve been holding off on Next.js because of the lock-in concerns — those concerns were valid, but this release addresses them head-on.