On one next start instance with persistent local disk, the default Next.js cache persists naturally. Ephemeral containers lose local cache on replacement. Multiple instances each have separate caches unless you configure shared storage and coordinated invalidation.
Match storage to topology
For a single server, preserve the relevant .next cache path across application restarts while replacing immutable build assets by release. In containers, mount only the runtime cache path if persistence is desired; never share an entire mutable build directory across different releases.
For multiple instances, configure a production cache handler backed by durable shared storage and disable conflicting local memory behavior where required by the current API.
Coordinate tags and builds
All instances must run the same build. Multi-instance deployments also need consistent Server Function encryption, a deployment identifier for version-skew protection, shared cache behavior, and tag synchronization. A revalidateTag call received by one instance must not leave peers serving stale content.
Prove revalidation
Run production mode and inspect x-nextjs-cache values. Test time-based and on-demand revalidation, restart the process, replace a container, deploy a new build, and remove the cache backend temporarily. Define whether failure serves stale content, bypasses cache, or fails closed.