Next.js 16 Boilerplate Migration & Security 2026

TL;DR

Next.js 16 is the biggest breaking release since the App Router landed in Next.js 13. If you run a boilerplate or starter kit built on Next.js 15, you need to act: synchronous Request APIs are fully removed (not just deprecated), middleware.ts is replaced by proxy.ts, and Turbopack is the default bundler for both dev and production. On the security side, a critical RCE vulnerability (CVE-2025-66478) patched in Next.js 16 affects all App Router projects on 15.x — upgrade is not optional.

---

Key Takeaways

• Node.js 20.9+ required — Node.js 18 support is dropped; boilerplates must update engine constraints and CI configs before shipping Next.js 16.
• Async Request APIs are fully removed — cookies(), headers(), params, and searchParams must all be awaited. Synchronous access throws at runtime.
• Turbopack is the new default — New projects use Turbopack; existing projects that relied on Webpack plugins need a compatibility audit.
• CVE-2025-66478 (RCE) and CVE-2025-55184 (DoS) — Both affect App Router projects on Next.js 15.x and are patched in 16. Staying on 15 without backports is a liability.
• middleware.ts → proxy.ts — The middleware filename and export are deprecated; the new proxy.ts convention clarifies network boundary semantics.
• "use cache" replaces implicit caching — The new Cache Components model is opt-in and explicit; old fetch caching assumptions will break in migrated apps.
• T3 App and major boilerplates have migrated — Create-T3-App, Makerkit, and SaasBold have updated to Next.js 16 as of March 2026.

---

What's New in Next.js 16

Next.js 16 shipped in early 2026 as the most significant version since the App Router became stable. Rather than incremental polish, this release makes permanent what 15.x started: it removes the compatibility shims that let apps limp along with synchronous patterns, and it promotes experimental features — Turbopack production builds, Partial Pre-Rendering, and the "use cache" directive — to stable or default status.

Turbopack Stable for Production

Turbopack reached development stability in Next.js 15, but production builds still used Webpack by default. In Next.js 16, Turbopack is the default for all builds — development and production — on new projects. The claimed performance improvements are substantial: 2–5× faster production builds and up to 10× faster Fast Refresh in development. No configuration change is required for new projects.

For existing boilerplates, the shift creates a compatibility audit need. Projects that use custom Webpack plugins (e.g., for SVG imports, bundle analysis, or CSS Modules transforms) need to verify each plugin has a Turbopack equivalent or fork. If a plugin has no equivalent, you can opt back to Webpack with the --webpack flag in next build, but that defeats the performance gains.

React 19 as Default

Next.js 16 ships with React 19 as the default React version. React 19 introduced stable Server Actions, improved hydration error messages, and the new use() hook for reading promises and context. Most boilerplates that already upgraded to React 19 during Next.js 15's lifecycle will feel no difference here. For those still pinned to React 18, this is the forcing function.

Cache Components and "use cache"

The most architecturally significant change in Next.js 16 is the new caching model. Previous versions of the App Router used implicit, "magic" caching that caught many developers off guard — fetch() calls were cached by default in ways that were difficult to predict or override.

Next.js 16 replaces this with Cache Components: an explicit, opt-in system centered on the "use cache" directive. You can apply it to a page, a component, or an individual function. Nothing is cached unless you declare it.

// Before (Next.js 15) — implicit caching via fetch
async function getData() {
  const res = await fetch('https://api.example.com/data');
  return res.json(); // cached indefinitely by default
}

// After (Next.js 16) — explicit with "use cache"
"use cache";
export async function getData() {
  const res = await fetch('https://api.example.com/data');
  return res.json(); // cached because you said so
}

Boilerplates that include data-fetching utilities or API wrappers need to audit every fetch() call and decide which should be cached. The implicit behavior is gone.

Partial Pre-Rendering (PPR) Stable

Partial Pre-Rendering — which renders a static shell immediately and streams dynamic content into it — moved from experimental to stable in Next.js 16. Boilerplates targeting edge deployment patterns or dashboard-heavy SaaS apps should consider enabling PPR for key pages. It provides the performance profile of static pages with the data freshness of dynamic rendering.

MCP Integration

Next.js 16 ships with an official Model Context Protocol (MCP) integration via Next.js DevTools. This lets AI coding assistants (including Claude Code) understand your app's routing structure, component tree, and codebase. For boilerplate authors, this is worth documenting in your README — users will expect AI tools to "understand" their project out of the box.

---

Security Improvements & CVE Patches

The security story around Next.js in 2025–2026 is sobering. Multiple critical vulnerabilities were disclosed that affect App Router projects, and several require version upgrades to patch.

CVE-2025-66478: Critical RCE in Next.js

The most severe issue is CVE-2025-66478, a critical Remote Code Execution vulnerability in Next.js. This vulnerability exists in the default configuration of affected applications — no special setup is required to be at risk. It affects Next.js projects using the App Router (Pages Router projects are not affected, but upgrading is still recommended).

Projects on Next.js 15 must apply the backport patch or upgrade to 16. There is no safe way to remain on an unpatched 15.x in a public-facing application.

CVE-2025-55182: React Server Components RCE

A companion RCE vulnerability in React itself (CVE-2025-55182) was disclosed in December 2025. This affects the React Server Components runtime — the same runtime Next.js uses for App Router. The React team patched this quickly, and Next.js 16 ships with the patched React 19 version. Projects still using React 18 with RSC compatibility layers should treat this as a forcing function to upgrade.

CVE-2025-55184 and CVE-2025-55183: DoS and Source Code Exposure

Following the RCE disclosures, two additional vulnerabilities were found: a high-severity Denial of Service (CVE-2025-55184) and a medium-severity Source Code Exposure (CVE-2025-55183). The DoS vulnerability carries a CVSS score of 7.5 and can be triggered by crafted RSC requests. The source code exposure bug can leak server-side code paths under specific conditions.

Both are patched in Next.js 16. If you're maintaining a boilerplate that hasn't upgraded, these CVEs should be prominent in your changelog.

CVE-2025-29927: Middleware Auth Bypass

Earlier in 2025, CVE-2025-29927 disclosed an auth bypass vulnerability in Next.js middleware. Attackers could craft requests that bypassed middleware-based authentication checks. This was patched in 15.x backports, and the architectural change in Next.js 16 (replacing middleware.ts with proxy.ts) partly addresses the underlying design issue. Boilerplates that relied on middleware for auth gating should audit their proxy.ts implementation carefully.

New Default Security Behaviors in Next.js 16

Beyond CVE patches, Next.js 16 hardens several defaults:

• Image optimization: Local IP optimization is blocked by default. Set images.dangerouslyAllowLocalIP: true only for private networks. The images.maximumRedirects default drops from unlimited to 3.
• Secure Server Action IDs: Action IDs are encrypted with non-deterministic IDs, recalculated between builds. This prevents action ID enumeration attacks.
• Explicit cache semantics: The new "use cache" model prevents the accidental caching of authenticated or dynamic data that plagued implicit caching in earlier App Router versions.

---

Migration Checklist

This checklist is ordered by risk level — start with blockers, then work through compatibility.

1. Update Node.js and TypeScript

# Check current versions
node --version   # must be ≥ 20.9.0
tsc --version    # must be ≥ 5.1.0

Update your CI configuration (.github/workflows/*.yml, Dockerfile, railway.toml, etc.) to use Node.js 20 or 22 LTS. Update engines in package.json:

{
  "engines": {
    "node": ">=20.9.0"
  }
}

2. Install Next.js 16

npm install next@latest react@latest react-dom@latest
# or with pnpm
pnpm add next@latest react@latest react-dom@latest

Or use the automated codemod:

npx @next/codemod@canary upgrade latest

3. Migrate Async Request APIs

This is the largest source of runtime errors in Next.js 16 migrations. Every use of cookies(), headers(), draftMode(), params, and searchParams must be awaited.

Before (Next.js 15 — will throw in 16):

// app/dashboard/page.tsx
export default function DashboardPage({ params }) {
  const { slug } = params; // synchronous — BROKEN in Next.js 16
  const cookieStore = cookies();
  const token = cookieStore.get('auth-token');
  // ...
}

After (Next.js 16):

// app/dashboard/page.tsx
export default async function DashboardPage({ params }) {
  const { slug } = await params; // async
  const cookieStore = await cookies();
  const token = cookieStore.get('auth-token');
  // ...
}

The @next/codemod tool handles most of these automatically. Run it before manually auditing.

4. Rename middleware.ts → proxy.ts

The middleware.ts file and the named middleware export are deprecated in Next.js 16. Rename your file and update the export:

Before:

// middleware.ts
export function middleware(request: NextRequest) {
  // ...
}

After:

// proxy.ts
export function proxy(request: NextRequest) {
  // ...
}

The configuration export const config remains the same. Note that if you have auth middleware (Clerk, Auth.js), check their documentation for Next.js 16 compatibility — most have released updated helpers.

5. Migrate next.config.js → next.config.ts

Next.js 16 strongly recommends (and new projects default to) next.config.ts. This gives you TypeScript type-checking on your Next.js configuration:

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  experimental: {
    ppr: true, // enable Partial Pre-Rendering
  },
  images: {
    maximumRedirects: 3, // explicit (was unlimited)
  },
};

export default nextConfig;

6. Update Caching Patterns

If your boilerplate uses fetch() calls with revalidation or unstable_cache, audit them against the new "use cache" model. The old revalidateTag API has a new function signature in Next.js 16 — you can now pass a cacheLife profile as the second argument.

7. Remove AMP and next lint References

Two features are completely removed in Next.js 16:

• AMP: All AMP APIs and config options are gone. Remove amp: true from page exports.
• next lint: The next lint command is removed. Update your package.json scripts to call ESLint or Biome directly.

// Before
"lint": "next lint"

// After
"lint": "eslint . --ext .ts,.tsx,.js,.jsx"
// or with Biome
"lint": "biome check ."

---

Breaking Changes & Fixes

Breaking Change: Synchronous params in Dynamic Routes

One of the most common migration errors is forgetting that params and searchParams in page.tsx and layout.tsx are now Promises, not plain objects.

// This pattern breaks in Next.js 16
export default function ProductPage({ params }: { params: { id: string } }) {
  return <div>{params.id}</div>
}

// Fix: make the component async and await params
export default async function ProductPage({
  params,
}: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await params;
  return <div>{id}</div>;
}

Breaking Change: Turbopack Webpack Plugin Incompatibility

If your boilerplate configures webpack in next.config.ts, those plugins will be ignored when Turbopack is active. Common culprits:

• next-svgr / @svgr/webpack — use the built-in Turbopack SVG handling instead
• webpack-bundle-analyzer — use @next/bundle-analyzer which has Turbopack support
• Custom CSS preprocessors — verify PostCSS config works with Turbopack

To temporarily fall back to Webpack during migration:

next build --webpack

Breaking Change: TypeScript 5.1 Minimum

The satisfies operator, const type parameters, and other TypeScript 5.x features are used internally. If your boilerplate targets TypeScript 4.x users, this is a hard break.

Fix: Hydration Error Messages

Next.js 16 inherits React 19's dramatically improved hydration error messages. Where before you'd get a generic "Hydration failed" error, you now get the specific element and attribute that caused the mismatch. This isn't a breaking change, but it will surface latent bugs in boilerplates that previously masked hydration issues.

---

Boilerplate Compatibility Status

As of March 2026, here's where the major Next.js boilerplates and starter kits stand:

Boilerplate	Next.js 16	Notes
Create-T3-App	✅ Migrated	Updated in v8.0, Turbopack default, async APIs updated
Makerkit	✅ Migrated	proxy.ts migration complete, Auth.js v5 compatible
SaasBold	✅ Migrated	Next.js 16 + Turbopack, Clerk updated
ShipFast	⚠️ In Progress	v4 beta targets Next.js 16, v3 still on 15
Open SaaS	✅ Migrated	Wasp framework handles migration
Next SaaS Starter	✅ Migrated	Vercel template, migrated with official tools
Supastarter	✅ Migrated	proxy.ts and async APIs updated
Epic Stack	✅ Migrated	Remix-based, not affected by Next.js specifics

Auth Library Compatibility

• Clerk: Fully compatible with Next.js 16. The clerkMiddleware() helper has been updated to export from proxy.ts instead of middleware.ts. See Clerk's Next.js 16 migration guide.
• Auth.js (NextAuth v5): Compatible. The auth() handler works with async request APIs. The middleware helper needs renaming to proxy.ts.
• Better Auth: Compatible. No breaking changes required beyond the proxy.ts rename.

ORM Compatibility

• Prisma: Fully compatible with Next.js 16. No ORM-level changes required.
• Drizzle ORM: Fully compatible. Edge runtime support unchanged.
• TypeORM: Compatible, though TypeORM remains less common in modern Next.js boilerplates.

CSS Framework Compatibility

• Tailwind v4: Fully compatible with Next.js 16 and Turbopack. The PostCSS plugin works without changes. See our Tailwind v4 and shadcn/ui guide for setup details.
• CSS Modules: Fully compatible with Turbopack in Next.js 16.
• styled-components / emotion: Check for Turbopack compatibility — both have Turbopack support but may need configuration.

---

Testing Your Migration

After completing the migration steps, run this sequence before shipping:

# 1. Type-check — catches async/await issues and breaking API changes
npx tsc --noEmit

# 2. Build — verifies Turbopack production build succeeds
next build

# 3. Run tests
pnpm test

# 4. Audit for security vulnerabilities
npm audit

Pay particular attention to TypeScript errors around params and searchParams — these are the most common source of runtime failures after upgrading.

If the build fails with a Turbopack plugin error, add --webpack temporarily to unblock yourself while you fix plugin compatibility:

next build --webpack

---

Methodology

This article was researched using the official Next.js version 16 upgrade guide, the Next.js 16 release announcement, security advisories from nextjs.org/blog/security-update-2025-12-11 and CVE-2025-66478, and community migration reports from the Next.js GitHub discussions. Boilerplate compatibility status was verified against each project's public changelog as of March 2026.

• Sources consulted: 12
• Research date: March 2026

---

Evaluating which Next.js boilerplate to buy in the first place? See our best Next.js boilerplates guide for 2026.

Already on Next.js 15 App Router? Our Next.js 15 App Router patterns for SaaS covers the patterns that carry forward into Next.js 16.

Considering a stack change? Read our Next.js vs SvelteKit vs Nuxt boilerplate comparison to see how the options stack up in 2026.