Next.js 17 Isn't Out Yet. Here's the Version Your App Should Actually Run.

If you searched for Next.js 17 and landed on an article describing its bundler overhaul and agent-aware components, you read something that was invented. Next.js 17 does not exist. As of August 6, 2026, the latest stable release is Next.js 16.3, published on August 3, 2026.

I have shipped production SaaS applications on every Next.js major since 13, and I audit codebases for founders full time. Version confusion is not a trivia problem. It is the reason I keep finding apps pinned to an unsupported major, running known vulnerabilities, while the founder believes they are on something modern because their AI coding agent told them so.

Here is the verified state of Next.js versions right now, and the upgrade policy I use on every client project.

Why articles about "Next.js 17" exist

Search results are now polluted with AI-generated release coverage for versions that were never published. I have seen posts confidently dated to June 2026 describing Next.js 17 as the release that made Turbopack the default bundler and introduced agent-aware components.

Both of those claims are stitched together from real events attached to the wrong version number. Turbopack became the default bundler in Next.js 16, released October 21, 2025. The agent-focused tooling arrived across the 16.2 and 16.3 minors in 2026. A language model summarizing that timeline without checking the source will happily round it up to a major it has never seen.

This matters more than it used to. Your coding agent reads the same polluted web you do. When an agent absorbs a fictional release note, it will happily write configuration for a flag that was never real. The config silently does nothing, and the developer believes a feature is enabled that is not.

The fix is boring and it works: verify version claims against the official release blog and support policy, never against a blog post. The Next.js blog and the Next.js support policy are the only authoritative sources, and both are cheap to check.

What version of Next.js is current in August 2026?

Here is the actual state, taken from the official support policy and release blog.

• →16.3 (released August 3, 2026) is the latest stable release and sits inside the Active LTS line. Run this for most production apps.
• →16.2.11 (released July 20, 2026) is the latest security patch of the 16.2 minor. Run this if you are not ready to move to 16.3 yet.
• →15.5.21 (released July 20, 2026) is the current Maintenance LTS patch. Run this only if a 16.x migration is genuinely blocked.
• →14.x and older are unsupported. They receive no security patches. Migrate now.
• →17.x does not exist and has no release date.

Active LTS is the phase a major version occupies from its release until the next major ships. During Active LTS a version gets new features, bug fixes, performance work, and security patches. Next.js 16 entered Active LTS on October 21, 2025 and is still there.

Maintenance LTS is the phase a major enters once its successor is released. It receives only critical bug fixes and essential security updates, and it lasts two years from that major's original release date. Next.js 15 shipped October 21, 2024, which puts its maintenance window on a clock.

One detail founders miss: for Maintenance LTS versions, fixes ship as semver-minor releases even when they contain breaking changes. If you have pinned 15.x with a caret range and assumed minors are always safe, that assumption does not hold on the maintenance line.

What actually shipped in the Next.js 16 line

If you skipped the 16.x minors because you were waiting for a mythical major, here is what you missed. Every item below is from an official release post.

Next.js 16 (October 21, 2025) was the real inflection point. Turbopack became the default bundler for all apps. React Compiler support went stable. Cache Components arrived, built on Partial Pre-Rendering and the use cache directive. It also carried breaking changes, most notably async request params.

Next.js 16.1 (December 18, 2025) made Turbopack file system caching stable for next dev and added next dev --inspect for easier debugging.

Next.js 16.2 (March 18, 2026) delivered roughly 400% faster next dev startup and roughly 50% faster rendering. It also brought a stable Adapter API, which is the change that matters if you deploy anywhere other than Vercel.

Next.js 16.3 (August 3, 2026) cut development memory usage by up to 90% and introduced Instant Navigations, a set of tools that gives App Router navigation the responsiveness of a client-side SPA through partial prefetching of a reusable route shell.

For a small SaaS team, the cumulative effect of 16.1 through 16.3 is a meaningfully faster feedback loop. That is not a marketing claim about your users. It is time you get back every day.

The rule I use: run Active LTS, not "latest"

The most common version question I get is some form of "should I always be on the newest release?" My answer on every engagement is the same, and it has two parts.

Stay on the Active LTS major. Within it, take the newest patch quickly and the newest minor deliberately.

The reason to stay on the Active LTS major is security, and 2026 made that concrete. In December 2025 the ecosystem absorbed a critical vulnerability in the React Server Components protocol, CVE-2025-66478, rated CVSS 10.0 and allowing remote code execution. A week later two more RSC vulnerabilities were disclosed, a high-severity denial of service and a medium-severity source code exposure.

That exploit, referred to as React2Shell, is what pushed Vercel to formalize its process. On July 13, 2026 the team announced a scheduled security release program with advance notice for patches. The first scheduled release landed on July 20, 2026 and addressed 4 high and 5 medium severity vulnerabilities, with users directed to upgrade to 16.2.11 on Active LTS or 15.5.21 on Maintenance LTS.

Here is the part founders should internalize. A predictable monthly patch cadence is only a benefit if someone applies the patches. An unsupported major receives none of them at all. In the codebases I audit, the most common security finding is not an exotic bug. It is an app running a major that stopped receiving fixes long ago.

The reason to take minors deliberately rather than instantly is different. Minors in the 16 line have shipped real behavior changes to caching and navigation. Those are the kinds of changes that pass CI and surface as a support ticket three days later. Waiting for the first patch release of a new minor costs you nothing and catches the obvious regressions on someone else's production traffic.

This is exactly the kind of unglamorous operational decision I set up during a Codebase Audit, because it is invisible until the week it saves you.

How to check and upgrade your Next.js version

Five steps. Run them today, then put step 5 on a schedule.

1. Find out what you are actually running

Your package.json range is not the truth. The lockfile is.

# The resolved version in your lockfile, not your semver range
npm ls next

# Or ask the binary directly
npx next --version

2. Pin an exact version

Ranges make your production build depend on the day it ran. On client projects I pin exactly and upgrade on purpose.

{
  "dependencies": {
    "next": "16.3.0",
    "react": "19.2.0",
    "react-dom": "19.2.0"
  }
}

3. Use the official codemod for major and minor moves

Do not hand-migrate breaking changes when there is a tool for it. The upgrade CLI walks you through the version choice and applies the relevant codemods.

# Interactive upgrade with codemods applied
npx @next/codemod@canary upgrade latest

If you are moving from 15.x to 16.x, expect the async request APIs to be the bulk of the work. That change is mechanical, and the codemod handles most of it.

4. Verify before you deploy

npm run build
npx next start

A clean type check is not a passing build. Run the actual production build and boot the server locally before anything reaches your host.

5. Automate the security patch, not the feature upgrade

This is the step almost nobody sets up, and it is the one that matters. Configure your dependency bot to auto-merge patch releases of Next.js while holding minors for review.

{
  "extends": ["config:recommended"],
  "packageRules": [
    {
      "matchPackageNames": ["next"],
      "matchUpdateTypes": ["patch"],
      "automerge": true
    },
    {
      "matchPackageNames": ["next"],
      "matchUpdateTypes": ["minor", "major"],
      "automerge": false,
      "addLabels": ["needs-review"]
    }
  ]
}

Pair that with subscribing to the Next.js blog RSS feed. Vercel now gives advance notice of scheduled security releases, which means you can know a patch is coming before it lands.

What to do when Next.js 17 actually ships

It will, and the pattern is predictable. Majors have landed roughly annually, in October, for several years running.

When it does, three things happen at once. Next.js 17 becomes Active LTS. Next.js 16 moves to Maintenance LTS and starts its two-year clock. Next.js 15 falls out of support entirely.

My advice for a small team on that day: do nothing for a quarter. Read the breaking changes, note whether any touch your caching or routing surface, and let the first two or three patch releases go by. Then schedule the migration as real work with a real budget rather than squeezing it between features. The only exception is if the release closes a vulnerability that affects you, in which case it stops being an upgrade decision and becomes a security one.

What you should not do is what I keep finding in audits: stay on an old major indefinitely because the migration never got scheduled, then discover during a customer security review that your framework stopped receiving patches a year ago.

The takeaway

Next.js 17 is not out. Run the latest 16.x, treat security patches as non-negotiable and minor upgrades as planned work, and verify every version claim against the official sources rather than a search result. That is the entire policy, and it takes about an hour to set up properly.

If your app is stuck on an unsupported major and you are not sure what the migration costs, that assessment is most of a Codebase Audit, and it is the same diagnostic work I describe in why vibe-coded apps fall apart. You can see the kinds of builds this applies to on my work page.

Building or rescuing a Next.js SaaS and want a second opinion on your stack? Book a free scope call.

Version facts in this post verified against nextjs.org on August 6, 2026.