Content Delivery & 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.

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).

Connecting from a private hosting environment

Many organizations host their website inside their own cloud tenancy, for example on Azure App Service with VNet integration and outbound traffic routed through a firewall. Your site only needs outbound HTTPS to Agility. Agility connects to your environment only if you choose to receive webhooks.

1. An editor publishes in the Content Manager, after signing in through your identity provider if you use Enterprise SSO.
2. Agility writes the published content to its delivery store, in your instance's region, and clears the affected responses from its CDN.
3. Optionally, Agility sends a signed webhook to your site's revalidation endpoint, so the site refreshes straight away instead of waiting for its cache to expire.
4. Your site requests the content from the Content Fetch API over HTTPS, with an API key kept on the server. The CDN answers from its cache, or from Agility's origin on a cache miss.
5. Your site renders the page and serves it to visitors from its own cache and CDN.
6. Visitors' browsers load images and files from Agility's asset CDN, unless your site downloads and serves them itself.

Hostnames to allow

Allow outbound HTTPS (port 443) from your site to these hostnames:

Purpose	Hostname
Content Fetch, GraphQL and Content Sync APIs	The host for your instance's region: api.aglty.io (USA), api-usa2.aglty.io (USA 2), api-ca.aglty.io (Canada), api-eu.aglty.io (Europe) or api-aus.aglty.io (Australia)
Images and files, if your servers download them	The host in your asset URLs, for example cdn.aglty.io

Allow them by hostname, not IP address. The CDN uses shared addresses that change without notice. On Azure, use Azure Firewall application rules (or an equivalent outbound proxy) with these fully qualified domain names.

Your site doesn't need the Management API at runtime, unless you've built server-side features that write to Agility.

Ways to connect

Option	How it works	What Agility needs to reach
Fetch at runtime	Your site calls the Content Fetch or GraphQL API and caches responses for a set time.	Nothing. Outbound only.
Fetch at runtime, refreshed by webhooks	As above, and a webhook tells your site to clear its cache when content is published.	One HTTPS endpoint on your site.
Pull at build or sync time	Your CI/CD pipeline or a background job pulls content with the Content Sync SDK or the Fetch API and deploys it or stores it on your side. The live site never calls Agility.	Nothing, or a webhook endpoint that starts the pipeline when content is published.
Preview environment	Web Studio loads your preview site in the editor's browser, and the preview site reads unpublished content with a preview key.	Nothing. The preview site only has to be reachable from editors' browsers, so it can stay on your internal network or VPN.

Securing a webhook endpoint

If you receive webhooks, the endpoint must be reachable over HTTPS from the internet. You can put it behind your own gateway or web application firewall, for example Azure Application Gateway, Front Door or API Management.

Verify the signature on every request. Turn on secure delivery for the webhook, and reject any request whose signature doesn't verify. Agility doesn't publish a list of webhook source IP addresses, and the addresses can change, so don't rely on IP filtering. See Verifying Signed Webhooks.

What isn't available

Agility is a multi-tenant SaaS service. Private Link, ExpressRoute, VNet peering and dedicated IP addresses aren't available. If you need one of them, request it on our roadmap. All traffic to and from Agility uses HTTPS with TLS 1.2 or 1.3 over the public internet.

For sign-in, permissions and audit questions from security reviewers, see the Security Review Guide.

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)
Network path from private hosting	✅ Serves the content APIs and assets over HTTPS; signs webhooks	✅ Allows outbound HTTPS to Agility's hostnames; verifies webhook signatures; keeps API keys on the server