OCM Labs Cloudflare: free edge caching for Magento, on Magento's own terms
A free, open-source Magento module that caches storefront HTML at the Cloudflare edge using Magento's own full page cache rules, and purges by cache tag.

Put a Magento store behind Cloudflare and look at the response headers on a category page. Most of the time you will see cf-cache-status: DYNAMIC. Cloudflare is caching your CSS, JavaScript and images, and passing every HTML request straight through to the origin. The orange cloud is on, and the speed gain on the pages that matter is close to nothing.
OCM Labs Cloudflare is a Magento module that changes that. It is free, open source under OSL-3.0, and it ships today as version 1.0.0.
composer require ocmlabs/module-cloudflareWhy "Cache Everything" is the wrong fix
The usual answer to DYNAMIC is a cache rule that caches everything. It works until the first shopper reaches checkout and gets the cart of whoever got there before them. A logged-in customer's name and group prices end up in the cached copy of a product page, and the admin starts serving stale stock. Magento sets session and context cookies on exactly the pages that must not be shared, and a blanket rule ignores all of them.
Magento already knows which pages are safe to cache. Its full page cache only stores a page when every block on it is cacheable, the request is a GET, no bypass condition applies and the response does not set a context cookie. The stock Varnish VCL encodes the same decision. The problem is that nobody has been sending that decision to Cloudflare.
What the module does instead
The module reuses Magento's decision. A page the built-in full page cache would store leaves the origin with Cache-Control: public, max-age=0, s-maxage=<ttl> and a Cache-Tag header built from the page's Magento cache tags. Everything else, meaning bypass paths like checkout and customer account, POST requests, and any response that sets a store, currency or login context, is sent with private, no-store. The session cookies Magento's own Kernel and VCL strip (PHPSESSID, form_key, private_content_version and friends) are stripped from cacheable responses too.
Browsers get max-age=0 on HTML, so returning visitors revalidate with Cloudflare and a purge reaches them as well.
Edge caching is off by default. Until you turn it on, every storefront response is marked no-store, which also means a zone that already has a "Cache Everything" rule cannot cache HTML by accident once the module is installed.
Purges that follow Magento's invalidation
A cached page is only useful if it goes away when the product behind it changes. The module listens to the same events Magento's cache invalidation uses, so saving a product, category, CMS page or block purges Cloudflare by the tags Magento cleaned. Flushing the full page cache in the admin purges the zone.
Purges go through a queue. Observers publish a message, the ocmlabsCloudflarePurge consumer sends it, and an admin save never waits on the Cloudflare API. The consumer batches whatever has queued up since its last run: duplicate tags are dropped, tags are grouped per zone, and each group goes out in chunks of 100, which is Cloudflare's limit per request. A catalog import that cleaned ten thousand tags becomes a hundred API calls. If more than 20 messages are waiting for one zone, the backlog collapses into a single purge-everything.
Cloudflare's purge rate limit depends on the plan, so the module keeps a local token bucket sized to the plan it detected. On a Free zone that is 5 purge requests a minute. When the bucket is empty the consumer stops, re-queues what it has not sent and tries again on the next run. Tags wait; they are never dropped. Every purge lands in a log under System > Cloudflare > Purge Log with the trigger, the items, the status and Cloudflare's request ID.
The rest of the module
Recommended cache rules, written for you. Open the Health tab and click Apply recommended cache rules, or run bin/magento ocmlabs:cloudflare:rules:apply. You get a diff first. The module only touches rules whose name starts with [OCMLabs], so anything you wrote yourself stays where it is.
25 health checks. They run hourly from cron and on demand, from the admin or from bin/magento ocmlabs:cloudflare:health. The checks cover the API token, the zone settings that break Magento (Rocket Loader, Email Obfuscation, Flexible SSL, Always Online, a Browser Cache TTL override), the cache rules, the Magento side (cache type enabled, consumer running, theme detected), and live probes that fetch your storefront through Cloudflare and read cf-cache-status. A category page should HIT on the second request, the login page should never HIT. Each result carries the message, the fix and the raw evidence it looked at. The command exits 1 when anything fails, so it can gate a deploy.
Cloudflare analytics in the admin. Requests, cache hit ratio, bandwidth, status codes and top paths, pulled from Cloudflare's GraphQL API into a tab under System > Cloudflare.
Real visitor IPs. With Trust CF-Connecting-IP on, Magento uses the visitor's real address for orders, fraud checks and admin allowlists. The header is only honored when the TCP peer is a Cloudflare address, checked against Cloudflare's published ranges, refreshed daily with a bundled fallback. A request that reaches the origin directly cannot spoof it.
Varnish behind Cloudflare. Stock Magento VCL rewrites Cache-Control to no-cache and strips the tag header on the way out, so Cloudflare in front of Varnish sees nothing to cache. The module exports a Cloudflare-aware VCL with bin/magento ocmlabs:cloudflare:vcl:export. It is Magento's generated VCL with two changes, and the edge then caches what Varnish caches.
Plans, themes and editions
Everything above works on the free Cloudflare plan. The one feature that needs Enterprise is custom cache keys, which let other store views, currencies and customer groups be cached at the edge as separate variants. On every other plan those visitors bypass the edge and are served by Magento's full page cache, which is still fast. The default-context visitors, who are the majority on most stores, get the edge regardless of plan.
Luma and Hyva both render pages anonymously and load private content (cart count, customer name, messages) in the browser afterwards, so cached HTML is safe for both. There is no Hyva compatibility package to install, because the module adds nothing to the storefront. The health checks flag the Cloudflare features that break either theme: Rocket Loader breaks RequireJS on Luma and Alpine.js on Hyva, and Auto Minify can do the same.
One package covers Magento Open Source and Adobe Commerce, 2.4.4 through 2.4.9, on PHP 8.1 through 8.4.
Free means free
We build paid Magento modules. This one is free because Cloudflare and Magento should work together out of the box, and a module that makes your store faster and shows you the proof on a health page is a decent way to earn your trust.
There is no license key, no paid tier and no kill switch. The module never calls OCM Labs. Its only outbound requests go to Cloudflare's API and to your own storefront for the health probes. The admin footer carries one link to our other modules, and that is the whole pitch.
Install it
composer require ocmlabs/module-cloudflare
bin/magento module:enable OCMLabs_Cloudflare && bin/magento setup:upgrade
bin/magento setup:di:compile && bin/magento cache:cleanCreate a Cloudflare API token with Zone:Read, Zone:Cache Purge, Zone:Settings:Read, Zone:Settings:Edit, Zone:Cache Rules:Edit and Analytics:Read, paste it under Stores > Configuration > OCMLabs > Cloudflare, detect the zone, and run the health checks before you turn edge caching on. The checks tell you what to fix in which order. The step-by-step version, with verification after each step, is how to set up Cloudflare for Magento.
The module is in the OCM Labs store at $0, and the documentation covers every setting, the 25 checks, the CLI and the Varnish setup.

Shane Blandford
Founder of Orange Collar Media, a Denver ecommerce agency behind 800+ Magento and Shopify builds. In Magento since version 1.x - building, rescuing, and supporting revenue-critical stores since 2008.
✦ KEEP READING
Related from the Journal.
Magento 2 Follow-Up Emails After Purchase: What Core Does and What It Doesn't
Magento 2 sends no delayed follow-up emails after purchase. What core does, what a DIY cron queue needs, and where a per-SKU module fits.

Magento 2 Email Template Variables: {{var}}, {{for}} and Product Data
A working reference for Magento 2 email template variables: var, trans, if, depend, for loops, layout, strict mode, and how to list product data per item.

How to Customize the Magento 2 Checkout Success Page by Product
Customize the Magento 2 checkout success page per product: a CMS block for every order, a SKU-checking view model, and the gotchas.
