Content delivery (CDN)

How the revenexx edge serves your storefront and your Storage assets from a point of presence close to your users, under your own domain.

revenexx runs its own delivery edge — four points of presence in front of a single origin in Germany. No third-party CDN is in the path.

The edge fronts domains you point at it. Once shop.example.com CNAMEs to the edge hostname, the nearest point of presence answers every request for that host: it terminates TLS, filters the request, serves what it has cached, and forwards the rest to the origin.

That is the whole setup. There is nothing to provision, no cache to warm, and no configuration beyond the one DNS record — see Domains.

What the edge does for your domain

  • Terminates TLS close to the client, with a certificate issued and renewed for you. See TLS.
  • Filters the request through managed WAF rules and rate limiting before anything reaches the origin. See WAF.
  • Serves cacheable responses from the PoP, without a round trip to Germany.
  • Compresses text responses with Brotli or Gzip, depending on what the client accepts. See Compression.
  • Keeps serving cached content through a brief origin problem. If the origin errors or times out, or while a cache entry is being refreshed, the PoP serves the entry it already has rather than failing the request.

Serving assets under your own domain

Files in Storage are delivered under the /cdn/ prefix of a domain you have connected:

text
https://shop.example.com/cdn/photos/sunset.jpg

The path after /cdn/ is the path inside your tenant's storage, so the URL above addresses the file you uploaded to photos/sunset.jpg. Those requests are answered by the nearest point of presence. Transform parameters go on the same URL:

text
https://shop.example.com/cdn/photos/sunset.jpg?w=800&fm=webp

Each distinct set of transform parameters is cached separately at the PoP, so the first request for a size pays for the transform and every later one is served from the edge.

Cache behaviour you can rely on

  • Responses under /cdn/ are cached at the PoP for one hour, then revalidated. While a revalidation is in flight the previous entry keeps being served, so a request never waits for a refresh.
  • Every response from the edge carries an X-Edge-Cache header reporting what the cache did — HIT, MISS, EXPIRED, STALE, UPDATING, BYPASS. Read it when you are working out why something is or is not being served from the edge.
  • Only 200 and 302 responses are cached. Errors are not, so a bad deploy does not get pinned at the edge for an hour.
Request
curl -sI https://shop.example.com/cdn/photos/sunset.jpg?w=800 | grep -i x-edge-cache

There is no purge API. If you need a changed asset live immediately, publish it under a different path or a different set of transform parameters — a new URL is a new cache key and is fetched fresh. Overwriting a file in place will keep serving the previous version at the edge for up to an hour.

Where your data lives

The origin and your tenant's data are in Germany. A point of presence caches content that has been requested through it and holds it only until the entry expires — it is not a replica, and it does not move your tenant data out of the origin. See Edge network for what that means for data residency.

Related

Was this page helpful?