Every developer has had that one bug that seems insignificant but is capable of breaking an entire build process. For me, it was a simple `cache: "no-store"` setting in a fetch request. It worked perfectly in Dev dev server but caused a failed build when deploying on Cloudflare Pages. Here's what happened and what I learned about cache revalidation in Next.js.
My portfolio website, built with Next.js and Sanity CMS, was running smoothly on my local machine. But as soon as I deployed to Cloudflare Pages, I got this error:
"The following routes were not configured to run with the Edge Runtime…"
This didn’t make sense initially to me because My /blog and /index pages were static yet Cloudflare thought they were dynamic. I checked my Next.js setup, everything seemed fine.
After few minutes of debugging, I found the culprit: fetch("https://myapi.com/data", { cache: "no-store" });
This little line was forcing Next.js to treat the page as dynamic making it incompatible with Cloudflare’s static deployment model.
Here’s why:
- cache: "no-store" tells Next.js to always fetch fresh data on every request, which automatically switches the page to SSR mode
I removed cache: "no-store" and switched to revalidating at intervals using revalidate: const res = await fetch("https://myapi.com/data", { next: { revalidate: 60 } });
This allowed my pages to stay static while still fetching fresh data every 60 seconds. The build passed successfully!
Lessons (The Takeaway)
- Always use Incremental static regeneration where applicable, It gives you the speed of static pages while allowing updates without rebuilding everything
- Understand how Next.js treats different fetch behaviors –
cache: "no-store"is great for SSR but breaks static exports. - Dev mode is forgiving, production is not. Always test with `next export` before deploying.
- Revalidate instead of SSR when possible – This keeps pages static while allowing periodic updates.