Magento on Cloudflare: The Edge-Fast Headless Stack
Magento on Cloudflare: the edge-fast headless stack
You run Magento on Cloudflare by splitting the store in two: a headless storefront served as static HTML from Cloudflare's edge network, and the Magento origin — catalogue, checkout, admin — sitting behind Cloudflare's proxy for caching, TLS and a firewall. The result is that most of what a customer touches is answered from a server physically near them rather than from one origin box, which is where the largest latency wins on a Magento store come from.
This edge stack is the hosting layer behind the AgenticEcom Suite, and every piece of it is standard Cloudflare functionality you can assemble yourself.
Why the edge matters for Magento
A traditional Magento store serves every page from one server. A shopper in Sydney browsing your London-hosted store waits for a full intercontinental round trip on every request — and no amount of origin tuning removes that distance. Edge delivery flips the model: static pages and assets are cached in Cloudflare's data centres worldwide, so the response comes from nearby. Latency is the quiet killer of Core Web Vitals, and it is the one factor you cannot fix at the origin.
The stack, piece by piece
| Layer | What runs there | What it buys you |
|---|---|---|
| Cloudflare Pages | The headless storefront (in our stack, Astro) as pre-rendered HTML | The shop window served from the whole network at once |
| Edge image delivery | Images resized and converted to WebP/AVIF near the visitor | Smaller payloads for the usual LCP element |
| Cloudflare proxy in front of Magento | DNS, TLS, WAF, DDoS absorption, static-asset caching | A faster and better-protected origin doing less work |
| Cache invalidation (ISR) | Rebuild-and-push of only the pages whose Magento data changed | Static-fast delivery that still shows live prices and stock |
Setting up the origin side
- Move DNS to Cloudflare and enable the proxy (the orange cloud) on the records serving your store, so traffic flows through Cloudflare's network.
- Set TLS to Full (strict) so the connection is encrypted end to end, with a valid certificate on the origin.
- Cache static assets, never sessions. Use Cache Rules to cache Magento's static and media paths aggressively, and bypass the cache for cart, checkout, customer and admin paths and for any request carrying a Magento session cookie. Caching a logged-in page for the wrong visitor is the classic mistake here — bypass on cookie is what prevents it.
- Enable the WAF managed rules so common attack traffic — including the card-skimming probes Magento stores attract — is dropped at the edge before it reaches PHP.
Note what this alone does not fix: with only a proxy in front of a Luma theme, HTML still renders at the origin. The full win arrives when the storefront itself moves to the edge — which is the headless step, covered end to end in the complete headless Magento Astro guide.
Where Cloudflare Workers fit
Not everything on a storefront can be a static file. Cloudflare Workers run code at the edge, in the same data centres that serve the cached pages, which is how the dynamic pieces stay fast: serving the storefront itself, negotiating image formats per visitor, routing API calls to the Magento origin, and handling request-time logic such as redirects or header rules without a round trip to your server. In practice a headless Magento build on Cloudflare is static HTML for everything that can be static, and Workers for the thin layer that cannot — the customer rarely touches the origin directly at all.
Keeping edge pages honest: invalidation
The hard problem with static delivery is freshness. Prices change, stock sells out, products are renamed — and a stale cached page is worse than a slow one, because it can show a customer a price you no longer honour. The answer is incremental regeneration: when data changes in Magento, only the affected pages are rebuilt and re-pushed to the edge, so a price or stock change reaches the edge within seconds of the update rather than at the next full rebuild, while pages still deliver at static speed. Be honest about the window: regeneration is asynchronous, so there is a brief interval between the change in Magento and the new page reaching every edge location — design checkout to re-validate price and stock server-side, which is where the guarantee belongs. The alternative approaches both fail at scale — purging everything on every change throws away the cache you built, and timed expiry means a window where the page is simply wrong. That trigger-and-rebuild wiring between Magento and the edge is exactly what the Astro ISR for Magento module packages.
Fast and secure are the same project
The pleasant surprise of the edge stack is that speed and security improve together rather than trading off. Cloudflare absorbs attack traffic before it reaches your origin, terminates TLS at the edge, and serves cached responses without touching PHP — so the Magento server does less work, presents a smaller attack surface, and answers the requests it does receive faster. If your store currently fails performance audits and worries you at patch time, this is one architecture answering both.
The result
Put together — a static headless storefront on Cloudflare Pages, edge image delivery, the origin shielded behind the proxy, and incremental invalidation keeping pages current — this is the architecture a live client store runs on, and it passes all three Core Web Vitals in Google's field data on a catalogue of over 1,000 products (measured July 2026). If you are still diagnosing where your speed actually goes, start with why your Magento store is slow; if you want the invalidation layer without building it, see Astro ISR for Magento.
FAQ
Can you run Magento on Cloudflare?
Yes, in two halves: the headless storefront runs on Cloudflare Pages at the edge, and the Magento backend stays on its host with Cloudflare proxying in front of it for caching, TLS, WAF and DDoS protection. Cloudflare does not host Magento's PHP itself; it accelerates and shields everything around it.
Does Cloudflare make Magento faster?
Proxying alone speeds up static assets and cuts origin load, but HTML still renders at the origin. The substantial gain comes from serving a pre-rendered headless storefront from the edge, which removes distance from the customer's critical path entirely.
How do prices stay current with edge caching?
Through incremental cache invalidation: when catalogue data changes in Magento, only the affected pages are rebuilt and re-pushed to the edge. Customers see live prices and stock while the store keeps static-level delivery speed.
What should never be cached at the edge?
Anything session-specific: cart, checkout, customer account and admin paths, and any request carrying a Magento session cookie. Cache Rules should bypass on those, while static assets, media and pre-rendered catalogue pages cache aggressively.