Transloadit

What is an Edge Server?

An edge server handles requests near end users rather than solely at a central origin. It may cache content or perform routing, transformation, authentication, and computation at a distributed network location.

How Edge Servers work

In HTTP terms an edge server is a reverse proxy, which RFC 9110 calls a gateway: toward the client it acts as the origin server, and it forwards the requests it cannot answer itself to another server. CDN operators run many of them, grouped into locations that Fastly calls points of presence (POPs) and Cloudflare calls data centers. A client reaches one of those locations either because DNS returns an address chosen for that client or because the same anycast address is announced from every location and network routing picks one. The edge server then answers from its cache, runs configured request logic, or forwards the request toward the origin. A response cached in one location is not automatically stored in the others, and where a cache miss goes next depends on the CDN and its configuration: straight to the origin, or first to an upper-tier cache such as a Fastly shield POP, a Cloudflare Tiered Cache upper tier, or an Amazon CloudFront regional edge cache.

Key facts

  1. Does the nearest edge server always handle the request? No. With anycast, the routing system picks the location from network topology, and RFC 4786 notes that topological nearness does not, in general, correlate with round-trip performance. With DNS-based selection, the CDN’s authoritative DNS server sees the address of the recursive resolver (the DNS server that looks names up on the user’s behalf) rather than the user’s own address, unless the resolver forwards a client subnet, which is a truncated form of the user’s address. Someone using a distant resolver can therefore be sent to a location near the resolver.
  2. Is a response cached at one edge location available at all of them? Not automatically: a location that has not stored the response has a cache miss, and where that miss goes depends on the CDN and its configuration. Fastly POPs forward to the origin independently unless shielding sends them through one shield POP, and Cloudflare’s Tiered Cache makes a lower-tier data center ask an upper tier before the origin. Amazon CloudFront has such a tier by default: a POP that misses typically asks a regional edge cache, which may already hold the object. None of these tiers guarantees what reaches the origin. Cloudflare applies Tiered Cache only to requests that are eligible for caching, CloudFront sends dynamic requests and methods such as POST from the POP straight to the origin, and Fastly advises Compute code to fall back to the origin when the shield POP is unavailable.
  3. What code can run on an edge server? It depends on the product and on the stage of the request the code is attached to, so check before designing around it. Amazon CloudFront documents two options: CloudFront Functions for lightweight work such as cache key normalization, header changes, redirects, and token validation, with no network access and no access to the request body; and Lambda@Edge for functions that need network access, third-party libraries, or the request body. Tiering can also change how often code runs: with Fastly shielding, edge code typically runs twice, once at the first POP and once at the shield, so logic that rewrites a request or adds a header has to be safe to run twice.
  4. Does validating a signed URL at the edge protect the origin? Only for requests that pass through the edge. CloudFront documents two separate controls: signed URLs or signed cookies restrict access to files in the edge caches, while the origin has to be closed separately so that clients cannot bypass the CDN and fetch from it directly. For an S3 origin that means giving an origin access control permission to read the bucket and removing everyone else’s permission to read the files through S3 URLs. For a custom origin it means a custom header that CloudFront adds to origin requests and the origin requires, with HTTPS on both the viewer and the origin connection so that the header is encrypted in transit. AWS’s guidance for load balancer origins adds that this works only while the header name and value stay secret, and recommends rotating them. Separately, if clients authenticate with an Authorization header rather than a signed URL, RFC 9111 forbids a shared cache from reusing the response for a later request unless the response allows it with public, s-maxage, or must-revalidate.

When Edge Servers matter

Edge servers matter most when many clients far from the origin request the same response: a cache hit is answered at the edge location and never reaches the origin. A request that the edge cannot answer from a stored response is handled when it arrives, either by the origin, in which case the request still travels upstream, or by edge logic that generates the response itself. There the edge contributes routing, filtering, or request logic rather than a stored copy. When you design around one, plan for the cache-miss path, for caches that fill separately in each location, and for requests that reach the origin without passing through the edge.

How Transloadit helps with Edge Servers

Transloadit’s Smart CDN puts edge caching in front of on-demand processing. A request to a tlcdn.com URL is answered from the edge when a cached copy exists. On a cache miss the request runs your Template as an Assembly, the /file/serve Robot picks the result to return and sets its Cache-Control header, and /tlcdn/deliver caches and delivers that result close to your users.

The linked pages describe caching and delivery at the edge and processing in an Assembly. They do not document a runtime for running your own code at the edge. A Smart CDN URL can optionally carry an expiration time and a signature; if the URL or its parameters are changed afterwards, the signature no longer matches. That keeps outsiders from altering the URL only when unsigned requests are refused, and the linked pages also do not say how an unsigned request to the same Template is treated, so test that on your own Workspace before relying on it. Transloadit describes Smart CDN as a transformation and delivery layer that does not replace your application’s authorization policy.

Explore Transloadit’s delivery capabilities

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free