Next.js 16.3 and the upgrade I stopped deferring

Next.js 16.3 shipped on August 3 with a claim I've wanted to be true for about two years: long next dev sessions now use up to 90% less RAM. Three weeks later, Vercel shipped an out-of-cycle security release with two critical remote-code-execution advisories. Those arrived as separate announcements, and I read them a week apart. They are the same decision.

This site runs 15.3.8. Writing this post is what made me look.

What 16.3 actually changes

Everything below is Vercel's own benchmark, measured on Vercel's own applications. I have not run any of it against this site, because this site is a major version behind and the comparison would be dishonest. I would rather hand you an attributed number than a borrowed one.

Dev memory. Turbopack now enables disk caching and memory eviction by default. Vercel reports the vercel.com dashboard dropping from 21.5 GB to 2 GB after compiling 50 routes, and nextjs.org from 4,600 MB to 840 MB. That is the "up to 90%" in the headline, and the shape of it matters more than the percentage: this is the long-session leak, not cold-start memory. If your dev server is fine for an hour and unusable by mid-afternoon, this is the fix.

Build caching. The same disk cache now applies to next build. Vercel's numbers range from 1.4× on vercel.com/home to 5.5× on vercel.com/geist. Repeat builds on CI benefit most, which means the gain depends on whether your CI preserves the cache between runs — the changelog can't tell you that, your pipeline can.

SSR throughput. The App Router rendering layer moved from web streams to native Node.js streams, removing a conversion in the hot path. Vercel measured up to 22% more requests under load with no application changes. This one is free in the truest sense: it isn't a flag, it isn't opt-in, and there's nothing to configure.

TypeScript 7 can now do type checking during next build, if you bump your local dependency. And import.meta.glob landed in Turbopack, which is directly relevant to any blog that reads MDX off the filesystem — including this one.

The larger story in 16.3 is Instant Navigations, an opt-in set of behaviors behind cacheComponents and partialPrefetching. Vercel has said these become default in a future major. That's the part I'd budget real time for, and it is not what upgrading is for today.

turbopackUseSystemTlsCerts: removed in 16.2, so don't set it on 16.3

Short answer: on Next.js 16.2 and later, including 16.3.3, there is no turbopackUseSystemTlsCerts option and no NEXT_TURBOPACK_EXPERIMENTAL_USE_SYSTEM_TLS_CERTS variable to set. Turbopack now trusts your operating system's certificate store by default. The flag only ever existed in 16.0 and 16.1.

The problem it solved is still worth understanding, because it's the one you'll be debugging if you're searching for it. Turbopack makes a few network requests of its own from Rust, not Node — the one most apps hit is next/font/google downloading font files at build and dev time. Inside a company network, a proxy or security gateway (Zscaler, Netskope, Cloudflare WARP and similar) often intercepts HTTPS and re-signs it with the company's own certificate authority. Your browser and curl trust that authority because IT installed it in the OS trust store. Turbopack originally didn't read that store — it shipped its own bundled list of root certificates — so its requests failed while every other tool on the machine worked. The typical symptom is a warning like Error while requesting resource against fonts.googleapis.com.

The history, from the Next.js source:

On 16.1 or earlier, the config looks like this:

// next.config.ts — Next.js 16.0 / 16.1 only
const nextConfig = {
  experimental: {
    turbopackUseSystemTlsCerts: true,
  },
};

On 16.3, delete it: the key no longer exists, so it does nothing. If fetches still fail with certificate errors after upgrading, check where the company certificate is actually installed. Turbopack now reads the OS trust store. NODE_EXTRA_CA_CERTS only affects Node's own requests, so a certificate added only through that variable is still invisible to Turbopack. That mismatch — every other tool fine, only the build failing — is the thing to check before assuming the proxy or firewall is down.

The upgrade tax the changelog doesn't price

15.3 to 16.3 is not a version bump, it is a migration. Turbopack's role changed, the caching model was deliberately simplified toward "dynamic by default, no hidden or implicit caching," and the 'use cache' primitive is now the thing everything else is being built on. None of that is a surprise if you've been following along; all of it is work if you haven't.

So the honest sequencing is two moves, not one:

1. Take the patch on the line you're already on. Nothing to migrate, nothing to test beyond your existing build.
2. Evaluate 16.3 on a branch, with a real build and a real load test, on your own schedule.

Collapsing those two into one decision is how a security patch ends up waiting three weeks behind a migration. The patch has no dependency on the migration. Ship it separately.

Protocol upgrades split the same way. MCP's 2026-07-28 spec is worth adopting outright for a new integration and worth deferring on a working one until something forces the issue — same reasoning, different layer.

The security release removed the "later" option

On August 25 — moved forward a day from the originally announced date, after a second critical was identified — Vercel published 16.3.3 (Active LTS) and 15.5.24 (Maintenance LTS), covering two critical-severity issues:

• AVIF image optimization RCE (GHSA-2xp9-vwfh-vxw4). A flaw in libheif, reached through sharp, can give unauthenticated remote code execution when Next.js optimizes an attacker-controlled AVIF image. The patched releases disable AVIF optimization outright until the upstream fix lands.
• Windows-hosted RCE (CVE-2026-75604). Applications using both the Pages Router and the App Router without Cache Components, served from a Windows filesystem. Linux and macOS are unaffected, and there is no known workaround for the applications that are.

That's the qualifier I'd want someone to give me, rather than a blanket "you are vulnerable." Reachability is the whole question with this class of bug. But "probably not reachable" is a reason to stay calm while you patch, not a reason to skip patching — the exposure changes the day someone adds a remote image source and doesn't think about a CVE from last August.

What I'm doing

Patch first, on the line I'm already on. Then put 16.3 on a branch and actually measure it against this app, because that's a post I can write with my own numbers instead of Vercel's.

The performance work in 16.3 is a good reason to want the upgrade. It is not the reason to move this week. The two advisories are.

Keeping a production Next.js app patched, fast, and boring to operate is part of the full-stack work I take on.

Sources: Next.js 16.3, August 2026 Security Release, Update: August Next.js Security Release