On January 28, 2026, Vercel shipped tag-based cache invalidation for all CDN responses, on every plan, at no extra cost. You tag a response with a Vercel-Cache-Tag header and later evict every cached response that carried that tag, without touching a URL path or waiting on a redeploy. It is the surrogate-key model Fastly and Cloudflare have shipped for years, now reachable from outside the Next.js primitive that previously gated it.
What did Vercel actually ship?
Vercel’s CDN now reads a Vercel-Cache-Tag response header, indexes the tags it carries, and strips the header before delivering the response to the client, according to the January 28 changelog. The header takes a comma-separated list of tags. Once a response is tagged, it can be invalidated through dashboard settings, the Vercel CLI, a Function API call, or the REST API.
The framing is “group related content and invalidate it together, rather than just purging your entire cache,” available on all plans at no additional cost. Underneath, Vercel describes it as “the same underlying technology that powers Next.js Incremental Static Regeneration (ISR)” exposed to any framework or backend. That last clause is the actual news: before this ship, surrogate-key semantics at the CDN layer required Next.js revalidateTag or a hand-rolled key-versioning scheme. They are now a CDN header any framework can emit.
How does a tag purge actually execute?
Vercel exposes two distinct purge semantics, and the one you pick decides whether a stale response revalidates in the background or blocks the next reader. Per the CLI cache docs, vercel cache invalidate --tag X marks the matching content STALE, so the cached object still serves while it revalidates in the background. vercel cache dangerously-delete --tag X forces a MISS, so the next request has to revalidate synchronously and the client waits.
The --tag flag accepts a single tag or multiple comma-separated tags, and works with both subcommands. It is mutually exclusive with --srcimg, which covers source-image invalidation as a separate operation.
This STALE-versus-MISS split maps directly onto the soft-purge-versus-hard-purge split Fastly has shipped for years. Fastly’s purging reference drives soft purge through a Fastly-Soft-Purge: 1 request header, and supports it on single-object, surrogate-key, and bulk-surrogate-key purges, but not on purge-all. Vercel’s equivalent is two separate CLI verbs rather than one verb plus a header, which makes the cost model harder to hit by accident. The word “dangerously” in the subcommand is doing real work.
Whose model is Vercel copying?
The surrogate-key model Vercel now ships is the one Fastly pioneered and Cloudflare commoditized; Vercel is converging on a pattern that has been in production for the better part of a decade, not inventing one. Fastly was founded in 2011; surrogate-key purging predates the April 2017 launch of its edge cloud platform, which shipped alongside image optimization, load balancing, and a web application firewall. Per Fastly’s Surrogate-Key reference, individual keys are limited to 1,024 bytes and the full Surrogate-Key header to 16,384 bytes; if either limit is reached during parsing, the key currently being parsed and all keys following it within the same header are ignored.
Cloudflare’s surface is the comparable one. Per Cloudflare’s purge docs, Cache-Tag purging is available on every plan tier (Free, Pro, Business, and Enterprise), with a cap of 100 purge operations per request.
| Vendor | Header | Delimiter | Documented limit | Soft purge |
|---|---|---|---|---|
| Fastly | Surrogate-Key | space | 1,024 bytes/key, 16,384-byte header | Fastly-Soft-Purge: 1 header |
| Cloudflare | Cache-Tag | comma | 100 operations per purge request (all plans) | per-zone API |
| Vercel | Vercel-Cache-Tag | comma | not published in changelog or CLI docs | invalidate (STALE) vs dangerously-delete (MISS) |
Comparisons written before Vercel’s January 2026 ship necessarily predate the Vercel-Cache-Tag header. The changelog supersedes them. Any third-party guide that still describes Vercel as lacking native surrogate keys at the CDN layer is out of date.
Why does relationship-tagging beat path purging?
The point of surrogate keys is that invalidation flows from content relationships rather than URL globs. Change one product record and evict every page that referenced it, in a single purge call, without over-purging unrelated URLs or under-purging the ones you forgot to enumerate.
Concretely: a product record product-123 might surface on its detail page, on a category listing, in a search result, in a personal recommendation carousel, and in a homepage recently-viewed strip. Path-based invalidation forces you to enumerate every URL that rendered product-123, which means your cache layer needs to know your routing, which means it usually falls back to purging the whole catalog. Tag-based invalidation makes each of those responses carry product-123 at render time, then lets a single purge of that tag reach all of them.
The cost shift is structural. With path purging, the contract between the data layer and the cache is the URL, which the framework already owns. With surrogate keys, the contract is the tag vocabulary, which your application code now owns. You are trading a problem the framework solved for one your app has to solve.
Where does the complexity land?
It lands in your application code. Every response that should participate in a tag purge has to emit the right tags, and the code that mutates the underlying data has to purge the right tags. Both sides have to agree on the vocabulary, or you get silent over-serving that nobody notices until a customer files a bug.
This is the second-order cost the changelog does not price. Path purging made the URL the cache contract; surrogate keys make the tag string the cache contract, and tag strings are application state. A rename, a refactor, a CMS migration that changes how SKUs are formatted, a team that ships a new listing component and forgets to emit the product tag: each of those is now a stale-cache incident waiting to happen.
The mitigation is to treat tags the way you treat database columns, as code-owned, versioned state, with tests asserting which tags a given response carries. Tags derived from primary keys (product-{id}) survive refactors better than tags derived from presentation concerns (featured, hero-slot), because the former change when the data changes and the latter change when the marketing team redesigns the page.
What breaks when tags drift?
The new failure class is tag drift between the writer and the purger. The render path tags a response product-123; the mutation path purges products-123, plural, or with a different separator, or with a stale format from before the migration. Cached content then serves until a human notices, which on a low-traffic page can be weeks.
Two adjacent failure modes travel with this one. The first is the thundering herd: a dangerously-delete on a hot tag forces every concurrent request to revalidate synchronously, and a popular tag can stampede origin. The invalidate (STALE) path exists precisely to avoid this, and the Fastly soft-purge model exists for the same reason. The second is the propagation race: a purge issued at time T does not necessarily reach every edge node before a request already in flight reads the now-stale object, and the size of that window depends on propagation latency the docs do not publish.
Fastly markets an average regional mean purge time under 150 ms with Instant Purge, per its marketing site, but that is a Fastly figure, not a Vercel claim. Treating it as a proxy for Vercel’s propagation would transfer a number between vendors with different architectures. The Vercel-specific latency is [unverified] in the sources available here.
What does Vercel not document (yet)?
Before porting a Fastly-style tag budget onto Vercel, pin the numbers Vercel’s docs do not publish. The January 28 changelog and the CLI cache docs establish the header name, the two purge verbs, and the CLI flag semantics. They do not state a per-response tag cardinality cap, an individual tag length cap, or a purge propagation latency.
Fastly’s 1,024-byte-per-key and 16,384-byte-header limits and Cloudflare’s 100-operations-per-request cap are vendor-specific. They are useful as a sense of the order of magnitude the industry has converged on, but they are not Vercel’s limits, and the sources available here do not confirm Vercel equivalents. A team migrating a Fastly config that pushes against those caps should verify Vercel’s actual limits against a primary doc, or in its own load test, before assuming parity.
Frequently Asked Questions
Can a non-Next.js backend emit Vercel-Cache-Tag?
Yes, any origin that writes HTTP response headers (a Go service, a Rails controller, even a static asset served through the edge network) can tag, because the CDN reads the header before stripping it. Before January 28, 2026, the documented workaround was Next.js revalidateTag or appending a version token to cache keys so the old version aged out, a technique third-party edge guides still describe as if Vercel lacked surrogate keys entirely.
Which purge API fits a CMS-driven publish hook?
The REST API is the surface for external triggers such as a CMS webhook or a database post-save hook, where the caller is outside the Vercel request lifecycle. The Function API fits the opposite case, a purge issued from inside the request that performed the write, so the eviction happens before the response returns to the client.
How does Fastly’s bulk surrogate-key purge differ from Vercel’s —tag flag?
Fastly exposes bulk-surrogate-key purge as a distinct API operation that accepts many keys in one call and still honors the Fastly-Soft-Purge header, so a single request can soft-evict an entire content graph. Vercel collapses the same idea into one comma-separated list shared by both the invalidate and dangerously-delete verbs, with no published cap on how many tags a single CLI invocation can carry.
Is the cache-tag ship part of a broader 2026 Vercel push?
It lands inside a sustained Q2 2026 platform investment that included WebSocket Public Beta, CLI blob-URL signing, and zero-config Node servers in the June 22-23 changelog. Read against that cadence, the cache-tag feature is one of several edge primitives Vercel is promoting from Next.js-only into framework-agnostic availability, which suggests revalidatePath-style path invalidation may follow the same route.
