Skip to main content

Server cache storage

The production server keeps Next.js incremental fetch and ISR cache entries in its existing, bounded 50 MiB memory cache. experimental.isrFlushToDisk: false prevents these runtime entries from accumulating in the container's writable filesystem. This covers CMS configuration, content and other cached fetches. It preserves request cache keys, revalidation and bounded bootstrap reuse. It does not make the entire Node process fit in 50 MiB: Next accounts for cache payloads, and application objects and other caches use additional memory.

The setting also stops regenerated ISR pages being persisted. Build-time pages remain readable. Entries can be evicted under the memory budget and refetched; there is no disk fallback for evicted fetch responses. Pods retain independent caches, as before.

In the installed Next.js 16.3.4 runtime, this setting also disables the default image optimizer disk cache. Record currently has no next/image usage in its application source. If image optimization is introduced, reassess its caching requirements; the 50 MiB incremental cache budget does not replace that cache.

Run pnpm test:server-cache to qualify this policy against the installed Next.js version. The tests use the production server cache factory, verify memory reuse and eviction, context isolation, revalidation, legacy fetch-file rejection and prerendered page reads. The configuration is experimental, so this check must remain in CI when upgrading Next.js.

Activation and verification​

  1. Build and deploy a new image through the normal release workflow. Changing configuration without rebuilding the standalone image is insufficient.
  2. Replace old pods normally; do not delete cache files from serving pods. Old writable-layer files disappear when those pods and containers are removed.
  3. During a representative nonproduction soak, check that .next/cache/fetch-cache does not grow as distinct visitors browse config and content. Include repeated requests and more distinct keys than fit in memory.
  4. Verify session, locale, region and Kids profile isolation, public pages, protected redirects and revalidation. Compare CMS request volume, latency, process memory and CPU against the release baseline. Removal of disk reuse may increase misses; this change does not promise a NAT cost reduction.
  5. After authorized production promotion, monitor the same metrics and node disk pressure. Select ephemeral-storage requests/limits and node disk headroom with DevOps using measured remaining storage needs. These are additional containment measures, not replacements for preventing cache growth.

A rollback to an image with disk persistence enabled reintroduces the growth path. Neither rollout nor rollback repairs unrelated playback network errors.