# Why We Recommend Next.js and .NET > Source: https://agilitycms.com/docs/developers/why-we-recommend-nextjs-and-dotnet Agility CMS is headless, so your front end can be built with almost anything that can make an HTTP request. For **new projects**, though, we recommend one of two stacks: **Next.js** or **ASP.NET Core (.NET)**. This article explains why, what each one is good at, where each one is weaker, and what to do if your team prefers something else. ## The short answer - **Choose Next.js** if your team works in JavaScript or TypeScript and wants the most complete Agility experience out of the box: server components, tag-based caching with instant revalidation, preview, and in-context editing in Web Studio. - **Choose .NET** if your organization is a Microsoft shop, runs on Azure, or wants a strongly typed, long-term-support platform that fits existing enterprise standards. Pick MVC or Blazor depending on how you build UI today. - **Using something else?** That still works. Our [Content Fetch API](/docs/developers/content-fetch-api), [GraphQL API](/docs/developers/graphql-api) and [Content Sync SDK](/docs/developers/content-sync-api) are framework-agnostic. You just won't get an official, maintained starter for it. ## Why we recommend fewer frameworks We used to publish starters and guides for many frameworks. Over time most of them fell behind their framework's current major release. A starter that targets an out-of-support version is worse than no starter: it ships known security issues, its guides stop matching what developers see, and AI coding tools learn from the outdated code. The honest reason for focusing is capacity. **We can keep two starters current and secure. We can't do that for ten.** Concentrating on two stacks lets us promise: - **Maintained starters.** The official [Next.js starter](https://github.com/agility/agilitycms-nextjs-starter) and [.NET starter](https://github.com/agility/agilitycms-dotnet-starter) track current framework releases, so you start a project on supported versions instead of upgrading on day one. - **Security updates.** When a framework or dependency ships a security fix, we update the starters that we maintain. Fewer starters means fixes land sooner. - **Docs that stay accurate.** The [Next.js](/docs/nextjs) and [.NET](/docs/dotNet) sections are kept in step with the current starters and SDKs, rather than describing an older release. - **AI tools that get it right.** Our starters include `AGENTS.md` conventions written for these stacks, the [MCP server](/docs/developers/agility-cms-mcp-server) lets AI coding tools work with your Agility instance directly, and the [Knowledgebase MCP server](/docs/overview/agility-knowledgebase-mcp-server) points them at current docs. An AI coding tool working in a maintained starter has accurate instructions and current examples to follow. This is not a judgment on other frameworks. Many of them are excellent, and plenty of Agility customers run production sites on them. ## Why Next.js Next.js is a React framework, and it's the stack our own docs site is built with. The official starter uses the **App Router**, **React Server Components**, and our [`@agility/nextjs`](https://www.npmjs.com/package/@agility/nextjs) and [`@agility/content-fetch`](https://www.npmjs.com/package/@agility/content-fetch) SDKs. **Performance and caching.** The starter tags every content fetch with a cache tag. When an editor publishes, Agility calls the starter's revalidation webhook, and only the pages that use that content are refreshed. Pages stay statically fast without waiting for a full rebuild or a timed cache expiry. See [Caching with Next.js and Agility](/docs/nextjs/caching-with-next-js-and-agility). **Server components.** Content is fetched on the server, close to the data, and your API keys never reach the browser. Components ship only the JavaScript they need to be interactive. **Preview and Web Studio.** The starter is wired for preview mode and for in-context editing in [Web Studio](/docs/web-studio), so editors can click into a page and edit what they see. See [Preview URL Lifecycle](/docs/nextjs/preview-url-lifecycle) and [Previewing in Web Studio](/docs/editors/previewing-in-web-studio). **Ecosystem.** React and Next.js have a very large community, component library and hiring pool, and most AI coding tools are especially familiar with them. **Hosting options.** Next.js is not tied to one host. You can deploy to [Vercel](/docs/nextjs/deploying-next-js-to-vercel), [Netlify](/docs/nextjs/deploying-next-js-to-netlify) or [Azure](/docs/nextjs/deploying-next-js-on-azure), run it as a self-hosted Node.js server, or package it in a container. Use a current Node.js LTS release (Node 24 is the active LTS today). To get started, see [Next.js and Agility CMS](/docs/nextjs/next-js-and-agility-cms) and [Using the Next.js Starter](/docs/nextjs/using-the-next-js-blog-starter). ## Why .NET ASP.NET Core is Microsoft's cross-platform web framework. The official .NET starter includes both **ASP.NET Core MVC** and **Blazor** versions, targets **.NET 10 (LTS)**, and uses the `Agility.NET.FetchAPI` package to read content. For writing content, models and pages from code, the [.NET Management SDK](/docs/javascript/management-sdk/getting-started) (version 2.0) is stable on .NET 10. **Enterprise and Microsoft shops.** If your team already builds, secures and operates .NET applications, an Agility site fits into the same tooling, code review, CI/CD and security processes you use today. There's no second runtime to learn or govern. **Azure.** .NET apps deploy naturally to Azure App Service and other Azure services, alongside the identity, monitoring and networking you already run there. See [Deploy to Azure](/docs/dotNet/deploy-to-azure). **Strong typing.** C# models for your content give you compile-time checks and editor tooling across the whole project, which helps on large teams and long-lived sites. **Predictable support.** Microsoft publishes a regular release cadence with designated long-term-support (LTS) versions. Building on an LTS release gives you a known support window to plan upgrades around. **MVC or Blazor.** Use [MVC](/docs/dotNet/mvc-starter) for classic server-rendered pages, or [Blazor](/docs/dotNet/blazor-starter) if your team prefers a component model in C#. To get started, see [Getting Started with .NET](/docs/dotNet/getting-started). ## Which one should I choose? | If this describes you | We suggest | | --- | --- | | Your team writes JavaScript or TypeScript and React | Next.js | | You want in-context editing in Web Studio with the least setup | Next.js | | You want to host on Vercel or Netlify | Next.js | | Your organization standardizes on Microsoft and C# | .NET | | You deploy to Azure App Service and use Azure identity and monitoring | .NET (Next.js also runs on Azure) | | You need long, predictable support windows for compliance or procurement | .NET | | You want a component-based UI but in C# | .NET with Blazor | | You're building a marketing site and want the largest pool of examples and AI tooling | Next.js | Both are good choices. The best choice is usually the one your team can maintain confidently for years. ## Honest trade-offs No stack is perfect. Here is the devil's-advocate view of each. **Next.js** - **It changes quickly.** Major releases arrive often and sometimes change recommended patterns (routing, caching and rendering have all shifted in recent years). Budget time to keep up, or pin versions and upgrade deliberately. - **It has more moving parts.** Server and client components, multiple caching layers and preview modes are powerful, but they take time to understand. Debugging "why didn't this page update?" means understanding how caching works. - **Hosts differ in the details.** Next.js runs anywhere Node.js runs, but platform extras such as image optimization, edge functions and build caching vary from host to host. Check your host's Next.js support before you commit. **.NET** - **A smaller headless ecosystem.** Fewer headless-CMS examples, community components and tutorials exist for .NET than for React and Next.js, so you'll write more yourself. - **In-context editing needs more wiring.** The .NET starters support preview mode, but Web Studio in-context editing comes wired into the Next.js starter. In .NET, expect to do more of that setup yourself. - **A heavier fit for small teams.** If you don't already run .NET, adopting it just for a marketing site adds a runtime, tooling and hosting you didn't have before. ## Using another framework? You can. Agility is API-first, and everything you need is available to any stack: - The [Content Fetch API](/docs/developers/content-fetch-api) and [GraphQL API](/docs/developers/graphql-api) work from any language that can make an HTTP request. - The [Content Sync SDK](/docs/developers/content-sync-api) keeps a local copy of your content for fast builds. - The [JavaScript SDKs](/docs/javascript) work with any JavaScript framework. - Webhooks, preview and the [MCP server](/docs/developers/agility-cms-mcp-server) are framework-agnostic. If you build with an AI coding tool, the [Vibe Coding with Agility](/docs/developers/vibe-coding-with-agility) section shows how to go from a use-case brief to a working, editable site on the framework of your choice, using the MCP server to create the content model as you go. Our older framework guides remain online. The Angular, Astro, Eleventy and SvelteKit guides are archived, which means they carry a notice that they're no longer maintained, but every URL still works. The [Nuxt](/docs/nuxt) guides are marked as outdated. These guides can still help with patterns, but check versions carefully before you build on their starters. ## Have a framework you love? Let us know! We'd like to hear what you're building with. If there's a framework you'd like us to support, or if you're running Agility on a stack that isn't covered here, tell us what you're using and what you'd need from us. **[Email support@agilitycms.com](mailto:support@agilitycms.com?subject=Framework%20request)** with the subject "Framework request". Requests like yours help us decide where to invest next.