What is your developer-dependent CMS actually costing you? Calculate your costs and get a full report
What is your developer-dependent CMS actually costing you? Calculate your costs and get a full report
Architecture
Proven shapes for solutions built on Agility: the building blocks, the request path they share, and five reference architectures with components, data flow, caching, preview and failure modes.
A reference architecture shows one proven shape for a whole solution built on Agility: which parts you build, which parts Agility runs, how content moves between them, where it is cached, how editors preview it, and what breaks first. Use these pages to choose a starting shape and to explain it to your team. The implementation guides they link to cover how to build each part.
Every architecture on these pages is put together from the same Agility pieces.
| Building block | What it does | Learn more |
|---|---|---|
| Instance | One Agility project: its own content, assets, users, roles, API keys, webhooks and data region | Choose Your Tenancy Model |
| Sitemaps and channels | Page trees. An instance can have several, each with its own pages, domains and preview URL | Sitemaps |
| Content Fetch API and GraphQL API | Read published content (fetch key) or the latest saved content (preview key) | Content Fetch API, GraphQL API |
| Content Sync | Copy content into a store you own and keep it up to date with a sync token | Content Sync Explained |
| Webhooks | Tell your systems that content was saved, published, unpublished or moved through workflow | Webhook Events and Payload Reference |
| Preview and Web Studio | Show editors saved, unpublished changes on your own site, inside Agility | Setting Up Preview, Set Up Web Studio with Any Framework |
| Asset CDN | Serves images and files from cdn.aglty.io, with image transformations by query string | Image Transformation Reference |
| Management API, SDKs, CLI and MCP server | Write content, models and settings from code, pipelines and AI tools | Content Management API |
Agility is the content system. Your team builds and hosts the front end. Between the two sit two CDN layers: Agility's, in front of the content APIs and assets, and your own, in front of your rendered pages. See Content Delivery & CDN Architecture.
| Step | From | To | What happens |
|---|---|---|---|
| 1 | Visitor's browser | Your CDN or host | Most requests are answered with a page that is already rendered and cached |
| 2 | Your host | Your app | A cache miss, or a page that must be rendered per request |
| 3 | Your app | Your data cache | Content the app has already fetched is reused |
| 4 | Your app | Agility Content Fetch or GraphQL API | A response cached on Agility's CDN is returned without reaching the API |
| 5 | Agility | Your webhook endpoint | On publish, your app learns what changed and clears the matching cache entries |
| 6 | Visitor's browser | cdn.aglty.io | Images and files load straight from Agility's asset CDN |
Two rules follow from this shape and apply to every page below:
| Architecture | Choose it when | Key decision |
|---|---|---|
| Marketing website | One brand's public website, managed page by page by marketers | How you cache and how publishing clears the cache |
| Multi-brand and multi-site | Several brands, regions or microsites share a team, a model or content | One instance with several sitemaps, or several instances |
| Headless commerce | A commerce platform owns products, prices and checkout; marketers own the story around them | Which system owns each piece of data |
| Member portal and intranet | Some content is only for signed-in people | Where access is enforced, and what is public by design |
| Multi-channel delivery | The same content reaches a website, an app, email, kiosks or screens | Pull, push or local copy for each channel |
Most real solutions combine two or more of these. A retailer might run a multi-brand setup in which each brand site is also a commerce site, with an app reading the same content.
