How can I share my Vercel cache across deployments?

When fetching data from external sources like a database or CMS, it can be beneficial to prevent re-fetching the same data if it has not changed by utilizing caching. This guide will explain how to use the Next.js App Router and the Vercel Data Cache to persist cached data across deployments.

Requirements

To cache data and share responses across deployments, you must currently use the Next.js App Router (latest version recommended). You cannot share the cache between different projects.

Next.js App Router

The Next.js App Router (app/) provides more fine-grained control over fetching, caching, and revalidating your data. For example, you can fetch and cache data (using fetch or your favorite library) and revalidate the data by cache tag or path by defining a stale time or programmatically purging the cache.

Vercel Data Cache

The Vercel Data Cache is a specialized, granular cache for storing responses from fetches while using modern frontend frameworks like Next.js. It's a shared cache, meaning users of the same project share the same cache.

Frameworks that integrate with the Data Cache (currently Next.js) can cache data per fetch instead of per route. This means you can have static, dynamic, and revalidated data together in the same route.

Example

Inside your Next.js application, fetch and tag your data with a cache key:

async function Blog() {
  const res = await fetch('https://api.vercel.app/blog', {
    next: { tags: ['blogs'] }
  });
  const blogs = await res.json();
 
  return '...';
}

The response from fetch will be cached and not re-fetched on the next deployment. Instead, to revalidate the data and purge the cache, you can use revalidateTag:

'use server'
 
import { revalidateTag } from 'next/cache'
 
export default async function action() {
  revalidateTag('blogs')
}

Frequently Asked Questions

Differences with build caching

Caching data from your database, CMS, or other external location is different than caching artifacts during the build process.

Vercel's build cache will prevent re-downloading dependencies (node_modules), monorepo cache artifacts (remote cache), and framework-specific files.

Learn more about builds on Vercel.

Differences with Edge Network caching

Static assets like images, fonts, and JavaScript files can be cached in Vercel's Edge Network regions from the deployment outputs created after a build. These files, typically generated by your framework, usually contain a hash in the filename.

The filename hash enables the ability to safely add immutable caching headers since we are guaranteed that a new version of the file will be generated by the framework if something changes. This also means these cached files will persist across deployments.

Learn more about Edge Network caching.

Differences with Incremental Static Regeneration

When a page contains entirely static data, Vercel will use Incremental Static Regeneration (ISR) to generate the whole page. However, when a page contains a mix of static and dynamic data, the dynamic data needs to be re-fetched when rendering the page. In this scenario, the Vercel Data Cache is used to cache the static data to avoid slow origin fetches.

Both ISR and Vercel Data Cache support time-based revalidation, on-demand revalidation, and tag-based revalidation.

Learn more about ISR on Vercel.