Runtime cache is a regional, ephemeral cache you can use for storing and retrieving data across Vercel Functions, Routing middleware, and build execution within a Vercel region. It lets you cache data close to where your code runs, reduce duplicate work, and control invalidation with TTLs and tags.

• Find out how runtime cache works
• When to use it
• Get started with the framework-specific examples

Runtime cache is best when your functions fetch the same data multiple times or perform expensive computations that can be reused, such as in the following scenarios:

• API calls that return the same data across multiple requests
• Database queries that don't change frequently
• Expensive computations you want to reuse
• Data fetching in server components or API routes

Runtime cache is not a good fit for:

• User-specific data that differs for each request
• Data that must be fresh on every request
• Complete HTTP responses (use CDN cache instead)

Runtime cache stores data in a non-durable cache close to where your function executes. Each region where your function runs has its own cache, allowing reads and writes to happen in the same region for low latency. It has the following characteristics:

• Regional: Each region has its own cache
• Isolated: Runtime cache is isolated per Vercel project and deployment environment (preview and production)
• Persistent across deployments: Cached data persists across deployments and can be invalidated through time-based expiration or by calling expireTag
• Ephemeral: Each project has a storage limit. When your project reaches this limit, Vercel evicts (removes) the entries that haven't been accessed recently to free up space for new entries
• Automatic: When runtime cache is enabled, Vercel handles caching for you
• Framework-agnostic: Works with all frameworks

The cache sits between your function and your data source, reducing the need to repeatedly fetch the same data. See limits and usage for information on item size, tags per item, and maximum tag length.

You can cache your Vercel function with any framework by using the functions of the helper method getCache.

This example caches data fetched from the API so that it expires after 1 hour and adds a tag to the cache entry so you can invalidate it later from code:

With Next.js, you can use runtime cache or data cache in the following ways:

With Next.js 16, you have two options for runtime caching:

• use cache: remote: A directive that caches entire functions or components with Runtime cache. Requires enabling cacheComponents in your config.
• fetch with force-cache: Caches individual fetch requests without additional configuration with Data cache.

Use the use cache: remote directive at the file, component, or function level to cache the output of a function or component.

First, enable the cacheComponents flag in your next.config.ts file:

Then, use the use cache: remote directive in your code. This example caches data so that it expires after 1 hour and adds a tag to the cache entry so you can invalidate it later from code:

You can also use runtime cache in API routes:

If you don't enable cacheComponents, you can use fetch with cache: 'force-cache' to cache individual fetch requests:

In Next.js 15, use the fetch() API with cache: 'force-cache' or unstable_cache for runtime caching with Data cache.

Use cache: 'force-cache' to persist data in the cache:

For time-based revalidation, combine cache: 'force-cache' with the next.revalidate option:

For tag-based revalidation, combine cache: 'force-cache' with the next.tags option:

Then invalidate the cache using revalidateTag:

For non-fetch data sources, use unstable_cache:

If you're using Next.js 14 or below, see Data Cache for the legacy caching approach or use the framework-agnostic getCache function.

You can control how long data stays cached using the following revalidation options:

This example revalidates the cache every hour:

This example associates the products tag with the data:

You can then revalidate the cache for any data associated with the products tag by using the revalidateTag function. For example, use a server action:

This example revalidates the cache for the /products path using a server action:

Runtime cache can work alongside CDN caching in two ways:

1. With Vercel ISR: Vercel handles CDN caching for your pages and routes, while runtime cache stores the data fetches within your functions
2. With manual CDN caching (shown below): You set Cache-Control headers to cache HTTP responses at the CDN, while runtime cache stores data fetches within your functions

This section covers the manual approach. If you're using Vercel ISR, runtime cache operates independently as described in limits and usage.

When you've set up runtime cache with a serverless function and manual CDN caching, the following happens:

1. Your function runs and checks the runtime cache in the region where it is executed for data
2. If that region's runtime cache has the data, it returns the data immediately
3. If not, your function fetches the data from origin and stores it in that region's runtime cache
4. Your function generates a response using the data
5. If you configured CDN cache via Cache-Control headers, it will cache the complete response in Vercel regions

This example uses runtime cache to fetch and cache product data, and CDN cache to cache the complete API response:

In this example:

• Runtime cache stores product data in the region for 1 hour (3600 seconds)
• CDN cache stores the complete HTTP response in the regional cache for 60 seconds
• If the CDN cache expires, the function runs but can still use runtime-cached data
• If both caches expire, the function fetches fresh data from the origin

You can observe your project's Runtime cache usage in the Runtime Cache section of the Observability section in the sidebar under your project in the Vercel dashboard.

The Runtime Cache section provides graphs for:

• Cache reads and writes
• Cache hit rate
• On-demand revalidations

You can also see a tabular list of runtime cache tags used in your project with cache reads, writes, hit rate, and revalidation times.

Runtime cache operates independently from Incremental Static Regeneration. If you use both caching layers, manage them separately using their respective invalidation methods or use the same cache tag for both to manage them together.

Each project has a fixed storage limit. When your project reaches this limit, Vercel uses a least recently used (LRU) eviction policy: it removes the entries that haven't been accessed recently first. You can monitor your cache size and eviction activity in the Runtime Cache section of the Observability tab.

Usage of runtime cache is charged. Learn more about pricing.