
Next.js 16 makes Turbopack the default. Migration is mostly free.
Next.js 16 ships Turbopack as the default bundler for dev and prod, replaces middleware with proxy.ts, and introduces a Build Adapters API. Six months in, the migration story is calmer than expected.
Next.js 16 has been out since October 2025, and the migration story is now clearer than it was at launch [Next.js 16 release].
── What shipped ──
Turbopack is the default bundler for both next dev and next build. Vercel cites 5–10x faster Fast Refresh and 2–5x faster production builds for typical projects [Next.js 16 release].
Three changes that matter for migration:
middleware.ts→proxy.ts. The file is renamed to clarify the network boundary. Behaviour is identical; the rename is mechanical.- Cache Components. A new caching primitive built on Partial Pre-Rendering and
use cachedirectives. The previous segment-levelrevalidateAPI still works but is no longer the recommended approach. - Build Adapters API. Hosting providers (Cloudflare, Netlify, AWS, etc.) get a stable hook to mutate config and post-process build output. This unblocks first-class non-Vercel deployments [InfoQ].
── Why it matters ──
Turbopack moving to default is the visible change. The under-discussed change is the Build Adapters API — it removes a long-standing complaint that Next.js was easy on Vercel and awkward everywhere else. With a public adapter API, expect first-class adapters from Cloudflare, AWS Lambda, and self-hosted Node within the next two release cycles.
For teams sitting on Next.js 14 or 15: the upgrade path is mostly mechanical. Rename middleware.ts to proxy.ts, update Node 20 → 22 if needed, and run the codemods. Cache Components is opt-in — old caching keeps working.
The webpack-to-Turbopack delta is the place to measure. If you have custom webpack config (image loaders, transformers, plugin chains), check whether Turbopack supports your specific chain — this is where most reported migration friction sits.
── Editor's take ──
Six months of community shake-out has done the de-risking work. If you are running Next.js 14 or 15 in production today, schedule a one-engineer-week migration window in the next quarter. The performance gain pays the cost back.
// newsletter_offline · provider_not_configured