use cache: remote
Learn how to use the `"use cache: remote"` directive to enable caching in dynamic contexts in your Next.js application.
The 'use cache: remote' directive enables caching of shared data in dynamic contexts where regular use cache would not work, for example after calling await connection(), await cookies() or await headers().
Good to know:
- Results are stored in server-side cache handlers and shared across all users.
- For user-specific data that depends on
await cookies()orawait headers(), use'use cache: private'instead.
Usage
To use 'use cache: remote', enable the cacheComponents flag in your next.config.ts file:
Then add 'use cache: remote' to your function that needs to cache data in a dynamic context.
Basic example
Cache product pricing that needs to be fetched at request time but can be shared across all users. Use cacheLife to set the cache lifetime of the price.
Note: Regular use cache will not cache anything when used in a dynamic context (after await connection(), await cookies(), await headers(), etc.). Use 'use cache: remote' to enable runtime caching in these scenarios.
How use cache: remote differs from use cache and use cache: private
Next.js provides three caching directives, each designed for different use cases:
| Feature | use cache | 'use cache: remote' | 'use cache: private' |
|---|---|---|---|
| Works in dynamic context | No (requires static context) | Yes (designed for dynamic contexts) | Yes |
Access to await cookies() | No | No | Yes |
Access to await headers() | No | No | Yes |
After await connection() | No (won't cache) | No | No |
| Stored in cache handler | Yes (server-side) | Yes (server-side) | No (client-side only) |
| Cache scope | Global (shared) | Global (shared) | Per-user (isolated) |
| Supports runtime prefetching | N/A (pre-rendered at build) | No | Yes (when configured) |
| Use case | Static, shared content (build-time) | Dynamic, shared content in runtime contexts (per-request) | Personalized, user-specific content |
Note: While you can't call await cookies() or await headers() inside 'use cache: remote', you can read the values before calling a function that is wrapped by 'use cache: remote' and the arguments will be included in the cache key. Note that this is not recommended as it will dramatically increase the cache size and reduce the cache hit rate.
When to use each directive
Choose the right caching directive based on your use case:
Use use cache when:
- Content can be prerendered at build time
- Content is shared across all users
- Content doesn't depend on request-specific data
Use 'use cache: remote' when:
- You need caching within dynamic context
- Content is shared across users but must be rendered per-request (after
await connection()) - You want to cache expensive operations in a server-side cache handler
Use 'use cache: private' when:
- Content is personalized per-user (depends on cookies, headers)
- You need runtime prefetching of user-specific content
- Content should never be shared between users
How it works
The 'use cache: remote' directive enables runtime caching of shared data in dynamic contexts by storing results in server-side cache handlers rather than prerendering at build time.
Dynamic context detection
When Next.js encounters certain APIs like connection(), cookies(), or headers(), the context becomes "dynamic". In a dynamic context:
- Regular
use cachestops working - it won't cache anything 'use cache: remote'continues to work - it is cached by a remote cache handler.- Results are stored server-side in a key-value store configured for your deployment
- Cached data is shared across requests - reducing database load and origin requests
Good to know: Without 'use cache: remote', functions in dynamic contexts would execute on every request, potentially creating performance bottlenecks. Remote caching eliminates this issue by storing results in server-side cache handlers.
Storage behavior
Remote caches are persisted using server-side cache handlers, which may include:
- Distributed key-value stores (in-memory or persistent storage solutions)
- File system or in-memory storage (often used in development or for custom deployments)
- Environment-specific caches (provided by your hosting infrastructure)
- Custom or configured cache handlers (depending on your application's setup)
This means:
- Cached data is shared across all users and requests
- Cache entries persist beyond a single session
- Cache invalidation works via
cacheTagandrevalidateTag - Cache expiration is controlled by
cacheLifeconfiguration
Dynamic context example
Request APIs and remote caches
While 'use cache: remote' technically allows access to request-specific data by calling API's like cookies() and headers() before calling a function that is wrapped by 'use cache: remote', it's generally not recommended to use them together:
| API | Allowed in use cache | Allowed in 'use cache: remote' | Recommended |
|---|---|---|---|
cookies() | No | No | Use 'use cache: private' instead |
headers() | No | No | Use 'use cache: private' instead |
connection() | No | No | No - these cannot ever be cached |
searchParams | No | No | Use 'use cache: private' instead |
Important: If you need to cache based on cookies, headers, or search params, use 'use cache: private' instead. Remote caches are shared across all users, so caching user-specific data in them can lead to incorrect results being served to different users.
Nesting rules
Remote caches have specific nesting rules:
- Remote caches can be nested inside other remote caches (
'use cache: remote') - Remote caches can be nested inside regular caches (
'use cache') - Remote caches cannot be nested inside private caches (
'use cache: private') - Private caches cannot be nested inside remote caches
Examples
The following examples demonstrate common patterns for using 'use cache: remote'. For details about cacheLife parameters (stale, revalidate, expire), see the cacheLife API reference.
Per-request database queries
Cache expensive database queries that are accessed in dynamic contexts, reducing load on your database:
API responses in streaming contexts
Cache API responses that are fetched during streaming or after dynamic operations:
Computed data after dynamic checks
Cache expensive computations that occur after dynamic security or feature checks:
Mixed caching strategies
Combine static, remote, and private caching for optimal performance:
Good to know:
- Remote caches are stored in server-side cache handlers and shared across all users
- Remote caches work in dynamic contexts where regular
use cachewould fail - Use
cacheTag()andrevalidateTag()to invalidate remote caches on-demand - Use
cacheLife()to configure cache expiration - For user-specific data, use
'use cache: private'instead of'use cache: remote' - Remote caches reduce origin load by storing computed or fetched data server-side
Platform Support
| Deployment Option | Supported |
|---|---|
| Node.js server | Yes |
| Docker container | Yes |
| Static export | No |
| Adapters | Yes |
Version History
| Version | Changes |
|---|---|
v16.0.0 | "use cache: remote" is enabled with the Cache Components feature. |