Capa
Contact salesGet started

ProductsFor your stack

Edge Cache

Served from the edge. Fresh the moment you publish.

Published content is served from the nearest of Fastly's edge locations, typically in 20 to 50 ms. When you publish, it clears only the responses that changed, keeps serving the last copy while the edge refreshes, and your page is live in two to three seconds. No rebuilds, no revalidate timers.

Start freeHow caching works
cdn.capacms.com2.4 s
Capa
MenusAutumn menuPublished v8Published
OriginIdle
Edge cache
  • /api/entries/menus/…0021m:menus e:…0021v8
  • /api/entries/menus?sort=titlem:menus e:…0021 e:…0022v8
  • /api/entries/articles?limit=10m:articles e:…002ecached
  • /api/graphql?…BlogIndexm:articles m:authorscached
  • /api/entries/pages/…0007m:pages e:…0007cached
  • /files/brand/hero.jpg?width=800f:…00c4cached
Requests
  1. GET /menuHIT · 27 ms
  2. Publish “Autumn menu”v8
  3. Soft purge m:menus e:…00212 of 6
  4. GET /menuHIT · stale · 24 ms
  5. GET /menuHIT · v8 · 22 ms
  6. Live everywhere2.4 s
On publish

Press Publish. Nobody waits.

What happens in the two to three seconds between your click and a fresh page on every edge.

  1. 01

    A new version

    Capa saves the version you published and points the entry at it. Drafts never reach the cache, so saving one changes nothing a visitor sees.

  2. 02

    Purge only what changed

    Every cached response carries surrogate keys for the entries and models in it. Capa purges the entry's key and its model's key. Everything else stays warm.

  3. 03

    Serve while it refreshes

    The purge is soft. The next reader gets the previous copy at once while the edge fetches the new one behind them.

  4. 04

    Live everywhere

    Two to three seconds after you press Publish, every edge serves the new version. Unpublish and delete purge hard, so a takedown is immediate.

In the headers

Nothing magic. Just good headers.

Every production response says how long it lives, what it may serve while it refreshes, and which keys purge it.

  • Keys for every entry and model

    Surrogate-Key lists the project, the key, every model and every entry in the response. A publish finds every response that showed the entry, lists included.

  • Stale while revalidating

    The edge can keep serving a response for a day while it fetches a fresh one, so a refresh never puts a visitor behind a slow request.

  • Stale if the origin stumbles

    If the origin errors, the edge keeps answering with the last good copy for up to a week.

  • ETags for free

    Send the ETag back as If-None-Match and an unchanged answer is a 304 with no body.

GET /api/graphql?…
HTTP/1.1 200 OK
cache-control: public, max-age=60
surrogate-control: max-age=60, stale-while-revalidate=86400, stale-if-error=604800
surrogate-key: t:… c:…:1 k:… m:… e:…002e e:…002c
etag: "ec0d0bb2483b4f758082c5078cc60420"
capa-version: 2026-10-01
vary: Origin, x-api-key, Capa-Version, Capa-Contract
Instead of ISR

Retire the revalidate timer. Keep the speed.

Static rebuilds and incremental regeneration exist because CMS reads were slow. With published content already at the edge, the page can simply ask.

Rebuilds and timersCapa Edge Cache
Publish to liveA rebuild, or whenever the revalidate window runs outTwo to three seconds, measured
What refreshesThe whole site, or the pages you remembered to tagOnly the responses that held the entry or its model
The next readerCan wait on a build or a fresh renderGets the previous copy instantly while the edge refreshes
What you maintainRevalidate times, cache tags and a webhook routeNothing. Read from cdn.capacms.com
The numbers

Fast from the nearest edge.

  • 20 to 50 msA typical cached read, nearest edge
  • 2 to 3 sFrom Publish to live, measured
  • 1 yearAt the edge for every image size
  • 7 daysOf last good copy if the origin errors

Publish to live measured at 2.3 to 2.6 seconds on 1 October 2026.

Also in the cache

Details that keep every page warm.

  • Pro and up

    Rewarm

    Capa fetches purged and soon-to-expire responses again before a visitor asks, so even the first reader after a publish gets a warm answer.

  • Drafts

    Drafts stay out of the cache

    A development key reads drafts, and its responses are sent with no-store, so the edge never keeps them.

  • Keys

    Revoking a key purges it

    Rotate, narrow or deactivate a key and everything it could read leaves the edge with it.

  • Takedowns

    Gone means gone

    Unpublish or delete an entry and its responses drop at once. Its 404 is cached too, until a publish brings it back.

  • Your CDN

    Tags for your own cache

    The SDK hands you each response's surrogate keys, and revalidateFromWebhook refreshes the right Next.js tags on publish.

  • Admin

    See it and purge it

    Developers > Cache shows what is cached and lets a developer purge by hand when they need to.

Works with

Fast at the edge. Fresh after every publish.

Point your reads at cdn.capacms.com and delete your revalidate timers.

Start freeHow caching works