XM Cloud Architecture: How It Actually Works

Sitecore XM Cloud is not just “Sitecore in the cloud.” It represents a fundamental architectural shift from Sitecore XP and standalone XM:

• Cloud-native SaaS: Sitecore manages the CMS infrastructure entirely. You access it via web UI (Pages Builder, Content Editor) and deploy content through Experience Edge CDN.
• Headless-only: There is no traditional MVC rendering in XM Cloud. Your frontend is separate (typically Next.js + React) and consumes content via GraphQL from Experience Edge.
• Continuous deployment: Updates roll out automatically. You’re always on the latest version — no manual upgrades.

XM Cloud launched mid-2022 and has matured significantly through 2024-2026. As of early 2026, it represents Sitecore’s strategic direction for new CMS projects.

Naming Evolution

You may see “XM Cloud” referred to as “SitecoreAI” in some 2026 contexts due to Sitecore’s rebrand focus on AI capabilities. The underlying platform is the same.

How It Actually Works

Understanding XM Cloud’s architecture requires knowing four core components and how they interact.

Core Components

1. XM Cloud (Content Management)

The actual Sitecore instance lives in the cloud. You interact with it through:

• Pages Builder: WYSIWYG component-based content authoring (the primary editing interface)
• Content Editor: Admin interface for schema work, settings, complex content operations
• Sitecore CLI (SCS): Command-line tool for pulling/pushing serialized content and templates

Content is authored, then published to Experience Edge. Sitecore manages all infrastructure — databases, caching, scaling, patching.

2. Experience Edge (Content Delivery)

Experience Edge is a globally distributed CDN that serves published content via GraphQL. It has two APIs:

• Delivery API (https://edge.sitecorecloud.io/api/graphql/v1): Production content only, CDN-cached, extremely fast
• Preview API (https://xmcloudpreview.sitecorecloud.io/api/graphql/v1): Draft + published content, no CDN caching, used during editing

Your frontend queries these APIs to fetch content. Experience Edge handles global distribution, caching, and rate limiting.

3. Headless Frontend (Your Next.js App)

XM Cloud requires a separate frontend application. Most implementations use Next.js with React, though any framework that can consume GraphQL works.

You host this frontend separately — Sitecore does not host it. Common hosting options:

• Vercel (recommended by Sitecore, excellent Next.js support)
• Azure Static Web Apps
• AWS Amplify
• Custom Node.js hosting

4. Deploy App (CI/CD)

XM Cloud includes a built-in GitOps CI/CD service that connects to GitHub or Azure DevOps. When you push code, Deploy App:

1. Builds your serialized templates and content (SCS format)
2. Pushes them to your XM Cloud environment
3. Publishes to Experience Edge

You can alternatively use your own CI/CD tooling with Sitecore CLI commands.

Architectural Flow

Developer Workstation
   ├─> Sitecore CLI (push/pull templates)
   ├─> Next.js codebase
   └─> Git repository

Git Repository (GitHub/Azure DevOps)
   ├─> Deploy App (XM Cloud CI/CD) → XM Cloud environment
   └─> Frontend CI/CD (Vercel/Azure) → Rendering host

XM Cloud Instance
   ├─> Pages Builder (content authoring)
   ├─> Content Editor (schema/admin)
   └─> Publishing → Experience Edge CDN

Experience Edge CDN
   ├─> Delivery API (production)
   └─> Preview API (draft content)

Next.js Frontend (your hosting)
   └─> Queries Experience Edge GraphQL

Rendering Architecture: Content SDK vs. JSS

As of 2026, Sitecore has two SDK paths for building headless frontends with XM Cloud. Understanding which to use is critical.

Content SDK (Recommended for New Projects)

The Sitecore Content SDK is the newer, XM Cloud-specific SDK. It became stable in 2025 and represents Sitecore’s strategic direction.

Key characteristics:

• Leaner footprint: Significantly smaller bundle size than JSS
• Manual component registration: You explicitly register components in configuration (no automatic file watcher like JSS)
• Pages Builder only: Works exclusively with Pages Builder (metadata integration mode), no Experience Editor support
• XM Cloud-only: Not compatible with XP or standalone XM

When to use Content SDK:

• New XM Cloud projects starting in 2026
• You want simpler, more maintainable code
• Your content authors will use Pages Builder exclusively
• Not ideal if you’re migrating from XP with existing JSS code (evaluate migration cost first)

JSS SDK (Legacy Path, Still Supported)

JavaScript Services (JSS) is Sitecore’s original headless SDK, supporting XP, XM, and XM Cloud.

Current status (2026):

• Still maintained and receiving updates
• Updated to React 19 and Next.js 15 support (JSS SDK 22.10, November 2025)
• Not recommended for new XM Cloud projects — use Content SDK instead
• Maintained primarily for XP customers and existing XM Cloud JSS codebases

When to use JSS:

• You have an existing JSS codebase (migration to Content SDK requires effort)
• You need multi-platform support (XP + XM Cloud in the same codebase)
• Not ideal if you’re starting a new XM Cloud-only project (use Content SDK)

JSS + Next.js 15 Peer Dependency Issue

As of February 2026, JSS SDK 22.10 has a peer dependency declaration issue with Next.js 15. You’ll need to install with npm install --legacy-peer-deps until this is resolved. This is a known issue tracked in the Sitecore JSS GitHub repository.

Placeholder System Example

Both Content SDK and JSS use Sitecore’s placeholder system to dynamically render components. Here’s a JSS example (Content SDK is similar but with manual component registration):

import { Placeholder } from '@sitecore-jss/sitecore-jss-nextjs';

const Layout = ({ layoutData }) => (
  <div>
    <header>
      <Placeholder name="jss-header" rendering={layoutData} />
    </header>
    <main>
      <Placeholder name="jss-main" rendering={layoutData} />
    </main>
    <footer>
      <Placeholder name="jss-footer" rendering={layoutData} />
    </footer>
  </div>
);

Sitecore determines which components render in each placeholder based on layout service data fetched from Experience Edge.

Rendering Strategies: SSG vs. SSR

Static Site Generation (SSG) — Strongly Recommended

Generate pages at build time, serve as static HTML + JSON. This is the sweet spot for XM Cloud:

• Best performance (no API calls per page view)
• Lowest Experience Edge API usage (avoids rate limits)
• Cheapest hosting (static files on CDN)
• Use Incremental Static Regeneration (ISR) for content updates without full rebuilds

Server-Side Rendering (SSR) — Avoid Unless Necessary

Render on every request, fetching fresh data from Experience Edge:

• Higher latency (API call per page view)
• Risk of hitting Experience Edge rate limits
• Higher hosting costs (requires Node.js runtime)
• Only use for highly dynamic, personalized content that cannot be cached

Experience Edge Rate Limits

Experience Edge enforces rate limits on API queries. Always prefer SSG over SSR to avoid hitting limits. If you must use SSR, implement aggressive caching at your rendering host level.