How to purge the Cloudflare cache from Magento automatically

Edge caching only works if the edge forgets a page the moment Magento does. With OCM Labs Cloudflare, a free and open source Magento module, a product save ends with Cloudflare dropping every page that carried that product's cache tags. Install and zone setup are in post 1; turning edge caching on is post 2.

What triggers a purge

The module listens to the events Magento's own cache invalidation uses:

A tag purge sends exactly the tags Magento cleaned, with one exception. Every page carries store_* and website_* tags, and those are left out: purging store_1 would wipe the whole site on every save. The usual Magento cache flush habit still works, too. Flush the full page cache from Magento cache management and Cloudflare is flushed with it.

Pick a purge mode

Open Stores > Configuration > OCMLabs > Cloudflare > Purging (default scope).

1. By cache tag (recommended). The tags go to Cloudflare's purge-by-tag endpoint, and Cloudflare removes every cached page whose Cache-Tag header carried one of them. Works on every plan. Leave Purge Mode here unless step 2 applies.
2. By URL. For setups where something between Magento and Cloudflare strips the Cache-Tag header. Product tags (cat_p_<id>) resolve to the product URL on each store of the website plus configurable parents, category tags (cat_c_<id>) to the category URL and its paginated pages, CMS page tags (cms_p_<id>) to the page URL. A tag that resolves to more than Max URLs per Tag (500 by default), or one with no URL mapping such as cat_c_p_*, purges everything instead. The total is capped at 5000 URLs per run.
3. Purge everything. Every invalidation purges the whole zone. Simple, and the edge is cold after every product save.

How the queue works

With Purge Asynchronously on (the default), the observers never call Cloudflare. They publish a message to the ocmlabs.cloudflare.purge queue on Magento's built-in db connection, no RabbitMQ needed, and the ocmlabsCloudflarePurge consumer does the sending. Saving a product never waits on the Cloudflare API, and an API outage never breaks an admin save.

The consumer is a batch consumer. Everything that queued up since the last run is merged into one pass: duplicate tags are dropped, tags for the same zone are grouped, and each group is sent in chunks of 100 items, Cloudflare's limit per request. A catalog import that cleaned ten thousand tags becomes a hundred API calls, not ten thousand.

If more than 20 messages are waiting for one zone, the consumer collapses the backlog into a single purge-everything request, logged with the trigger backlog_collapse. One cold cache costs less than hours of queued tag purges.

Set Purge Asynchronously to No and the purge runs inside the request that triggered it, so a slow or unreachable API delays the admin save. Keep it on unless you have a reason not to.

Run the consumer

The queue goes nowhere until the consumer runs.

Option 1: Magento cron. If app/etc/env.php has no cron_consumers_runner key, Magento's cron starts every registered consumer, this one included. To scope it:

'cron_consumers_runner' => [
    'cron_run' => true,
    'max_messages' => 10000,
    'consumers' => ['ocmlabsCloudflarePurge'],
],

Option 2: a process supervisor. Run it as a long-lived process under supervisord or similar:

bin/magento queue:consumers:start ocmlabsCloudflarePurge --max-messages=10000

To verify, open System > Cloudflare > Dashboard > Health. The "Purge queue consumer" check compares the last cache clean event with the last completed purge and warns when the queue is falling behind.

Rate limiting per plan

Cloudflare limits purge requests per zone, and the limit depends on the plan. The module keeps a local token bucket per Cloudflare account, sized to the plan it detected, and spends one token per 100-item request:

When the bucket is empty the consumer stops, re-queues only the items it has not sent yet, and tries again on its next run. When Cloudflare answers 429 Too Many Requests, the module blocks the bucket for the Retry-After period it was given. Tags wait in the queue; they are never dropped. On a Free zone a large import can take a few minutes to purge fully.

Read the purge log

Every purge lands in System > Cloudflare > Purge Log (ACL resource OCMLabs_Cloudflare::purge_log). Each row shows when it ran, the zone and website, the mode (tag, URL, prefix or everything), the trigger, the item count, the status (success, failed or queued), the API call duration and Cloudflare's request ID for support tickets. Open a row to see the items and, for a failed purge, the error Cloudflare returned with the token redacted. Failed and queued rows have a Retry action. Rows older than 30 days are deleted by a nightly cron.

Quick purge from the dashboard

The Overview tab has a quick purge panel for the selected website. Paste cache tags, URLs or prefixes (host plus path, for example www.example.com/catalog) one per line, or purge everything. These purges skip the queue and run immediately. The admin user needs the OCMLabs_Cloudflare::purge ACL resource, granted under System > Permissions > User Roles.

Purge from the command line

The same four forms exist as a command. It skips the queue and logs each purge with the trigger cli:

bin/magento ocmlabs:cloudflare:purge --tag=cat_p_12 --tag=cat_c_3
bin/magento ocmlabs:cloudflare:purge --url=https://www.example.com/some-product.html
bin/magento ocmlabs:cloudflare:purge --prefix=www.example.com/catalog
bin/magento ocmlabs:cloudflare:purge --all

--all cannot be combined with the others. --url takes absolute http(s) URLs. --tag purges only the websites the tags belong to. --website=<code> (repeatable) limits the run; without it the command covers every website with a zone. Exit code 1 means a Cloudflare call failed, 2 means bad input.

Purging in a deploy pipeline

Purge after static content is deployed, not before:

bin/magento setup:static-content:deploy
bin/magento ocmlabs:cloudflare:purge --all

Because the command exits 1 on an API failure, a set -e deploy script stops instead of finishing with a stale edge. Every option is on the purging and CLI reference docs pages.

Pages are stale after a product save

Work through these in order:

1. The consumer is not running. Purges are queued by default and go nowhere until ocmlabsCloudflarePurge runs. The "Purge queue consumer" health check and the purge log (rows stuck at queued) both show it.
2. Rate limited. On a Free zone only five purge requests a minute go out. A large import takes minutes to drain; the purge log shows batches arriving. Nothing is lost.
3. Cache-Tag never reached Cloudflare. Tag purges only work if Cloudflare stored the page with its tags. If something strips Cache-Tag before the edge, switch Purge Mode to By URL, or fix the proxy.
4. The browser cached it. If curl is fresh but the browser is stale, the zone's Browser Cache TTL overrides the module's max-age=0; set it to Respect Existing Headers.

To confirm a purge took, run curl -sI https://www.example.com/some-product.html | grep -i cf-cache-status twice. The first response after a purge shows MISS, the second HIT.

If you would rather have someone set up the queue, the consumer and the deploy step, our performance and infrastructure team does this on Magento stores behind Cloudflare.