Next.js Application Serving Older Version After Successful Vercel Deployments

Help
,
1

Next.js Application Serving Older Version After Successful Vercel Deployments

I’m experiencing an issue where some users continue to see an older version of our Next.js application even after multiple successful production deployment.

I found a previous discussion about this issue, but the topic has been closed and the suggested solution references a Data Cache purge option that no longer appears to exist in the current Vercel UI.

Details:

  • Next.js application hosted on Vercel

  • Latest deployment is marked as Production

  • Deployment completes successfully with no errors

  • Issue affects the frontend application, not API responses

  • Some users continue to receive an older version of the application

Has the recommended troubleshooting process changed? Are there any known causes related to frontend asset caching, CDN caching, or client-side caching that could result in users receiving an older build after deployment?

Any guidance would be appreciated.

2

Hi Trylotsy,

I’d separate this into a few different “old version” cases, because they have different causes.

First, ask one affected user to open DevTools → Network and hard reload, then check the main document request for / or the affected route:

Status:
Cache-Control:
x-vercel-cache:
x-vercel-id:

If the HTML document itself is old, I’d check for something in front of Vercel, like Cloudflare, a corporate proxy, browser cache, or a service worker/PWA. A service worker is a common cause when only some users keep seeing an older frontend after a successful deployment.

If the HTML is new but the page still behaves like the old app, check which JS chunks are being loaded:

Network tab → filter "_next/static"

/_next/static/... assets are normally content-hashed and cached aggressively. That is expected. A new deployment should usually reference new chunk filenames from the new HTML. I would not try to manually purge /_next/static unless there is evidence the new HTML is still pointing at old chunk files.

The Data Cache is a different layer. It can explain stale fetched data or ISR/static page content, but it usually would not explain old client-side code or an old UI bundle by itself.

A few checks I’d run:

curl -I https://yourdomain.com/
curl -I https://yourdomain.com/?cache-bust=$(date +%s)

Then compare the response headers with what an affected user sees. If your curl gets the new deployment but the affected browser gets old HTML, I’d look at browser/service-worker/downstream cache. If both get old HTML, then check whether the production alias is actually pointing at the latest deployment.

Vercel’s CDN cache docs are useful for the static asset behavior:

One useful follow-up detail would be whether affected users see the new version after unregistering any service worker or opening the site in a private/incognito window.

3

Thanks for the response.

The challenge is that this is affecting a consumer-facing application with a large mobile user base, so it isn’t practical to walk individual users through DevTools checks, cache clearing, service worker inspection, or other device-specific troubleshooting steps.

What we’re seeing is inconsistent behavior across devices:

  • Some users see the latest version on desktop but not mobile.

  • Some see the latest version on mobile but not desktop.

  • Some see the latest version on both.

  • Some continue to see the old version on both.

Because the issue appears random across users and devices, I’m trying to determine whether there is a deployment-side solution that can prevent stale frontend builds from being served in the first place.

A few questions:

  1. Are there any known Vercel or Next.js deployment configurations that can cause older HTML documents to remain cached after a successful production deployment?

  2. Is there a recommended way to force all users onto the latest build without requiring manual intervention on their devices?

  3. If service workers are a common cause, what is the recommended strategy for ensuring outdated service workers are automatically replaced during deployment?

  4. Has Vercel replaced the old Data Cache purge workflow with another mechanism for clearing cached frontend content globally?

At this point I’m less interested in debugging individual devices and more interested in understanding whether there is a deployment-level fix or best practice that guarantees users receive the latest application version after a production release.