Integrations — Vercel routing and microfrontends for Sitecore XM Cloud

Introduction

On many Sitecore XM Cloud projects today, Vercel + Next.js is a no brainer / go to way to ship the front end. What is less obvious is just how much can be actually done with Vercel’s routing layer and microfrontend patterns before we reach for external routing like Azure Front Door or a legacy reverse proxy.

In this post I’ll walk through:

• when to rely on Vercel-native routing versus putting Azure Front Door (or similar) in front,
• how to structure microfrontends for XM Cloud using Vercel’s multi‑zone patterns and templates from the official Microfrontends documentation,
• how microfrontends let you run multiple independent projects — including non‑Next stacks and multiple CMSs — under one domain,
• what latency and cost look like in both routing patterns, with realistic ballpark numbers,
• and how to wire CI/CD so each microfrontend can be deployed independently without breaking the overall experience.

Everything here assumes a typical XM Cloud + Next.js setup (App Router or Pages Router) deployed to Vercel, but the patterns generalize to other React/Vue heads as well.

The two routing patterns I reach for

For an XM Cloud estate with several sites (for example several product or brand sites) and a legacy website or CMS, I keep two routing options in mind.

Vercel as the primary router

In the “Vercel‑only” pattern, DNS points directly at Vercel’s edge network and Vercel’s routing layer decides which app serves which path.

Key traits of this pattern in my projects:

• One edge hop: DNS → Vercel Edge → origin (Next.js functions or static assets).
• Path‑based routing: vercel.json and the Vercel dashboard route /brand-a/** and /brand-b/** to one project, /brand-c/** and /brand-d/** to another, and everything else to a legacy origin.
• Tight integration with Next.js: rewrites, middleware, caching, and incremental static regeneration (ISR) all live in the same place I define routes and layouts.
• Good default for most XM Cloud projects when I am happy for web traffic to be anchored on Vercel.

This is also where Vercel’s official Microfrontends guidance fits best: I can split by path into multiple apps (the “multi‑zones” starter) or use frameworks like single‑spa, while Vercel manages the edge routing.

Azure Front Door (or similar) in front of Vercel

In more regulated or multi‑cloud environments, I see teams put Azure Front Door (AFD), Cloudflare, or another global entry point in front of Vercel.

In that setup:

• DNS points to Azure Front Door, which provides web application firewall, DDoS protection, and global load balancing.
• AFD forwards traffic to various origin groups, which can include several Vercel Edge domains, legacy CMSs, portals, or on‑prem gateways.
• Vercel still performs Next.js‑level routing, caching, and ISR behind AFD.

This pattern is useful when:

• security teams want all external traffic to land on Azure (for unified rules, private links, and logging),
• you need to front not only Vercel, but also API Management, App Services, and other Azure‑native workloads,
• you are mid‑migration and expect to keep non‑Vercel origins for a while.

Configuring routing on Vercel and Azure Front Door

You do not need anything exotic to configure these patterns; they mostly use standard routing features in Vercel and Azure Front Door.

Vercel routing and rewrites

For a Vercel‑only setup:

• Per‑project routing

  • Each project has its own routes defined by Next.js (App Router or Pages Router).
  • You can add rewrites, redirects, and headers in next.config.js (rewrites(), redirects()) or via the Vercel dashboard.
  • Vercel’s Microfrontends docs and the Next.js Multi‑Zones guide walk through how to split a domain into multiple apps and configure their routes.

• Edge rewrites and middleware

  • Vercel’s routing layer supports rewrites between apps and to external origins using vercel.json or project‑level settings.
  • You can add Middleware in middleware.ts for cross‑cutting concerns (geofencing, A/B tests, auth) that run at the edge before the request hits your app.
  • Look for the “Routing” and “Middleware” sections in the Vercel and Next.js docs for concrete configuration examples.

For the microfrontends examples in this post, the key idea is:

• map /brand-a/* and /brand-b/* to one Vercel project,
• /brand-c/* and /brand-d/* to another project,
• and configure rewrites for any routes that need to jump to a legacy CMS or API.

Azure Front Door routes and origins

For the Azure Front Door → Vercel pattern:

• Create an endpoint and routes

  • In the Azure portal, create an Azure Front Door Standard/Premium instance and endpoint.
  • Add routes with patterns like /brand-a/*, /brand-b/*, /brand-c/*, /brand-d/*, and a catch‑all route for everything else.
  • Point each route at an origin group that contains the appropriate Vercel project or legacy origin.

• Define origins and health probes

  • For each Vercel app, add an origin using its Vercel domain (for example brand-a-example.vercel.app).
  • Configure health probes so Front Door can fail over if an origin is unavailable.
  • Use origin groups to bundle related apps (for example “marketing sites” vs “portal/API”).

• Documentation to follow

  • Azure’s official tutorials on creating a Front Door Standard/Premium profile, configuring routes and origins, and adding a custom domain show the exact clicks and ARM/Bicep examples.
  • The billing and pricing page you already saw is complemented by a “billing meters” doc that explains how request and bandwidth meters are calculated.

Once routes and origins are in place, the pipeline looks like this:

• DNS points example.com to Azure Front Door.
• Front Door matches the path and forwards to the right Vercel origin or legacy CMS.
• Behind that, Vercel and Next.js still handle page‑level routing, ISR, and caching as usual.

Latency and cost: some concrete numbers

Routing choices are easier when you anchor them in numbers. These examples are illustrative ballparks, not vendor SLAs — always validate with your own tests and pricing calculators.

Network hops and latency

Consider a user in London hitting cws.com:

• Vercel‑only pattern

  • DNS → Vercel Edge PoP in the UK or nearby EU region.
  • Static/ISR pages are served directly from that PoP.
  • For cached pages, real‑world TTFB is often in the 40–80 ms range.

• Azure Front Door → Vercel pattern

  • DNS → nearest AFD PoP.
  • AFD forwards to the nearest Vercel PoP that can serve the content.
  • You now have two TLS terminations and routing decisions instead of one.
  • In practice, you often add 20–40 ms of overhead per request versus Vercel‑only, depending on regions and cache hits.

If your XM Cloud pages are mostly static or ISR and you care about every millisecond on marketing sites, that extra hop matters.
For authenticated portals or heavy API calls, the difference is usually overshadowed by app logic.

Azure Front Door pricing vs Vercel

As of writing, the Azure Front Door pricing page shows (Standard tier):

• Base fee: approximately $35/month for the service itself.
• Request pricing (per 10,000 requests) in North America and Europe:
  • Standard: $0.009 per 10,000 requests (Zone 1 and 6).
  • Premium (includes WAF/Private Link): $0.015 per 10,000 requests.
• Data transfer out to clients: varies by zone and volume, but think $0.06–$0.10/GB for the first tens of TB in many regions.

For a mid‑size XM Cloud estate doing 50 million requests/month and 2 TB egress from Front Door to clients:

• Standard AFD base fee: $35.
• Requests: 50,000,000 / 10,000 * 0.009 ≈ $45.
• Egress: 2,000 GB * ~$0.07 ≈ $140.
• Rough total: $220/month, before origin egress and any additional Azure services.

On Vercel Pro, pricing is mostly plan‑based:

• The Vercel pricing page currently shows Pro at around $150/month (for a project with the default quota).
• That includes a bundle of bandwidth and compute (edge function and SSR invocations).
• Above that quota, you pay per GB of bandwidth and per 1,000 edge/SSR invocations.

The actual break‑even point depends heavily on:

• whether you already pay for Azure anyway (and want to reuse AFD/WAF),
• how much non‑Vercel traffic must pass through the edge,
• and whether you would run Vercel Pro or Enterprise regardless.

Rule of thumb:

• If you only front a handful of Vercel apps and you are already paying for Pro, the incremental cost of letting Vercel handle routing is usually lower and simpler.
• If your organization standardizes on Azure‑first networking and front‑doors many apps and APIs, the incremental cost of adding a few more origins for XM Cloud is relatively small.

Microfrontends on Vercel for XM Cloud

With routing in place, the next question is how to carve the estate into microfrontends.

Vercel’s Microfrontends documentation and templates highlight three useful patterns:

1. Multi‑zones — split a domain by path into multiple Next.js apps.
2. Module Federation / build‑time composition — share components across apps, often via Turborepo.
3. Framework‑agnostic shells — compose React, Vite, or single‑spa apps in the browser.

XM Cloud works well with all three.

Path‑based microfrontends with Multi‑Zones

Multi‑zones is the simplest pattern and tends to be my default for XM Cloud:

• You create multiple Next.js apps, each responsible for a slice of the URL space:
  • /brand-a/** → apps/brand-a
  • /brand-b/** → apps/brand-b
  • /brand-c/** → apps/brand-c
  • /brand-d/** → apps/brand-d
• Vercel’s routing layer (via vercel.json or the dashboard) maps those paths to the correct app.
• Each app talks to its own XM Cloud instance or site definition via Experience Edge.

Benefits:

• Independent deployments: a change in apps/workwear only rebuilds and redeploys that app.
• Clear ownership: each product line or region has its own app and team.
• Fail‑fast: a bad deploy in one app rarely affects others beyond shared assets.

This corresponds directly to the Next.js Multi‑Zones Starter template that Vercel publishes for microfrontends.

Component‑level microfrontends

Sometimes you want to go finer‑grained than “one app per path”. For example:

• a shared global header and footer across all sites,
• a React checkout widget embedded into a mostly static marketing site,
• or a logged‑in account microfrontend mounted inside multiple marketing shells.

In those cases you can:

• Use Module Federation (Webpack) or a shared UI package in a Turborepo to publish components once and consume them across apps.
• Or use single‑spa / Web Components to compose microfrontends client‑side.

Vercel is agnostic here: you deploy each app as usual; the composition is handled by your build config or runtime framework.
From an XM Cloud perspective, the important part is that:

• XM Cloud content is still delivered via Experience Edge or Content SDK in each app.
• Route mapping stays clear so that personalization, analytics, and sitemaps still make sense.

Cross‑stack microfrontends (multiple CMSs, multiple stacks)

One of the more powerful patterns is to mix stacks and CMSs under one domain:

• Marketing and campaigns: XM Cloud + Next.js microfrontends.
• Product docs: Content Hub or headless CMS + Next.js (or Vite) app.
• Customer portal: React or Vue SPA backed by Azure AD and custom APIs.
• Legacy microsites: a legacy CMS or website behind a reverse proxy.

Vercel’s routing and microfrontends story allows you to:

• Serve Next.js apps from a monorepo,
• Proxy legacy stacks via rewrites to external origins,
• And still keep everything under a single domain (for example example.com) without a tangle of nested iframes.

When Vercel is the main edge router, you configure:

• rewrites for paths that belong to Next.js apps,
• proxy style rewrites for paths that belong to external CMSs or portals,
• and shared middleware for concerns like cookies, A/B routing, or geofencing.

If Azure Front Door sits in front, it will route by top‑level path and hostname to the right Vercel or non‑Vercel origin, and Vercel handles the microfrontends for the origins it owns.

Monorepos and independent deployments

Microfrontends are much easier to manage in a monorepo with clearly separated apps and shared packages.

A typical structure for an XM Cloud estate might look like:

apps/
  marketing-brand-a/
  marketing-brand-b/
  marketing-brand-c/
  marketing-brand-d/
  account-portal/
packages/
  ui/
  design-tokens/
  xm-cloud-content/
  analytics/

Patterns that work well here:

• Use Turborepo (or Nx) for incremental builds and shared tooling.
• Each app is a separate Vercel project with its own environment variables (XM Cloud endpoints, keys, feature flags).
• Shared packages (ui, xm-cloud-content) are versioned within the monorepo and imported via normal Node resolution.

Deployment behavior:

• A commit that only touches apps/marketing-brand-a and packages/ui will only rebuild the impacted apps.
• Vercel’s remote cache and monorepo support keep CI fast, even with many apps.
• You can map branches to environments:
  • main → production
  • develop → staging
  • feature branches → Preview Deployments that still honor the same microfrontends routing.

From XM Cloud’s point of view, each app is just another consumer of Experience Edge; serialization and SCS workflows stay in your XM Cloud repo(s) and pipelines.

Serving multiple independent projects and CMSs

The real strength of this approach is that you can serve multiple independent projects from a single monorepo and even multiple CMSs and stacks under one domain.

Examples I see in practice:

1. XM Cloud multi‑tenant estate

   • apps/marketing-brand-a talks to an XM Cloud instance dedicated to Brand A.
   • apps/marketing-brand-b talks to an XM Cloud instance dedicated to Brand B.
   • Each has its own SCS project and item tree.
   • Both share a ui library and some layout patterns, but deploy independently.

2. XM Cloud + Content Hub + third‑party CMS

   • /products/** is served by a Next.js app hitting Content Hub GraphQL directly (no sync), as described in the Content Hub GraphQL post.
   • /stories/** is served by an XM Cloud‑backed marketing app.
   • /help/** is a docs app backed by a separate headless CMS.
   • Routing between them is handled purely at the edge (Vercel or AFD).

3. Next.js + non‑Next stacks

   • /portal/** is a React SPA deployed as a static export to Vercel or as a separate origin behind Front Door.
   • /config/** is a small Hono or Nitro microservice deployed as a backend microfrontend (as in Vercel’s SaaS microservices template).
   • Everything still appears as a single coherent site from the user’s point of view.

Because each microfrontend is its own deployable app, you can:

• manage separate lifecycles (XM Cloud instance upgrades, CMS migrations),
• introduce new stacks incrementally,
• and retire legacy systems path by path.

CI/CD for XM Cloud microfrontends

The last piece is wiring CI/CD so teams can move fast without breaking routing or content.

Vercel‑centric pipeline

For apps deployed to Vercel:

• Use GitHub or Azure DevOps as the source of truth.
• Hook Vercel projects to specific directories in the monorepo (apps/marketing-workwear, etc.).
• Let Vercel handle:
  • build and deploy on every push,
  • environment promotion (Preview → Production),
  • and per‑project environment variables.

For XM Cloud:

• Keep serialization in a separate repo or in an /authoring folder of the monorepo.
• Use XM Cloud Deploy and your existing pipelines (YAML or GitHub Actions) to push SCS changes to environments.
• Configure Experience Edge environments and tokens as Vercel environment variables.

In this setup:

• Most UI‑only changes trigger only Vercel builds.
• Schema and content structure changes go through XM Cloud pipelines.
• You can still coordinate releases via tags or environment locks when necessary.

Azure‑centric pipeline with Front Door

If Azure Front Door is the primary entry point:

• You still deploy front ends to Vercel, but add:
  • Infrastructure as code (Bicep/Terraform) to manage AFD routing rules and WAF policies.
  • Release stages in Azure DevOps or GitHub Actions to roll out new origins and routes.
• When you spin up a new microfrontend:
  • Create a new Vercel project and environment.
  • Add an Azure Front Door origin and route to point to that Vercel domain.
  • Gradually shift traffic (weighted routes) if you are replacing an existing site.

This pattern is slightly more complex but gives you:

• centralized edge security and logging in Azure,
• better alignment with network/security teams,
• and the ability to front non‑Vercel workloads in the same way.

When to choose which routing pattern

To decide between “Vercel‑only” and “Azure Front Door → Vercel”, I would ask:

• Is Vercel already the strategic edge platform for web?

  • Yes → lean toward Vercel‑only routing; keep architecture simple.
  • No, we standardize on Azure/Cloudflare → strongly consider putting XM Cloud behind that.

• Do we have many non‑Vercel origins under the same hostname?

  • Yes (APIs, portals, legacy apps) → an external front door is often worth the extra hop.
  • No → Vercel’s rewrites and proxies usually cover what you need.

• Are we extremely latency‑sensitive on marketing pages?

  • Yes → avoid extra hops; Vercel‑only routing plus good caching/ISR.
  • No → the additional 20–40 ms of a front door is often acceptable for the security and governance it delivers.

• How mature is our platform governance?

  • Strong Azure governance, central WAF, and SOC that lives in Azure → Front Door fits better.
  • Smaller teams or greenfield builds → Vercel‑only is easier to own end‑to‑end.

In both cases, I tend to lean towards microfrontends with:

• clear path and ownership boundaries,
• independent deployments,
• and shared design systems and analytics.

Practical recommendations for XM Cloud teams

If you are planning or refactoring an XM Cloud estate with Vercel:

• Start with Vercel-only routing unless you have a strong Azure governance requirement.
• Use Multi-Zones and a monorepo to split the domain by path into separate Next.js apps.
• Treat each app as a microfrontend with its own owner, pipeline, and XM Cloud site or CMS backend.
• Reuse shared UI and content access packages instead of sharing routes or Next.js config.
• When regulatory or security needs push you toward Azure Front Door, keep composition the same — just move the “first hop” to Azure.

Done well, this gives you:

• the developer experience of Vercel + Next.js + XM Cloud,
• the operational clarity of microfrontends and monorepos,
• and the option to scale up to enterprise-grade routing and security without rewriting everything later.

Useful links

• Vercel — Microfrontends overview and templates — https://vercel.com/docs/microfrontends
• Next.js — Multi-Zones deployment guide — https://nextjs.org/docs/app/building-your-application/deploying/multi-zones
• Vercel — Routing concepts and configuration — https://vercel.com/docs/routing
• Azure Front Door — Service overview — https://learn.microsoft.com/azure/frontdoor/front-door-overview
• Azure Front Door Standard/Premium — Create a Front Door profile and configure routes/origins — https://learn.microsoft.com/azure/frontdoor/standard-premium/how-to-create-front-door

Related posts

• AI-Powered Stack — Series overview and roadmap
• AI-Powered Stack — My Sitecore delivery stack for 2025
• AI-Powered Stack — Sprint zero for XM Cloud with agentic AI
• AI-Powered Stack — From Signed SOW to Sprint One
• AI-Powered Stack — Fast POCs from prompt to XM Cloud components