Skip to Content

How to Host SitecoreAI in China

Piers Matthews

Why a China footprint turns SitecoreAI hosting into an infrastructure problem, and what has to be true to solve it.

Most conversations about entering the Chinese market start with the storefront, the localization plan, the go-to-market timeline. They rarely start with hosting. That's usually where things get complicated.

Here's the pattern we keep seeing: a global enterprise headquartered in Sydney, Chicago, London or wherever builds out a subsidiary, a retail presence or a customer base in China. At some point, someone on the platform team asks a question nobody planned for: where is this actually going to be hosted?

And the honest answer is that the infrastructure most SitecoreAI deployments run on wasn't built to operate inside Chinese borders.

This isn't a China-market problem. It's a global-enterprise-with-a-China-footprint problem. Different thing entirely.

Why the usual playbook doesn't travel

SitecoreAI's pull is obvious: AI-powered personalization, composable architecture, next-generation digital experience and agentic capabilities. Teams already running it elsewhere want the same thing for their China-facing properties. Reasonable expectation. Wrong assumption.

A standard SitecoreAI deployment runs into three hard constraints the moment it targets a China-based audience:

  • Transactional and personal data must stay in-country. It has to be stored and processed locally, including any data capture or interactivity.
  • SitecoreAI's global infrastructure doesn't operate in China. The cloud backbone that makes SitecoreAI fast and reliable everywhere else isn't available inside Chinese borders, so every call crosses slow cross-border links and the site becomes unusable for visitors. Same platform, different physics.
  • Standard front-end hosting tools weren't built for this. Most platforms have no answer for what China requires, because they were never asked to operate under these constraints.

None of this is a SitecoreAI problem. It's an infrastructure problem sitting one layer below it, and it's the layer most teams don't think about until they're already committed to the platform decision.

What actually has to be true for this to work

Arc by Dataweavers runs entirely inside the customer's own Azure tenant, on local China infrastructure, Azure and Cloudflare, with Next.js hosting, built-in governance and six-layer security, all under a single SLA from code release to end-customer experience. In-country, compliant, operational from day one. No separate vendor relationship to manage for the China piece, no bolt-on workaround.

Arc delivers this through Full In-Country Hosting, which puts compute, data and delivery inside China's borders. Next.js is deployed to an in-country Azure region, with content and media requests routed through Arc's accelerated proxy so they perform reliably and media is served from a local cache. It's the full-sovereignty path, and it comes with a real prerequisite: your organization needs to hold a local business license in-region to run it.

None of this asks you to rebuild your SitecoreAI investment from scratch. That's the point.

The three gaps nobody else is answering

Deploying SitecoreAI headless in China surfaces infrastructure gaps that most platforms simply leave for the customer to figure out. We'd rather name them upfront:

  1. Sitecore Experience Edge isn't hosted in-country, so the Arc proxy uses our accelerated network links to dramatically improve the performance and stability of your Experience Edge queries.
  2. Media served from Experience Edge or Content Hub DAM is cached locally, as requests are directed through the head layer across our proxy path.
  3. The Sitecore Portal itself is inaccessible in-region, which is why we recommend a customer-managed VPN for local content authors.

Each of these is a known quantity with Arc. Left unaddressed, they're the kind of gaps that turn a straightforward SitecoreAI rollout into a six-month infrastructure investigation.

The actual question worth asking

If your organization is planning a China-facing SitecoreAI deployment, or already has one running on infrastructure that's quietly out of compliance, the question isn't whether you need in-country hosting. It's which model gets you there without slowing down everything else your platform team is trying to ship.

We've built Arc specifically to answer that, and we're always happy to walk through which option fits your architecture. Reach out to hello@dataweavers.com or fill out our contact form to chat.

Answers to your questions

Can SitecoreAI run inside China?

Not on its standard global infrastructure. The cloud backbone that makes SitecoreAI fast and reliable elsewhere doesn't operate inside Chinese borders, so every call crosses slow cross-border links and the site becomes unusable for visitors. A China-facing deployment needs its head layer hosted in-country.

What data has to stay in China?

Transactional and personal data must be stored and processed in-country, and that includes any data capture or interactivity on the site.

What is Full In-Country Hosting with Arc?

It's the full-sovereignty path. Arc by Dataweavers puts compute, data and delivery inside China's borders: Next.js is deployed to an in-country Azure region, and content and media requests are routed through Arc's accelerated proxy, with media served from a local cache.

Do we need a local business license to host in China?

Yes. Full In-Country Hosting requires your organization to hold a local business license in-region.

Can content authors use the Sitecore Portal from inside China?

The Sitecore Portal is inaccessible in-region, so we recommend a customer-managed VPN for local content authors.

Do we have to rebuild our SitecoreAI implementation for China?

No. Arc runs inside your own Azure tenant alongside your existing SitecoreAI investment, under a single SLA from code release to end-customer experience.