static//edge

Documentation

Static Edge

An edge caching layer for static assets and read-heavy API responses. This site documents cache lifetimes, revalidation behaviour, cache keys and the invalidation API exposed to accounts on static-edge-cdn.xyz.

01How the cache works

Every request arrives at the edge node closest to the client. The node builds a cache key from the request method, host, path, the normalised query string and any headers listed in the response Vary directive. If a fresh object exists for that key, it is served without contacting the origin.

If no object exists, the node fetches from the origin, stores the response according to its caching headers, and serves it. Concurrent requests for the same key are collapsed into a single origin fetch, so a cold key never produces a stampede.

Response headers added by the edge

x-se-cache: HIT
x-se-pop:   fra1
x-se-key:   9d1f0c4a2b7e
age:        412
cache-control: public, max-age=600, stale-while-revalidate=60

The x-se-cache header reports one of four states:

ValueMeaning
HITServed from the edge; the origin was not contacted.
MISSNo stored object; the response was fetched and stored.
STALEExpired object served while revalidation runs in the background.
BYPASSThe response was not cacheable, or a rule excluded it.

02Cache lifetimes

Freshness is decided by the origin. The edge honours standard HTTP caching semantics and resolves the effective TTL in this order:

  1. A matching path rule in the account configuration (highest precedence).
  2. s-maxage in the response Cache-Control header.
  3. max-age in the response Cache-Control header.
  4. The Expires header, if no directive above is present.
  5. The account default TTL, applied only to responses with no caching headers at all.

Responses carrying no-store, private, or a Set-Cookie header are never stored. Responses to POST, PUT, PATCH and DELETE are always passed to the origin unchanged.

Stale content is a feature. Pair a short max-age with stale-while-revalidate so visitors get an instant response while the edge refreshes the object in the background, and with stale-if-error so an origin outage does not become a visitor-facing outage.

03Invalidation

Three mechanisms remove content from the edge before it expires:

Purges propagate to all nodes within a few seconds and are idempotent. Full request and response examples are on the configuration page.

04Service endpoints

Last reviewed: 12 August 2026 · Edge software 3.4