Production domain keeps serving stale deployment after redeploys, purges, alias resets

Help
1

My production domain has been serving an old, stale JS bundle for over an hour, despite many fresh production deployments completing successfully.

Steps already tried, all reporting success but not fixing the issue:

  • Multiple vercel deploy --prod --yes --force redeploys, each producing a new bundle hash, status “Ready”
  • vercel alias set [deployment-url] [domain] — succeeded, dashboard confirms correct deployment aliased
  • vercel cache purge --type cdn --yes — succeeded (“Successfully purged the CDN cache”)
  • Cloudflare cache purge (“Purge Everything”) on the domain’s DNS proxy layer
  • Deleted several old stale deployments via vercel rm
  • Waited 15+ minutes between attempts, tested across multiple browsers

The dashboard’s “Production Deployment” always shows the correct latest commit, yet curl-ing the live domain keeps returning different, older bundle hashes over time — sometimes matching a deploy from hours earlier, never the current one. x-vercel-cache: HIT with a high age value appears even right after a fresh deploy.

This matches a previously reported thread here: “Production Edge Cache NOT Purging.”

Any guidance appreciated — happy to share more diagnostic output (without identifying details).

2

Hi Alaa,

I’d separate the stale HTML document from stale /_next/static/... assets first.

For a Next.js app, old hashed JS/CSS files being cached with x-vercel-cache: HIT can be normal. The real problem is if the live domain’s HTML is still referencing old chunk hashes after the production alias points to the new deployment.

I’d compare the deployment URL and the production domain directly:

curl -sL https://your-new-deployment-url.vercel.app | grep -o '/_next/static/[^"]*' | head -20
curl -sL https://your-production-domain.com | grep -o '/_next/static/[^"]*' | head -20

curl -I https://your-production-domain.com
curl -I https://your-new-deployment-url.vercel.app

If the deployment URL shows the new chunk hashes but the production domain shows old ones, then the build artifact is fine and the issue is in the domain/proxy/cache layer.

Since Cloudflare is also in front, I’d temporarily bypass that as an isolation test: either pause/disable the proxy for the hostname or create a temporary DNS-only subdomain pointing to Vercel. If the DNS-only hostname shows the new deployment immediately, then Cloudflare is still caching or routing the old HTML even if the Vercel deployment/alias is correct.

I’d also check for any custom headers that accidentally cache HTML or route responses too long:

next.config.js headers()
vercel.json headers
middleware
route handlers
Cloudflare cache/page rules

Especially look for Cache-Control, CDN-Cache-Control, or Vercel-CDN-Cache-Control on page routes. Those are useful for APIs/static responses, but they can make debugging deploy rollouts confusing if applied broadly.

Vercel’s CDN cache docs are useful for checking the headers involved:

If the production domain and deployment URL return different HTML after Cloudflare is bypassed, the next useful details would be the curl -I output for both URLs and the exact deployment URL currently assigned to the production domain.