Next.js 16, Finally: Cache Components & Proxy

Next.js 16 is here, and it’s not just a version bump. The release (October 21, 2025) lands with explicit caching via Cache Components and a framework-level rename of middleware.ts to proxy.ts. Together with a minimum Node.js requirement of 20.9+, React 19.2 alignment, and Turbopack as the default, the changes shape how we build, deploy, and debug full‑stack React apps. If you’ve been dealing with implicit caching surprises or fragile middleware, Next.js 16 gives you a clearer, safer path forward.

What actually shipped—and why it matters

Here’s the thing: the biggest friction in the App Router era has been predictability. Next.js 16 tackles that head‑on.

• Cache Components: The new 'use cache' directive and cacheComponents: true config flip caching from implicit to explicit. You decide what’s cached, for how long, and how it revalidates.
• proxy.ts replaces middleware.ts: A clearer network boundary and a single Node.js runtime. Edge‑runtime middleware is effectively on a deprecation path; use Proxy for request interception, rewrites, and redirects.
• Node.js 20.9+ required: Node 18 is out. This impacts CI images, containers, and serverless runtimes immediately.
• Turbopack default, stable: No more flags. Faster startup and builds, and clearer failures if you still carry custom webpack.
• Next.js DevTools MCP: The Model Context Protocol hook lets AI tools reason about routes, logs, and stack traces with project context—handy for debugging and onboarding.
• React 19.2 integration: View Transitions, useEffectEvent(), and Activity support make motion and background work smoother.

If you lead a product or platform team, this is the release that trades “framework magic” for explicit intent. Fewer invisible caches, fewer runtime mismatches, and a path to safer request interception.

Next.js 16 Cache Components: get explicit, get fast

With Next.js 16, caching is a deliberate choice. You enable it in next.config.ts with cacheComponents: true, then mark routes, components, or async functions with 'use cache'. The compiler generates cache keys from the build ID, a function ID, and serializable inputs—so a cached function that depends only on stable props will return instantly across requests until you revalidate.

Practical example: imagine a product page that pulls a slow‑to‑change category tree and a dynamic inventory feed. Wrap the category sidebar component with 'use cache' and set a cache lifetime (say, hours). The rest of the page remains fully dynamic.

• Constraints to respect: Arguments and returns must be serializable. Don’t poke into non‑serializable values passed through as children; render them. Avoid cookies/headers at build‑time; if you need personalized caching, reach for 'use cache: private'.
• Revalidation: Use cacheLife() for lifetimes and cacheTag() for on‑demand invalidation (e.g., after a product import).
• Defaults changed: With cache components on, dynamic code executes at request time by default. You opt into caching where it makes sense—no more guessing what fetch did.

Where teams win fast: header/footer blocks, marketing sidebars, pricing tables sourced from a CMS, expensive formatting routines (e.g., currency matrices), and any API call that changes on minutes‑to‑hours cadence. Start there.

“Do I have to use Cache Components everywhere?”

No. Most apps benefit from caching a few expensive components or queries, not every route. If you turn on cacheComponents without adding 'use cache', your app still runs—just fully dynamic by default. That’s a feature.

Middleware is dead; long live proxy.ts

Next.js 16 renames middleware.ts to proxy.ts and makes the purpose explicit: a network boundary that runs before route handling in a single, predictable Node runtime. The practical implications:

• File rename and function: middleware → proxy. Same logic (rewrites, redirects, headers), but a clearer mental model.
• Runtime clarity: proxy runs on Node.js, not Edge. If you still rely on Edge‑runtime middleware, it’s available but deprecated and slated for removal in a future version. Treat this as a migration clock ticking.
• Config flags renamed: For example, skipMiddlewareUrlNormalize becomes skipProxyUrlNormalize. Update your config alongside the file rename.

Common failure modes we’ve seen this month: framework auth middlewares that assumed Edge APIs, or libraries that implicitly imported Node‑only modules when deployed near the edge. Audit auth, A/B testing, and geo redirects. Keep proxy cheap—headers, cookies, rewrites—and push heavy data access back into routes and Server Actions.

Quick migration: middleware.ts to proxy.ts

1. Rename middleware.ts → proxy.ts; rename the exported function to proxy.
2. Remove Edge‑only code paths. If you truly need Edge, keep the old file temporarily and plan a deprecation.
3. Search your repo for skipMiddlewareUrlNormalize and other middleware config keys; rename to their Proxy equivalents.
4. Run your e2e auth flows and redirect logic locally with Node 20.9+. Watch logs for runtime API access errors.

CI/CD: Turbopack by default and the Node 20.9 reality

Upgrading locally is the easy part. The breakage happens in pipelines. Next.js 16 uses Turbopack for dev and build without flags and enforces Node 20.9+. If your CI image, GitHub Actions runner, or container still pins Node 18, builds will fail—sometimes only in parallel jobs, which makes it maddening to diagnose.

Here’s a field‑tested patch list:

• Bump Node everywhere: dev machines, Docker base images, CI runners. If you manage GitHub Actions, upgrade your Node setup step and cache keys.
• Remove stale webpack config: Turbopack is default; lingering webpack customizations can fail builds. If you must keep webpack for a transition, call it explicitly in scripts and plan a removal window.
• Separate outputs: Next.js now isolates dev and build artifacts. Don’t mix commands in the same workspace across steps; keep build directories clean between jobs.

If you’re tightening CI security while you’re here, take a look at our analysis of the pull_request_target pitfall and the safer patterns teams adopted last winter: GitHub Actions pull_request_target: Dec 8 Fix Guide. Upgrades are a great time to reduce blast radius.

Next.js DevTools MCP: AI that actually helps

DevTools MCP wires a local MCP server into your project so AI agents can read route structure, gather unified logs, and pull stack traces without copy‑pasting. In practice, it’s how juniors ramp faster and how seniors automate repetitive fixups—like renaming middleware to proxy across a monorepo or surfacing mismatched Node versions in scripts.

Don’t overthink it: add the MCP server to your AI client config, point it at your app, and use it for migration chores. It’s not “AI takes my job”; it’s “AI takes my yak‑shaving.”

People also ask

Will my app break if we stay on Node 18 for a bit?

Yes, for Next.js 16 builds and local dev that rely on framework tooling. The minimum is Node 20.9. You can pin production to your current version while you test, but CI and new builds need the upgrade.

Do I need to migrate to proxy.ts today?

If you’re on middleware for rewrites/redirects, yes—rename and test. If you have Edge‑runtime middleware, you can defer while you design a Node‑runtime path or isolate the true edge bits. The deprecation clock is running.

Is Cache Components required?

No. When you enable cacheComponents, your app is dynamic by default. You opt into 'use cache' where it pays off. Start with expensive, stable sections.

Does Turbopack mean I must delete webpack config?

Short term, you can keep webpack by opting in explicitly. Long term, assume Turbopack is the path. The fewer custom loaders you carry, the less migration tax you pay later.

A pragmatic upgrade checklist (90 minutes to green)

1. Inventory: Search for middleware.ts, custom webpack configs, and Node version pins across Dockerfile, Actions workflows, and package scripts.
2. Node first: Install Node 20.9+ locally and in CI. Verify node -v at the start of each pipeline job.
3. Rename: middleware.ts → proxy.ts, function to proxy, config flags to Proxy names. Run your auth and rewrite paths end‑to‑end.
4. Turbopack smoke test: Remove --turbopack flags from scripts (they’re default now). If you see build failures tied to webpack customizations, isolate or remove them.
5. Turn on Cache Components: Add cacheComponents: true. Wrap two or three costly components with 'use cache' and set cacheLife(). Measure TTFB and server CPU.
6. DevTools MCP: Add the MCP server and run a quick “upgrade assistant” prompt to catch stragglers.
7. Rollout: Stage the upgrade behind a canary environment, log cache hit rates, and watch 95th percentile response times for a day.

Metrics that matter after the upgrade

Make the upgrade pay off by staring at a short list of numbers:

• Server CPU and memory: Cache Components should shave CPU when you pick your spots well.
• Navigation latency: With explicit caching, instant navigations are easier to achieve on busy pages.
• Build time: Turbopack reduces compile time; if it doesn’t, your custom loaders are the likely culprit.
• Cache invalidation errors: If content looks stale, check cacheTag() usage and revalidation hooks tied to your CMS or import jobs.

Zooming out: where Next.js is heading

Next.js 16 nudges the ecosystem toward explicit contracts. Proxy clarifies the request boundary, Cache Components turns implicit heuristics into readable intent, and Turbopack trims tooling overhead. The direction is unmistakable: fewer footguns, more defaults that scale.

If you want a deeper, day‑by‑day plan, use our 30‑Day Next.js 16 Migration Playbook. And if you’d rather bring in a team that’s shipped these upgrades already, our modernization services and recent case studies show the patterns that stick.

Your one‑sprint plan

If you’ve only got one sprint to spare, this sequencing works:

• Day 1–2: Node 20.9+ everywhere, CI fixed, proxy.ts migration done, canary deployed.
• Day 3: Turn on cacheComponents, wrap the two heaviest components, add cacheLife(), and wire cacheTag() to your CMS publish webhook.
• Day 4: Remove or isolate webpack customizations. Enable DevTools MCP for the team.
• Day 5: Tidy logs, add dashboards for cache hit rate and response percentiles, and ship broadly.

What to do next

• Upgrade your Node and CI now; schedule Proxy migration immediately after.
• Enable Cache Components and cache the top two expensive, low‑volatility components.
• Use DevTools MCP to automate refactors and surface runtime mismatches.
• Plan for a webpack exit or containment strategy under Turbopack.
• If you need a partner, explore how we work on upgrades on What We Do.

No framework move is free. But Next.js 16 trades hidden complexity for visible intent: a simple 'use cache', a clear proxy.ts, and a single Node runtime version to standardize. Tackle the Node bump, flip caching on where it counts, and let Turbopack do its job. You’ll feel the wins in your build logs and your error budget.