Next.js 16 Server Actions: What Actually Changed

Every version of Next.js has adjusted how Server Actions interact with the cache, and 16 is the biggest rethink yet. Instead of one blunt revalidatePath hammer, you now get three purpose-built functions, each solving a different invalidation problem — and a new caching model that replaces Partial Pre-Rendering outright. If you've been mutating data with Server Actions since the App Router's early days, this is the version where the mental model actually catches up to how people use them.

Three functions instead of one

Previously, invalidating cached data after a mutation meant reaching for revalidateTag or revalidatePath and hoping the timing worked out. Next.js 16 splits that single job into three functions, each with a distinct contract:

• updateTag() — expires a cache tag and refreshes the data within the same request, giving you read-your-writes semantics. The catch: it only works inside Server Actions, not Route Handlers, which makes sense once you think of it as a mutation-specific tool rather than a general cache API.
• revalidateTag() — now takes a cache profile ('max', 'hours', 'days') as a required second argument, enabling stale-while-revalidate: visitors see the cached version immediately while the real data refreshes in the background.
• refresh() — updates uncached data without touching the cache at all. Built for things like a notification counter or an online-status indicator that should never be cached in the first place.

A mutation, three ways

Here's the same "publish a post" action written against each function, to make the difference concrete:

'use server'

import { updateTag, revalidateTag, refresh } from 'next/cache'

// 1. The author needs to see the published post immediately.
export async function publishPost(id: string) {
  await db.post.update({ where: { id }, data: { status: 'published' } })
  updateTag(`post:${id}`)
}

// 2. A background job bumped view counts — fine to go stale for a bit.
export async function recountViews(id: string) {
  await db.post.update({ where: { id }, data: { views: { increment: 1 } } })
  revalidateTag(`post:${id}`, 'hours')
}

// 3. Live notification badge — never meant to be cached.
export async function markNotificationRead(id: string) {
  await db.notification.update({ where: { id }, data: { read: true } })
  refresh()
}

Cache Components replace Partial Pre-Rendering

The other half of this release is the "use cache" directive, which takes over from Partial Pre-Rendering as the way you control what gets cached. Mark an async function or component with it and Next.js generates a cache key automatically:

async function PricingTable() {
  'use cache'

  const plans = await getPlans()
  return <PlansGrid plans={plans} />
}

The difference from PPR is explicitness. Instead of Next.js inferring what's static vs. dynamic from how you write the component, you say so directly — which pairs naturally with the three invalidation functions above: cache something with "use cache", then choose updateTag, revalidateTag, or refresh depending on how quickly it needs to reflect a mutation.

If you're upgrading

A straight 16.1 → 16.2 upgrade is non-breaking — npx @next/codemod@canary upgrade latest handles it. Coming from 15.x, budget time for three things: request APIs like cookies() and headers() are now fully async everywhere, middleware.ts has been renamed to proxy.ts, and any experimental_ppr config needs to move to the new cacheComponents model. None of these are exotic changes, but they touch enough of a typical App Router project that it's worth doing as its own PR rather than folding it into feature work.

The net effect of all of this is that cache invalidation in Next.js finally has names that match intent — immediate, background, or bypassed — instead of one function you reach for every time and hope behaves the way you need it to.