# Content Delivery & CDN Architecture

> Source: https://agilitycms.com/docs/developers/content-delivery-and-cdn-architecture

Agility delivers published content and media through **Fastly**, a globally distributed CDN: the content APIs (Content Fetch / GraphQL) and the asset CDN are fronted by Fastly's edge network so that requests are served from the location nearest the end user, minimizing latency. This is **Agility's platform delivery layer**, and it is distinct from a **customer's own front-end CDN** — the CDN a customer puts in front of *their* website or application (e.g. via their hosting/Vercel/Netlify/Cloudflare setup). In a typical production architecture there are effectively **two CDN layers**: Agility's platform CDN serving content/assets to the application, and the customer's front-end CDN serving rendered pages to browsers. Understanding the split clarifies who controls caching, invalidation, and edge behaviour at each layer.

## Agility's platform delivery layer

Agility's APIs and assets are served from a global CDN:

- **Content APIs (Fetch / GraphQL):** responses are CDN-backed and cacheable on Fastly; a response served from the Agility CDN cache does not count against API rate limits.
- **Asset CDN (`cdn.aglty.io`):** images and files are stored on Microsoft Azure and delivered via Fastly, with edge caching, cache-control rules, and on-the-fly image optimization (resize/format) available via query-string transformations.
- **Edge distribution:** content and assets are cached at Fastly edge locations (POPs) close to users; the nearest edge server responds, and only cache misses reach the Azure origin.
- **Instant cache invalidation:** when content is published, the relevant cached content is invalidated at the edge **instantly**, so updates propagate immediately rather than waiting for a TTL to expire.

## A customer's own front-end CDN

Production sites built on Agility are usually statically generated or server-rendered and deployed behind the customer's own hosting and CDN (for example, the CDN built into Vercel, Netlify, Azure Front Door, Cloudflare, etc.). This front-end CDN:

- Caches and serves the **rendered HTML/pages and front-end assets** to browsers.
- Is **owned and configured by the customer/partner** — its cache TTLs, invalidation, WAF, geo rules, and failover are the customer's responsibility.
- Is **independent** of Agility's platform CDN: the front end fetches content from Agility's APIs (often at build time or via revalidation), then serves end users from its own edge.

![Two-CDN-layer architecture: in the customer-owned band, browsers hit the customer's own CDN (Vercel/Netlify/Azure Front Door/Cloudflare) serving rendered pages and front-end assets, backed by the customer app; across the ownership boundary, Agility's global Fastly CDN serves cached content-API responses and assets, with the Agility content platform on Microsoft Azure as origin reached only on cache miss.](https://cdn.aglty.io/agility-cms-docs/images/owners-admins/diagram-two-cdn-layers.svg)

## The two-layer model

| | Agility platform CDN | Customer front-end CDN |
| --- | --- | --- |
| Serves | Content API responses + media assets | Rendered pages + front-end assets |
| Consumer | The customer's application / build | End-user browsers |
| Owned by | Agility | Customer / implementation partner |
| Cache invalidation | Instant — Agility invalidates cached content at the edge on publish; also exposes webhooks for downstream revalidation | Configured by the customer (cache tags, on-demand revalidation, TTLs) |
| Origin | Agility's content platform on Azure | The customer's app/host, which in turn calls Agility's APIs |

This separation is also why end-user availability is so resilient: even if Agility's origin/API layer has a brief event, a statically generated site behind the customer's CDN keeps serving already-rendered pages (see *SLA & Uptime* and *Disaster Recovery & Business Continuity*).

## Shared responsibilities

| Area | Agility | Implementation partner / customer |
| --- | --- | --- |
| Platform content/asset CDN | ✅ Operates global edge delivery for APIs + assets | — |
| Image optimization / transformation | ✅ Query-string transforms on asset CDN | ✅ Requests appropriate sizes/formats |
| Front-end CDN | — | ✅ Selects, configures, and operates its own CDN (TTLs, invalidation, WAF, geo rules) |
| Cache invalidation end-to-end | ✅ Provides webhooks/revalidation triggers | ✅ Wires revalidation into the front end and its CDN |
| Delivery-residency constraints | ✅ Operates platform edge | ✅ Enforces any geo-restriction at the front-end CDN if required (see *Data Residency*) |