Several Next.js instances can serve different cached results unless the deployment coordinates their cache and revalidation behavior. A local disk cache is not automatically shared across servers.
IN THIS ARTICLE
01 What you need before you begin
Identify the caching features used by the installed Next.js version, the number of instances and whether local storage persists. Separate application caching from a CDN or proxy cache.
02 Preserve Next.js cache consistency across instances
Deploy the same reviewed build to instances that serve the same release. Record the build and deployment identifiers.
Choose the cache handler mechanism appropriate for the application’s actual features and Next.js version. Different cache APIs may require different handler configuration.
Use suitable durable shared storage and coordinate invalidation where consistency is required. Isolate environments and applications with appropriate namespaces.
Configure the proxy or CDN to respect response cache directives and request variants. Do not cache personalised responses as public content.
Test an update and revalidation while requests reach different instances. Include a rolling deployment and an already-open browser session.
03 Confirm the expected result
Confirm users see the intended refreshed data across instances and that private content never crosses between users. Observe cache storage errors and stale responses.
04 Troubleshoot unexpected results
If a clear fixes only one server, the invalidation may be local. Review the shared handler and tag or path coordination instead of repeatedly restarting every instance.
05 A common question
Can I use the example in-memory map as a shared cache?
An in-process map is local to that process. Production shared caching requires an actual shared backend and appropriate handling for expiry, errors and concurrent updates.
06 Example: investigate different content across application instances
If two requests show different versions of a page, first confirm that every instance runs the same release. Record the build identifier and deployment time for each instance before changing cache behaviour.
Next, distinguish browser caching, CDN caching and the application's own cache. Test a controlled page through the public route and inspect relevant response headers. A cached response at one layer can hide a newly deployed response at another.
What should I plan when scaling to several instances?
Review the framework's current self-hosting guidance for shared caches and invalidation. Choose an arrangement supported by the exact application version and deployment model. Do not assume that copying a cache directory between running instances is a complete consistency strategy.
Use a staging test that updates content and verifies the expected result through more than one instance. Include authentication and pages with user-specific content so private responses are not incorrectly shared. Contact us with the release details, route and observed headers when you need help identifying the hosting or proxy layer. Remove session cookies and authorisation tokens from diagnostic captures.