Caching issue with Next.js App Router - Vercel Deployment

I also use export const dynamicParams = false; in my page files.
But I guess, this makes sense as my pages only update when there is an update in the Prismic Repo - and if this is the case, it triggers a redeploy with a webhook.

If I understand it correctly, the dynamicParams setting only impacts routes and not content on those pages, and currently I have the issue that new routes and new contents (like a list of entities of a custom type) are missing out of builds.

dynamicParams = false is also included in the Page Snippet (in Slicemachine), so I guess this complies with the core Prismic concept?

Any idea on what the problem could be, @Pau or @angeloashmore?

I'm having the same issue here. I did the security token recommendation by @nathan and I don't understand what's going on.
I was seeing that issue and then changed the API access option to "open" and I was able to deploy successfully, however, if I make changes inside the primic interface such as changing text, it is not showing in my website as if I had a special cache configuration

1 Like

I reconfigured the webhook from vercel to prismic and it is now working as expected. So I guess that adding the accessToken and re-doing the webhook solved my problem. I hope that this can help you guys

1 Like

I've gone down a similar rabbit hole here, and found a decent solution with Vercel.

The new prismic/next/isr fetch() cache setup was working great; updates in Prismic were invalidaiting the Vercel correctly via the /api/revalidate call.

However, at build time I was getting "repo not found" errors from the prismic API. The build routine was trying to query an old cached master ref.

I found that because Vercel stores the whole .next build directory between builds, Next was using fetch responses from the previous build under ./next/cache/fetch-cache.

Nuke that directory before each build, and the latest Prismic master will be used. No need to mess with createClient() setup.

"scripts": {
    "build": "rm -rf .next/cache/fetch-cache && next build",

I hope this helps somebody out there! - Kyle


This was helpful. We had a similar situation. When there is multiple [:uid]/page.js files, e.g. /[:uid]/page.js and /some-path/[:uid]/page.js

It seems like subsequent createClient() calls trigger a not-found repo error. There very well be some kind of fetch cache on createClient() or client.getAllByType(...).

After adding Kyle's suggestion:

  • client.getByType('page')
  • client.getAllByType('page')
  • as well as creating a static array of uid's

All work as expected within generateStaticParams()

1 Like

Another option is to use the Environment Variable VERCEL_FORCE_NO_BUILD_CACHE with a value of 1. You can find limited info on that here. This has solved the issue for me on multiple projects.

Edit: After another day of dev the error RefExpiredError: The provided ref is no longer accessible, it has expired. has popped back up using the VERCEL_FORCE_NO_BUILD_CACHE option shared above. I'm going to give @kyle's suggestion a shoot, hopefully with better luck.

1 Like

Perhaps it would be helpful, if you could extend the Next.js / Deploy documentation with the most proven deployment methods (in addition to the blog post).
Especially for those who are new to Prismic and the App Router, it might be difficult to find the best way to deploy the projects.

I now use on-demand revalidation with a webook to /api/revalidate to reflect quick changes, but still trigger a rebuild of the application to rebuild my sitemap (app/sitemap.js) too.
If anyone has a better approach to that, please let me know. :slightly_smiling_face:

1 Like

It probably stems from the changes in fetch with next.js 13.x and the app router. All fetch requests get cached by default (it think).

Is there a specific strategy that Prismic has found helpful with their latest site release and updates now that their main site is Next.js? Maybe Prismic can chime in ;)

Hey @ryan,

You're absolutely correct that we rebuilt our main site with the Next.js App Router recently, but we're in the same boat as everyone else. We're trying to debug the issue with caching, but we haven't figured it out yet. We'll update this thread as soon as we have a solution or a temporary workaround.



Hey everyone,

We've opened an issue on the Next.js GitHub repository. Please feel free to upvote this issue and follow along for updates:



I am about to pass off the project to a client. Is there a reliable way to ensure their updates in Prismic get reflected on the frontend?

I am getting wildly inconsistent results with the revalidateTag webhook. Should I also trigger a build on the Vercel side after the revalidate endpoint is called?

Please help! and Thank you

Edit: I would like to add my changes (in even in Production) are reflected in Draft/Preview mode but not on the live site (after publishing).

1 Like

Hi @cires2023,

I'm not familiar with all of the rendering methods in Next 13, but maybe you could consider doing a full-site rebuild instead of ISR? It's not ideal, but I imagine it might be more fool-proof until these issues get ironed out.


I'm now also facing caching issues on Vercel in Next.js applications (v14.0.3) using the pages router.
Editing content in Prismic triggers a complete rebuild but the new contents are missing.

This also happens with the following suggested option:

Hey everyone,

The Next.js team has said that some of these issues might be fixed in their forthcoming 14.0.4 release. If you'd like, you can try installing the canary version to see if that helps:

npm install next@canary

Otherwise, you can wait until that version has been released and then upgrade.

If anyone tries this out, please let us know if it helps.


Hello everyone!

I wanted to join the conversation as I built the Prismic website using Next.js.

I've encountered similar issues as all of you have reported after migrating to app router. I've tried various solutions over the past few months.

However, since version 14.0.2, we haven't experienced any problems with revalidateTag() not revalidating.

The only unconventional setup we still have in place is VERCEL_FORCE_NO_BUILD_CACHE=1. As Nathan mentioned earlier, this is used to opt out of Vercel's build cache. We use it because when we trigger deploys from code changes in Git, we sometimes get outdated content if we've made content changes since the last build. It's not ideal since it doubles the build time, but now that revalidateTag() is working, our site doesn't need to rebuild as often.

Since version 14.0.4 has been released, it's possible that this issue has been fixed, as the update promises to resolve many caching issues. We're currently on the latest version, but we haven't had the chance to remove VERCEL_FORCE_NO_BUILD_CACHE=1 and test it yet.

Are any of you experiencing problems on version 14.0.4?


I have updated to version 14.0.4, and the cache issues have disappeared


That's wonderful news! Thank you for letting us know. :pray:

Did you disable the build cache with VERCEL_FORCE_NO_BUILD_CACHE=1 earlier because of deploying outdated caches? If so, have you attempted to remove it as well?



This is still not working in Next 14.0.4 for me. I have a simple Server Component page with export const revalidate = 120; And the data fails to refresh after build. I am seeing error logs with F [Error]: Ref not found. Ensure you have the correct ref and try again. Master ref is: ZXjLpxEAACIAKO1b
at N.fetch (/var/task/apps/web/.next/server/chunks/156.js:1:12940)...

1 Like