Cache-Control headers are not being set in the Vercel deployment

[abhishekmardiya]

I’ve set Cache-Control headers in next.config.ts like this:

async headers() {
  return [
    {
      source: "/:path",
      headers: [
        {
          key: "Cache-Control",
          value: "public, max-age=300, s-maxage=300, stale-while-revalidate=300",
        },
      ],
    },
  ];
}

When I run next build locally, the header is visible. However, after deploying to Vercel, the header does not appear.

Here are the GitHub repository and deployment links for reference:

GitHub: https://github.com/abhishekmardiya/nextjs-cdn-cache
Deployment: https://nextjs-cdn-cache.vercel.app/test

I’m currently testing this on the Vercel free tier.

[icyJoseph]

I am a little rusty on this area right now, but IIRC, since your page is a [slug] dynamic, with no build-time params, no revalidate, nor that combo of force-static a dynamic params situation, then the CDN strips Cache-Control, header to force the browser to fetch (it is the case usually that the .html entry point is not cached either - in some cases anyway, but the assets these load, so that if the hashes change, new scripts, styles, etc are fetched, but if they are the same, the browser likely already has them cached)

This is one of those cases where self-hosting works the expected way, cuz no vendor-lock in, you are in full control, but if you do deploy in a vendor, you give up some control, in exchange for the optimizations they put in place to make your app work correctly and efficiently.

I think you can go here, https://vercel.com/docs/headers/cache-control-headers and get the Ask AI bot, to explain some of these a lot better than I can here.

[abhishekmardiya]

Before opening this discussion, I tried the Vercel Docs AI bot, but it hallucinated quite a bit. After digging further myself, I found the following explanation:

When a page is dynamically rendered, it executes as a Vercel Function. In this scenario, the Function’s response headers take precedence over any headers defined in next.config.ts. Because Vercel Functions have higher priority, headers configured at the framework level are effectively ignored for dynamic routes.

This also aligns with your point about vendor lock-in:

Self-hosting behaves as expected because there’s no vendor lock-in and you retain full control. However, when deploying to a vendor platform, platform-specific behavior applies.

In other words, this isn’t a Next.js limitation—it’s a Vercel platform–specific behavior, where the runtime overrides framework-level header configuration for dynamic routes.

So if we want reliable control over cache behavior, we should rely on Next.js–provided mechanisms (SSG, ISR, fetch caching, route segment config, etc.) instead of manually setting Cache-Control headers, since those headers ignored once the route is executed as a Vercel Function.

[icyJoseph]

Mmm what I meant with vendor lock-in there I more in the sense that, when you deploy a project into a hosting service, there's gonna be some control you give necessarily - as in compared to setting up your own server on premise and launching from there, which is I guess where you truly control most things. Next.js is made to work in any hosting environment. In this case you observed some behavior on self hosting (next start), which differed from the deployment, that's a question then to the hosting provider.