xCloud and Cloudflare Enterprise

Version 1.3.6 Updated October 26, 2026

Detects and coordinates with xCloud’s own caching layers rather than fighting them. The API connection is off by default. Cloudflare Enterprise purging switches itself on when xCloud’s automatic cache purge plugin is installed, with no token needed (1.3.6 and later).

Why this exists

A site on xCloud can have up to three cache layers GT Performance does not run: xCloud’s host page cache, its free Cloudflare edge cache, and the separate Cloudflare Enterprise add-on. If a plugin also manages a page cache and a Cloudflare rule on top of those, you get purges that do nothing, stale pages that outlive every TTL you set, and two rule sets disagreeing about which paths bypass.

The integration’s job is to establish who owns what, purge the host layers it is allowed to purge, and otherwise stay out of the way.

Connect

On the Integrations tab, in the xCloud and Cloudflare Enterprise panel:

Turn on Enable xCloud cache integration.
Enter an xCloud API token with the read:sites and write:sites scopes. It is encrypted in WordPress, and a blank field on save keeps the saved token.
Optionally set xCloud site domain (blank uses this site’s home domain) or xCloud site UUID (blank is discovered from the exact domain).
Save, then click Connect/refresh xCloud in the xCloud cache status panel that appears.

The token can come from wp-config.php instead, which takes precedence over the saved one:

define( 'GTPERF_XCLOUD_API_TOKEN', '…' );

GTPERF_XCLOUD_API_BASE_URL overrides the API base URL, which defaults to https://app.xcloud.host. See Constants Reference.

What a refresh does

Status is read only when you ask for it. A refresh:

Finds the site by saved UUID, or by an exact match on its primary domain.
Reads the site’s cache settings from the xCloud Public API.
Resolves the numeric server and site IDs the Enterprise add-on uses. These add-on routes are capability-detected because xCloud has not published them in its Public API catalog. If xCloud does not expose them, the refresh fails.
Reads the Enterprise add-on’s traffic for the last 12 hours. The add-on counts as present only when that call answers that it is available.
Saves the results and turns the integration on.

What it reports

The xCloud cache status panel shows:

Field	Meaning
Site	The matched xCloud domain
Stack	The server stack xCloud reports
Page cache	Whether xCloud’s host page cache is on
Redis	Whether xCloud’s Redis object cache is on
Object Cache Pro	Whether Object Cache Pro is on
Cloudflare Enterprise	Active through xCloud or Not detected
Enterprise purge	Automatic, through xCloud’s cache purge plugin, installed but has no usable purge token, or Manual
Last Enterprise purge	When the last Enterprise purge was sent, its result, and how many listing pages were cleared at the origin only
Enterprise edge traffic (12h)	Requests served by Cloudflare, total requests, and the hit percentage
Free xCloud edge cache	Whether xCloud’s free Cloudflare edge cache is on
Last checked	When the status was last refreshed
Last xCloud purge	When host purge routing last ran, including runs that failed or had nothing to purge

When xCloud returns a dashboard link for the site, Open this site in xCloud appears next to the refresh button. If xCloud’s Redis or Object Cache Pro already owns object-cache.php, the Object Cache tab shows the drop-in as owned by another plugin and GT Performance leaves it alone. See Redis Object Cache.

When the last refresh reported xCloud’s host page cache on, Setup counts it as a host page cache and recommends optimize-only mode, where xCloud stores the pages and GT Performance optimizes them. Host purges (below) run in either mode.

The panel also appears without an API token when xCloud’s automatic cache purge plugin is installed.

Edge ownership

xCloud owns the edge when either of these is true:

xCloud’s automatic cache purge plugin (wp-content/mu-plugins/xcloud-cfe-cache-purge.php) is installed with a usable token. No API token is needed.
The API integration is on and xCloud reports the Cloudflare Enterprise add-on or its free edge cache.

While xCloud owns the edge, GT Performance:

stops sending its own automatic Cloudflare purges,
refuses Connect/sync Cloudflare and wp gt-performance cloudflare sync rather than creating a second rule,
and leaves your own Cloudflare zone alone when the plugin is deactivated.

With xCloud’s purge plugin installed, direct Cloudflare is paused, not reported as a conflict. Its settings are kept and it makes no API calls. The Cloudflare tab and connection check say so, and wp gt-performance doctor shows Cloudflare: paused (xCloud Enterprise). Removing the plugin resumes it.

Without the plugin, both owners enabled is a conflict: the status panel shows Resolve edge ownership, and the health report and doctor warn. Disable one or the other.

Cloudflare Enterprise purging

An Enterprise domain is a DNS-only CNAME to xCloud’s edge. Visitors are served from xCloud’s own Cloudflare zone, so a purge on your own Cloudflare zone returns success and clears nothing they receive.

After activation, the site’s Cloudflare Enterprise page in xCloud offers Install now for automatic cache purge. That step installs xcloud-cfe-cache-purge.php in mu-plugins with a per-site token pair. xCloud’s plugin purges a post’s own URLs when the post is saved, and nothing else.

GT Performance 1.3.6 and later look for that file. When it is present with a usable token, every GT Performance purge is also sent to xCloud’s endpoint:

related and archive pages after a post save, unpublish, trash or comment
Page Blocks, theme and menu edits that GT Performance purges
Purge GT cache, the admin-bar purges and scheduled purges
wp gt-performance cache purge and the AI abilities

How the requests are sent:

Situation	What goes to xCloud
Up to 300 URLs	The URLs and their query-string copies, in batches of 50
More than 300 URLs from a post change	Only the post’s own URLs: permalink, home, post type archive, author archive and current term archives. Recorded listing pages are cleared at the origin only and refresh at the edge when their copies expire
More than 300 URLs from anything else, or a full purge	One whole-site Enterprise purge

xCloud drops a merged purge of more than 300 URLs rather than purging part of it, which is why the limit exists.

Automatic purges are sent at the end of the request without waiting for xCloud, the same way xCloud’s plugin sends them. Purge GT cache, Purge and verify this URL, wp gt-performance cache purge and the abilities wait for xCloud’s reply and report a rejection.

The endpoint must be HTTPS on an xcloud.host hostname, so a changed constant cannot send the tokens anywhere else. To keep GT Performance out of Enterprise purging with the plugin installed, return false from the gt_performance_xcloud_enterprise_purge filter. See Hooks Reference.

Host cache purging

After every GT Performance origin purge (a URL purge or a full purge), the integration sends at most one host purge per request, chosen from the last refreshed state:

xCloud state	What GT Performance does
Cloudflare Enterprise detected, no purge plugin	Nothing. Fails closed and records the reason (see below).
Cloudflare Enterprise detected, purge plugin installed	The host page cache when it is on. Enterprise is purged separately, as above
Free edge cache on	Purges all host cache layers for the site, including the free edge cache
Host page cache on	Purges only the host page cache, without flushing object caches
Neither	Nothing to purge

These are site-wide host purges: GT Performance does not send individual URLs to xCloud. The result is recorded as Last xCloud purge. With Diagnostic logging on, failures are also written to the plugin’s diagnostic log.

Without the purge plugin, Enterprise purge is manual

The xCloud Public API token can read Enterprise analytics but cannot purge the Enterprise layer. Without xCloud’s purge plugin, GT Performance fails closed instead of sending a broad host purge-all request. Install automatic cache purge from the site’s Cloudflare Enterprise page in xCloud, or use its Purge control.

That produces a specific symptom: an origin purge succeeds, and the copy visitors receive does not change, because it is held by a layer your token cannot address. Verify a true origin render with a cache-busting query parameter rather than re-fetching the bare URL (see Cloudflare), then purge Enterprise from the xCloud dashboard. See Troubleshooting.

Keep commerce HTML out of Enterprise page caching

When the Enterprise add-on is detected, the status panel warns: keep xCloud Enterprise Edge Page Caching off unless xCloud provides request-level bypass rules. Live testing found its page-cache rule overrides origin no-store directives and caches cart, checkout, account, and receipt HTML. Enterprise static caching, WAF, and the add-on’s other features can stay on. See Commerce Safety.

WP-CLI

wp gt-performance xcloud            # status (default): saved state, no API call
wp gt-performance xcloud refresh    # query xCloud and save the results
wp gt-performance xcloud purge      # purge Enterprise, then the host cache
wp gt-performance xcloud purge --page-url=https://example.com/pricing/

xcloud status includes enterprise_purge=xcloud-plugin, unusable (the file is present without a usable token, or the filter turned it off) or not-installed. With the purge plugin, xcloud purge clears Enterprise first, the whole site or one page with --page-url, then the host cache when an API token is connected. Without it, xcloud purge fails with the Enterprise message when the add-on is detected. See WP-CLI.

Settings history

xCloud settings are never exported, imported, or restored by settings history. See Tools.