[Cache Components]Where is the static shell stored?

[AkifumiSato]

According to @gnoff's comment, at least on Vercel, “use cache” (i.e., cacheHandlers.default) does not actually cache anything.

The default cache handler on Vercel does not actually cache anything in process memory.

On the other hand, the static shell is also inherently static, but its persistence layer is not explicitly documented.

• Vercel
  • Where is the static shell stored?
  • How to revalidate the static shell?
• Self-hosting
  • Where is the static shell stored?
    • Is cacheHandlers.default used?
  • How to revalidate the static shell?

I want to understand the above points accurately and believe the documentation should be updated if necessary.

[0xpourya]

@AkifumiSato

On Vercel, cacheHandlers.default is effectively a no-op; it does not persist cached data in process memory.

The “static shell” of cached pages is stored by Next.js/Vercel as part of the build output (RSC payload + HTML) on disk/CDN, not in runtime RAM.

Revalidation of the static shell follows normal Next.js rules: use ISR or on-demand revalidate via revalidatePath/fetch tags when self-hosting.

When self-hosting, cacheHandlers.default is used, but it only keeps values in local process memory unless replaced with a custom adapter.

To control or revalidate the static shell, you must rely on Next.js revalidation mechanisms, not the default cache handler.

[leejpsd]

Good questions — the short version is that the static shell and 'use cache' entries live in two different cache layers, and cacheHandlers.default is the wrong layer to look at for the shell.

Where the shell lives (self-hosting):

• At build time it's literal files in .next/server/app: the HTML shell, the RSC payload (plus .segments/*.segment.rsc files), and — for partially prerendered routes — the serialized resume state (postponed) inside the .meta file. You can see this made explicit in the new adapter docs: build outputs expose prerenders[].fallback.filePath and prerenders[].fallback.postponedState (Output Types).
• At runtime, when the shell is regenerated (revalidation), it flows through the singular cacheHandler — the ISR/full-route layer — as an APP_PAGE entry carrying html, rscData, segmentData, and postponed. With no custom handler configured, that's the default file-system cache writing those same files back.

So for your self-hosting question: no, cacheHandlers.default is not involved. The plural cacheHandlers interface stores the results of 'use cache' functions/components — the inner building blocks — while the assembled shell for a route is an ISR-layer concern. If you're running multiple instances, it's the singular cacheHandler you need to make shared for the shell to be consistent across them.

How the shell revalidates (self-hosting): the normal ISR paths — time-based revalidate, or revalidateTag/revalidatePath. Tags reach the ISR layer attached to the page entry (they're carried in the entry's x-next-cache-tags header), so tag invalidation hits the shell exactly like any other full-route entry.

On Vercel: consistent with the @gnoff quote — cacheHandlers.default doesn't persist anything in-process there, and the shell is handled by the platform: shells are build outputs the deployment platform stores and serves (that's the model the adapter docs describe, including the resume protocol for streaming the dynamic holes after the shell — Implementing PPR in an Adapter). For exact storage details beyond that, only Vercel can answer.

Agreed the main docs could state the shell's persistence layer explicitly — right now the clearest documentation of it is, somewhat ironically, the adapter section rather than the caching guides.