# Headless, Hybrid or Traditional: Choose Your Delivery Model

> Source: https://agilitycms.com/docs/overview/choose-your-delivery-model

Agility is a headless CMS, but there is more than one way to use it. You can let editors run whole websites through page management, use Agility only for specific content, add it to an existing server-rendered site, feed many channels from one instance, or keep a synced copy of your content. This guide compares those options so you can pick the one that fits your project, or combine them.

## The options at a glance

| Option | What Agility manages | What your code does | What editors can do | Start with |
| --- | --- | --- | --- | --- |
| **Headless with page management** | Content, pages, sitemaps, page models and components | Renders each page in the sitemap with the matching page model and components | Add, remove and reorder pages and components, set SEO, preview, edit in Web Studio | [Next.js or .NET starter](/docs/developers/why-we-recommend-nextjs-and-dotnet), [Page Management in a Headless CMS](/docs/developers/page-management-in-a-headless-cms) |
| **Headless, content only** | Content lists and items | Decides what pages exist, their layout and routing, and pulls in content where needed | Manage specific content (blog posts, products, header, footer) and preview it | [Content Fetch API](/docs/developers/content-fetch-api), [GraphQL API](/docs/developers/graphql-api) |
| **Hybrid: Agility in an existing site** | Part of the site (for example the blog), or the whole sitemap | Your existing server-rendered site calls Agility's REST API for the parts it manages | Depends on how far you integrate, from managing one content type to managing every page | [Integrating Agility into a Traditional Website](/docs/overview/integration-agility-cms-into-a-traditional-website) |
| **Content hub for many channels** | Content shared by several sites, apps and other destinations, often with a sitemap per destination | Each channel reads the content it needs | Publish once and reuse everywhere | [Building a Content Hub](/docs/overview/building-a-content-hub), [Publishing to Multiple Destinations](/docs/overview/publishing-to-multiple-destinations) |
| **Synced copy** | Content and pages, as the source of truth | Keeps a local copy with the Content Sync API and reads from it | Edit and publish as usual; the copy updates after each sync | [Content Sync Explained](/docs/developers/content-sync-explained) |

## Headless with page management

This is the fullest way to use Agility, and the way Agility's Next.js and .NET starters work. Your front end reads the [sitemap](/docs/developers/sitemaps), and for each page renders the page model and the components editors placed in its zones. Each component model in Agility has a matching component in your code.

**Choose it when** editors should be able to launch and change pages without a developer, and you are building a new site or rebuilding one.

**Trade-off:** your front end has to implement page routing and a component for every component model. The starters already do this, which is why they are the usual starting point.

## Headless, content only

Your code decides what pages exist and how they look. Agility holds the content those pages show. This is the minimum integration described in [Integrating Agility into a Traditional Website](/docs/overview/integration-agility-cms-into-a-traditional-website): editors manage content, and preview it, but they can't add pages or change layouts.

**Choose it when** the pages are fixed by design (an app, a product UI, a small marketing site that rarely changes shape) and editors only need to change content.

**Trade-off:** every new page or layout change is a developer task.

## Hybrid: adding Agility to an existing site

If you have a server-rendered site you can't rebuild yet, you can integrate Agility gradually. Start with one type of content, such as blog posts, and extend from there. At the fullest level, Agility powers the sitemap and page rendering of the whole site. For ASP.NET, Agility's .NET SDK handles content sync, page routing and page rendering for you.

**Choose it when** a full rebuild isn't possible now, or you want to move section by section.

**Trade-off:** editors only get page management for the parts you integrate. Plan how far you'll go, because it decides what editors can and can't do.

## Content hub for many channels

One instance can feed several destinations. A [sitemap](/docs/developers/sitemaps) can represent a website, an app or digital signage, and the content behind it can be shared. Several similar sites can share page models, components and content models across sitemaps. See [Using Agility for Multiple Sites](/docs/overview/using-agility-cms-for-multiple-sites).

**Choose it when** the same content appears in several places, or several sites share a structure.

**Trade-off:** shared models need governance. Changes to a shared model affect every site that uses it.

## Synced copy

The [Content Sync API](/docs/developers/content-sync-api) returns every content item and page that changed since your last sync, so your app can read from its own store instead of calling Agility for each request. A publish webhook tells you when to sync.

**Choose it when** you need offline access, a search index or data warehouse, or very high read volume from your own infrastructure.

**Trade-off:** you own the store and the sync process. For most websites, requesting content when you render, with a cache in front, is simpler.

## What about traditional?

In a traditional, coupled CMS, the CMS also renders and serves your website. Agility doesn't: your website always runs on your own code and hosting, and Agility delivers content to it. The hybrid option is the closest to a traditional setup, and with the .NET SDK, page routing and rendering are handled for you inside your own ASP.NET application.

## Choosing

Ask these questions in order:

1. **Will editors create pages and change layouts?** If yes, use page management. If no, content only may be enough.
2. **Are you rebuilding, or keeping an existing site?** Keeping it points to the hybrid option, at least to start.
3. **Does content go to more than one place?** If yes, design it as a content hub from the start, even if you launch one site first.
4. **Does any consumer need content without calling Agility at read time?** If yes, add a synced copy for that consumer.

You can mix options. A common combination is page management for the website, the same content read by a mobile app through the API, and a synced copy feeding search.

## Related

- [How Agility Works: A 10-Minute Architecture Tour](/docs/overview/how-agility-works)
- [What Your Team Builds vs What Agility Provides](/docs/overview/what-your-team-builds-vs-what-agility-provides)
- [Pages vs Content](/docs/editors/pages-vs-content)

---

## Related pages

- [Evaluating Agility](https://agilitycms.com/docs/overview/evaluating-agility.md)
- [What Your Team Builds vs What Agility Provides](https://agilitycms.com/docs/overview/what-your-team-builds-vs-what-agility-provides.md)
- [How Agility Works: A 10-Minute Architecture Tour](https://agilitycms.com/docs/overview/how-agility-works.md)
- [Is Agility Right for Your Project? When It Fits and When It Doesn't](https://agilitycms.com/docs/overview/is-agility-right-for-your-project.md)
- [Choosing a Headless CMS: A Capability Checklist and Questions to Ask Any Vendor](https://agilitycms.com/docs/overview/choosing-a-headless-cms.md)
- [Run a Two-Week Proof of Concept](https://agilitycms.com/docs/overview/run-a-two-week-proof-of-concept.md)
- [Getting Your Content Out: Data Portability and Exit](https://agilitycms.com/docs/overview/data-portability-and-exit.md)
- [Building the Replatforming Business Case](https://agilitycms.com/docs/overview/replatforming-business-case.md)
- [Evaluate Agility with an AI Agent in 30 Minutes](https://agilitycms.com/docs/overview/evaluate-agility-with-an-ai-agent.md)

Index of every docs page: https://agilitycms.com/docs/llms.txt