Fastly: CDN, Compute, Security & Media

Fastly’s CDN, Compute, application security, video and image delivery, storage and observability services explained alongside its public detection signals.

Updated 8 September 2026

What is Fastly used for?

Fastly is a programmable delivery platform for websites, APIs and other HTTP content. It lets teams decide how requests are routed and which responses can be reused at the edge. The underlying application can remain on a separate cloud provider or in the operator’s own infrastructure.

A useful example is a news site: images and public articles can be cached, while subscriptions and account pages need application-specific handling. An API might similarly cache a public product catalogue while forwarding each customer’s basket to the backend. The important distinction is whether a response can be shared safely.

Fastly CDN with VCL versus Fastly Compute

Fastly offers CDN services configured with Varnish Configuration Language, or VCL, and Compute services that run compiled WebAssembly applications. VCL gives developers control over the CDN request lifecycle. Compute provides an application runtime for implementing edge behaviour in supported programming languages.

These are different development models on Fastly’s platform. A team maintaining cache rules and origin selection may work primarily in VCL. A team building an edge application may choose Compute. The choice affects how code is built, deployed and debugged; a Fastly response header alone does not establish which model is in use.

Cache purging and origin shielding

Purging removes or expires cached content so it can be refreshed. Fastly supports purging individual URLs and groups of objects associated with surrogate keys. A publisher can use a shared key for an article and the pages that reference it, allowing a content change to invalidate the relevant group instead of clearing everything.

Shielding adds a designated Fastly point of presence between other edge locations and the origin. Requests that need to travel upstream converge through that shield, where another cache lookup can reduce origin traffic. An edge cache hit does not need to make that trip. Shielding also means cache headers can describe more than one Fastly location.

Security for applications, APIs and automated traffic

Fastly’s security portfolio includes Next-Gen WAF, DDoS Protection, API Security and Bot Management. These address application attacks, disruptive traffic, exposed APIs and unwanted automation. Client-Side Protection extends coverage to browser-side threats; AI Bot Management focuses on automated AI crawling.

Media, storage and real-time applications

Image Optimizer transforms images at the edge. Live streaming, video-on-demand delivery, Media Shield and packaging services support media workflows. Compute applications can use Key Value Store and Object Storage, while WebSockets and Fanout support real-time messaging.

Observability and delivery diagnostics

Real-time Logging exports request information for analysis. Edge Observer, Domain Inspector and Origin Inspector provide different views of delivery behaviour, and alerts flag service metrics. This helps teams distinguish an origin problem from a cache or traffic change. Fastly also offers AI acceleration through semantic caching.

What to test before using Fastly in production

Design the cache key around the actual response variants. For a catalogue, language and currency may change the output; a login cookie may require bypassing a shared cache entirely. Test those differences explicitly before increasing cache lifetimes.

For example, publish a changed article, purge its associated key and request both the article and its listing page. Also test a cache miss and an origin failure. This separates freshness, cache reuse and backend availability instead of treating a quick response as proof that all three work.

How DNSTrace.dev detects Fastly

Detection correlates independent public signals. A single match is reported as strong evidence; agreement between a response header and the announcing network is reported as confirmed.

x-fastly-request-id — Per-request identifier.
fastly-debug-path — Present when debugging output is enabled.
x-served-by — Names the cache node that answered, in the form cache-<pop>. DNSTrace.dev matches this pattern rather than the header alone, because other software reuses the same header name.
x-cache and x-cache-hits — Cache outcome for the object.
CNAME targets under fastly.net — The standard Fastly delivery mapping.

What a detection proves

The response came from a Fastly cache node, and the named point of presence handled the request.

What it does not prove

The origin behind the cache. A Fastly hit may be served entirely from cache without the origin being contacted at all.

Common questions about Fastly

Does Fastly replace the application server?

A Fastly CDN service normally retrieves content from an origin and caches eligible responses. Compute can run application logic at the edge, but any databases, external APIs and other upstream dependencies still need their own architecture.

What is the difference between purging and a short TTL?

A TTL sets when a cached object becomes stale with the passage of time. A purge lets an operator invalidate content in response to an event, such as publishing a correction. Fastly supports URL and surrogate-key purges.

Why is x-served-by matched by pattern rather than presence?

Several other proxies emit an x-served-by header. DNSTrace.dev only treats it as Fastly evidence when the value matches Fastly's cache-node naming, which avoids a false positive.

Does a cache HIT mean the origin is down?

No. A hit only means the object was already stored at the edge. It says nothing about the current state of the origin.

Developer platform, CDN and security