DEV Community: Roshan Ravaliya

SitecoreAI Deployments: The Shift from Legacy to Decoupled Architecture

Roshan Ravaliya — Mon, 30 Mar 2026 12:34:30 +0000

When enterprise teams migrate to SitecoreAI (XM Cloud), they celebrate the shift to a headless, composable, and AI-driven architecture. However, a common technical trap awaits them during the DevOps setup:

“how you deploy your frontend matters just as much as how you build it.”

This decision directly impacts:

Release velocity
Developer experience
Deployment speed
Production risk

In the SitecoreAI ecosystem, there are two primary ways to deploy your Next.js application: the Integrated (Coupled) approach via the Sitecore Deploy App, and the true Decoupled approach using independent CI/CD pipelines.

Decoupling in SitecoreAI isn’t just an architectural choice it’s the difference between treating your frontend as a deployable product versus a dependency of your CMS

Let’s break down the architectures, execution behaviours, and why enterprise teams are standardizing on the decoupled model.

In this guide, we’ll break down:

Coupled vs Decoupled deployment in SitecoreAI
Real-world system behaviour
Architecture patterns
Pros, cons, and when to choose each

What is Coupled vs Decoupled Deployment in SitecoreAI

In Sitecore AI, there are two primary deployment models:

1) Coupled (Integrated) Deployment

Managed via SitecoreAI Deploy App
Backend (CM) + Frontend (Next.js) deployed together
Single pipeline
One pipeline control everything
Small UI change → full deployment
Deployments act as a monolith.
Small UI change → full deployment must trigger a deployment through Sitecore.
Typical Flow:

Git → Deploy App → CM + Edge + Frontend → Live

Deployment time: 15–30 minutes

2) Decoupled Deployment

Backend and frontend deployed independently
Separate CI/CD pipelines
Frontend hosted on:
- Vercel
- Netlify
- BYOF (Bring Your Own Frontend)
Flow

- Backend: Git → Deploy App → CM + Edge
- Frontend: Git → Vercel → Live

Deployment time:
- Small apps: 2–5 minutes
- Enterprise apps: 5–10 minutes

The Architecture: Coupled vs. Decoupled

To understand the difference, we must trace how code moves from your repository to the delivery edge.

1) The Coupled (Integrated) Architecture

In this legacy model, the Sitecore Deploy App acts as the monolithic orchestrator for your entire stack.

Your GitHub/Azure DevOps repository is connected directly to the SitecoreAI Deploy App.
When a deployment is triggered, SitecoreAI builds BE and FE, pushes schema changes to Experience Edge, and then pushes the Next.js frontend code to the Sitecore-managed rendering host - all in the same pipeline instance.
Git → Deploy App → CM + Edge + FE → Live

2) The Decoupled Architecture

In this model, the CMS backend and the Next.js frontend are treated as completely independent microservices.

Pipeline A (The CMS): The SitecoreAI Deploy App is strictly responsible for building the CM server and pushing backend schema/configuration changes to the Authoring environment.
Pipeline B (The Frontend): The Next.js application is built and deployed via its own pipeline.
BE: Git → Deploy App → CM + Edge
FE: Git → Vercel → FE

If you place both the backend and frontend in the same repository (Monorepo), the Authoring environment pipeline will completely ignore the frontend code, and the Delivery pipeline will ignore the backend code.

Alternatively, you can physically split them into two different repositories (Polyrepo).

The Two Flavors of Decoupled Frontend Hosting:

When decoupling, you have two options for hosting your Next.js delivery layer:

Option A: Sitecore-Managed (Inbuilt Vercel): You utilize the Vercel infrastructure provisioned and managed by Sitecore under the hood. It provides a managed Editing Host, but you still decouple the deployment triggers.
- Note: You can not use public url for this environment for the preview site, it is useful Page builder and experience editor only.
Option B: Bring Your Own Frontend (BYOF - External): You connect your own enterprise Vercel or Netlify account directly to your repository. This requires manual configuration but offers ultimate DevOps control.

Architectural Implementation Steps

Moving to a decoupled setup requires re configuring your pipelines to isolate the delivery edge. Here is the architectural flow:

Step 1: Establish the CMS Pipeline

In the SitecoreAI Cloud Portal, configure your Deploy App to only build the CM environment.
Disable any integrated frontend rendering host configurations if moving entirely to BYOF.

Step 2: Choose and Configure the Frontend Pipeline

If using BYOF (External Vercel/Netlify): Go directly to your external hosting provider. Create a new project, point it to your repository, and specify the root directory of your Next.js application.

-Note: Manually configure all variable in step 3
If using Sitecore-Managed (Inbuilt Vercel): Ensure your editing host is configured within your xmcloud.build.json to point to the correct Next.js application path, but rely on external webhooks to trigger UI-only builds if supported by your tier.
- Note: Sitecore configure all required variable automatically, No need to do Step 3

Step 3: Map the Environment Variables

Because Sitecore is no longer auto-injecting environment variables into the delivery host, you must map them manually in your frontend host. Crucial variables include:

SITECORE_API_KEY (Your Experience Edge Token)
SITECORE_API_HOST (The Experience Edge GraphQL endpoint)
JSS_APP_NAME (The name of your site configuration)
GRAPH_QL_ENDPOINT (The endpoint for the delivery layer)

Step 4: Configure CI/CD Hooks

Set up GitHub Actions, Azure Pipelines, or Vercel webhooks to trigger frontend builds automatically upon merging to your main or staging branches.

Common Troubleshooting Scenarios

Experience Editor breaks due to incorrect editing host setup
Mismatched GraphQL schemas between FE and Edge
Environment variable drift between environments
Preview vs Delivery endpoint confusion

Pros and Cons

Coupled (Legacy) Deployment

Pros:
- Simplicity: A single pane of glass for all deployments in the Sitecore Cloud Portal.
- Beginner Friendly: SitecoreAI handles the Edge and Editing Host environment variable mapping automatically.
Cons:
- Slow Feedback Loop: Frontend deployments take drastically longer because they wait on CM orchestration.
- Difficult Rollbacks: Rolling back a bad frontend deployment often means reverting the entire CM state.
- Lack of DevOps Control: You cannot easily utilize advanced CI/CD testing steps (like Playwright or Cypress) before the frontend deploys.

Decoupled Deployment

Pros:
- Blazing Fast Iteration: Frontend deployments finish in minutes.
- Independent Rollbacks: Revert a bad UI push instantly without affecting the CMS backend.
- Security & Access: Frontend developers don't need access to the Sitecore Cloud Portal to do their jobs.
- Reduced frontend deployment time by 80%
- Enabled parallel FE/BE releases

Cons:
- Manual Configuration: You must manage API keys, webhooks, and environment variables manually.
- Two Pipelines: DevOps teams must monitor two separate deployment streams.

Feature	Coupled (Integrated)	Decoupled (Standalone)
Frontend Deploy Speed	15 - 30+ Minutes	2 - 5 Minutes (small Apps) 5 – 10 minutes (Enterprise Apps)
Rollback Complexity	High (Tied to CM state)	Low (Instant via Vercel/Netlify)
CI/CD Customization	Limited	Unlimited (GitHub Actions, etc.)
Setup Effort	Low (Out of the box)	Medium (Requires manual Env Vars)
Best For	POCs, Sandboxes, Small Teams	Enterprise, Agile Teams, Production

When is Decoupled NOT the Right Choice?

Small teams without DevOps expertise
POCs or hackathons
Projects with minimal frontend changes
Teams heavily reliant on Experience Editor with no FE team

Why Enterprises Prefer Decoupled XM Cloud

While the Coupled deployment model is excellent for a quick Proof of Concept, the Decoupled architecture is the undisputed best practice for production environments.

The core promise of a headless CMS is agility. If your frontend developers are forced to wait for a monolithic backend deployment pipeline just to update a button color, you have lost the primary benefit of headless architecture like Release velocity, Team independence, Parallel development.

Decoupling your deployments aligns perfectly with modern software engineering principles:

Separation of Concerns: The delivery layer (Next.js) and the authoring layer (CM) have different lifecycles and should fail or succeed independently.
Developer Experience (DevEx): Frontend engineers can work entirely within their native tools (Vercel, GitHub) without navigating Sitecore portals.
Risk Mitigation: Isolating the delivery pipeline ensures that an error in a custom backend Sitecore pipeline won't prevent you from pushing a critical UI hotfix to your live website.
Reduce Deployment time more than 70%
Enabled parallel FE/BE releases

Untangle your pipelines, secure your Edge tokens, and let your frontend run free.

Final Thoughts

Decoupling in SitecoreAI is not just an optimization-it’s a mindset shift.

You move from:

-“Frontend as part of CMS”

To:

“Frontend as an independent product”

And that changes everything.

Official Documentation References

To explore the technical specifications of these architectures, refer to the official Sitecore documentation:

Turbocharge Your Content with Sitecore AI Publishing V2

Roshan Ravaliya — Sat, 21 Feb 2026 14:22:20 +0000

If you have worked with Sitecore AI (XM Cloud), you already know:

Publishing performance directly impacts delivery speed and author productivity.
For a long time, Snapshot Publishing (V1) powered Sitecore AI content delivery. It worked but as projects scaled, publishing times increased, CM servers became overloaded, and queues slowed down deployments.

Now, Sitecore introduces a modern, cloud-native approach:

Experience Edge Runtime (Publishing V2)

Let’s explore what changed and why it matters.

The Bottleneck: Publishing V1 (Snapshot-Based)

In Publishing V1, when you publish a page, the CM server performs heavy processing before the content even reaches Experience Edge

Calculated the entire layout.
Resolved all data sources.
Executed Layout Service pipes.
Created a massive, static JSON blob (a "Snapshot") to send to Experience Edge.

The Result: Publishing a simple page update could take minutes. Even a small content change requires rebuilding the entire page structure.

As your site grows:

Layout complexity increases
Datasource relationships multiply
CPU usage on CM rises
Publish queues grow longer

What once took seconds can quickly turn into minutes.

And at scale, this affects both publishing speed and authoring performance.

The Solution: Publishing V2 (Edge Runtime)

Sitecore AI introduced a new way to publish content: Publishing V2 (also known as Edge Runtime mode). It sounds technical, but it’s a beautiful simplification of how data moves.

Publishing V2 changes the architecture entirely.

Instead of pre-calculating the full layout JSON on the CM server, Sitecore now:

Publishes raw item data
Publishes layout references
Defers JSON assembly to the Edge runtime

The final JSON response is assembled dynamically on the Experience Edge delivery layer not on CM.

This shifts the workload from the single CM instance to the massively scalable Edge CDN.

The "Cake" Analogy: V1 vs. V2

To understand the difference, imagine you are sending a cake to a friend.

Publishing V1 (Snapshot):

You bake the cake, frost it, box it up, and ship the entire heavy box.

Technical Translation: Sitecore calculates the entire layout JSON on the CM server and sends a massive static blob to Experience Edge.
Result: Slow and heavy.
If you change one ingredient, you must bake the whole cake again.

Publishing V2 (Edge Runtime):

You just send the recipe and the ingredients. Your friend (Experience Edge) assembles the cake instantly when someone asks for it.

Technical Translation: Sitecore sends only the raw item data and layout references. Experience Edge assembles the JSON at "runtime" when the API is called.
Result: Lightning fast.
You only ship the tiny changes.

Architecture Comparison

V1 Flow (Snapshot Publishing)

CM → Layout Service Processing → Full JSON Snapshot → Experience Edge → CDN → Frontend
Everything is assembled on CM before delivery.

V2 Flow (Edge Runtime)

CM → Raw Items + Layout References → Edge Worker Runtime → JSON Assembly → CDN → Frontend
JSON is assembled at request time by the Edge worker.

Key Advantages of Publishing V2

1). Blazing Fast Publish Times

Since layout JSON is no longer generated on CM, publish jobs typically complete in seconds rather than minutes.

This is especially noticeable on:

Large component-based pages
Sites with heavy personalization
Complex layout structures

2️). Better CM Performance
The CM instance is no longer CPU-bound by layout assembly.

This means:

Better authoring performance
Higher concurrency
Multiple publish jobs can run safely

3️). True Scalability

Processing shifts to the globally distributed Experience Edge runtime designed for high availability and horizontal scaling.

Your publishing performance now scales with Edge infrastructure, not your CM size.

Important Behavioral Change: Strict Dependencies

This is where V2 requires architectural awareness.

In V1:

The snapshot captured fully resolved data at publish time.
Previously resolved data could still exist inside snapshots.

In V2:

JSON is assembled at request time.
If a datasource item is not published, it does not exist in the GraphQL response.

This can result in:

Empty components
Missing navigation items
Incomplete JSON output

Best Practice:

Always use:

Publish Related Items
Or ensure parent and datasource items are included in the publish job.

Caching Behavior in V2

V2 invalidates cache per item ID.

It does not automatically invalidate related items such as:

Parent navigation
Sibling teasers
Shared components

If a shared data source changes, and parents are not published, you may see stale content.

Always plan publish dependency carefully.

How to Implement (The "Switch")

No code changes required. No config patching. No redeployment of frontend.

You can do this directly in the Sitecore AI Deploy Portal

Step 1: Log in to the SitecoreAI Deploy.

Step 2: Select your Project and Environment (e.g., Production, QA, or Development).

Step 3: Go to the Variables tab.

Step 4: Click Create Variable and add the following:

Name: Sitecore_ExperienceEdge_dot_WorkerStoreEnabled 
Value: TRUE
Target: CM

Step 5: Save and deploy your environment.

Step 6: Once deployment completes, Republish all sites in the environment.

Important: Deployment + full republish is required for activation.

To revert to V1:

Change the variable Sitecore_ExperienceEdge_dot_WorkerStoreEnabled to FALSE.
Redeploy the environment
Delete Edge content
Republish all sites

Frontend Impact: The Best News

This is the "sweetest" part of the update.

Do not need to change your Next.js API endpoints.

Even though the backend architecture has completely changed, the Frontend Contract remains the same.

✔ Your Endpoint: Remains https://edge.sitecorecloud.io/api/graphql/v1
✔ Your Query: Remains exactly the same.
✔ Your JSON Response: Look exactly the same.
✔ Require zero refactoring

Why?

The change from V1 to V2 is purely architectural (Backend/Ingestion). It changes how data gets into the Edge, but it does not change Delivery how read it out.

V1: Edge reads a pre-baked JSON blob.
V2: Edge reads references and assembles the JSON blob on the fly.

Real-World Impact

In enterprise implementations, teams have observed:

Homepage publish time reduced from minutes to seconds
Massive reduction in publish queue backlogs
Improved CM responsiveness during large content pushes

For content-heavy, composable architectures, this is a game-changing improvement.

Final Verdict

Publishing V2 (Experience Edge Runtime):

✔ Faster
✔ Lighter
✔ More scalable
✔ No frontend changes
✔ Cleaner architecture

The only requirement?

Be disciplined with publish dependencies.

For most Sitecore AI headless projects, this is a clear upgrade and a rare “win-win” architectural improvement.

Official Documentation

Ready to make the switch? Check out the official guides here:

Closing Thought

Sitecore AI is evolving toward true cloud-native architecture and Publishing V2 is a major step forward.

If you are still on Snapshot Publishing, this is the time to switch.

Happy Publishing.