Edge network

revenexx runs one origin, in Germany, and four points of presence in front of it. There is no region to pick: every tenant's data lives at the same origin, and the points of presence are a delivery and filtering layer, not a second copy of the platform.

The four points of presence

This is our own fleet. No third-party CDN sits in the path, so the set of machines that sees your traffic is the set above plus the origin.

The region-to-PoP assignment above is the current one and can change as PoPs are added. It is not something you configure or depend on in code — treat it as orientation, not as an interface.

Routing

Routing happens in DNS. edge.revenexx.com — the name your custom domain CNAMEs to — is served by Geo-DNS: the answer depends on the region the asking resolver is in, so a client in Singapore gets the Singapore PoP's address and a client in Frankfurt gets Nuremberg's.

Two consequences are worth designing around:

• The decision is per-resolver, not per-request. It is made once when a resolver looks the name up, then cached for the record's TTL. A client using a resolver in a different region than itself is routed by the resolver's region.
• The granularity is regional, not latency-measured. There is no per-request probing to find the objectively fastest PoP, and no split of a single continent across two PoPs.

If a PoP is unavailable, traffic for its region is answered by another one. Delivery continues; latency for that region goes up until it is back.

What a point of presence does

Each PoP handles, for the hostnames it fronts:

• TLS termination. The handshake completes at the PoP, close to the client. See TLS.
• Request filtering. Managed WAF rules, bot mitigation, and rate limiting run before anything is forwarded. See WAF and DDoS mitigation.
• Caching. Cacheable responses are held at the PoP and served without touching the origin. See Caching.
• Compression. Text responses are compressed for the client that asked. See Compression.
• Image delivery. Transformed image variants are cached per set of parameters, so the second request for a size is served from the PoP. See Serve and transform images.

Everything a PoP cannot answer from cache is forwarded to the origin over the network between them.

The origin, and what that means for your data

There is one origin region and it is in Germany. Your tenant's data — products, orders, customers, uploaded files — is stored and processed there, and a point of presence never becomes a second home for it:

• Data at rest stays in Germany. A PoP holds cache entries for content that has been requested through it, and holds them only until they expire. It is not a replica and you cannot read your data out of one.
• Nothing to choose, nothing to migrate. Because there is one origin, there is no region selector at signup, no per-region hostname, and no cross-region migration to plan for.
• api.revenexx.com is answered by the origin. API calls are not fronted by a PoP; they go to Germany. That is the trade the topology makes: your data has one location, and the delivery layer accelerates content rather than duplicating the platform.

Some processing runs outside Germany but inside the EU — AI features in particular. If you have a data-residency commitment to meet, ask us for the current picture for the specific features you plan to use rather than inferring it from this page.

Related

• Endpoints — which hostnames the edge fronts and which the origin answers
• Content delivery — putting your own domain in front of the edge
• Domains — the DNS record and the verification flow