The Magento cache warmer for catalogs that never fit in cache

Every cache:flush, deploy and reindex empties your Varnish FPC — and with ten thousand product URLs, "wait for organic traffic" means most of your catalog is always cold. Warm it on a schedule instead, at the edge and worldwide.

The Magento-specific problem

Expensive pages, aggressive invalidation

Magento pages are among the most expensive on the web to render cold — and Magento invalidates them more aggressively than almost any other platform.

💸

Cold renders cost seconds

Layered navigation, price indexes, customer groups, EAV queries — an uncached Magento category page routinely takes multiple seconds to render. The gap between FPC HIT and cold render is bigger here than on any other platform we warm.

♻️

Everything invalidates the FPC

Deploys, cache:flush, reindexing, price updates, stock changes via import — each one purges some or all of Varnish/Fastly. Right after the nightly import is exactly when your cache is emptiest and your first morning visitors are slowest.

🗂️

The catalog long tail never warms itself

Organic traffic keeps your top 100 pages warm. The other thousands of product and category URLs — the ones Google sends long-tail shoppers to — expire and stay cold until the next unlucky visitor pays the render cost.

How it works with Magento

Sitemap in, warm catalog out

1

Add your Magento sitemap

Magento's generated sitemap.xml covers products, categories and CMS pages — we resolve sitemap indexes automatically and re-read them before every run, so catalog changes are picked up without maintenance.

2

Warm after every deploy — automatically

Trigger a run from your CI/CD via deploy hook or our GitHub Action: deploy, purge, warm, done. The cache is refilled before your customers notice it was ever empty — including the upper CDN tiers on Adobe Commerce Cloud's Fastly setup.

3

Paced so your origin survives

Warming a big catalog into an empty cache means real origin renders — so requests are rate-limited and paced. Once warm, the edge answers and your origin barely sees us. Every response's cache status is recorded per URL and location.

FAQ

Magento specifics

Varnish, Fastly or both — what do you warm?

Both layers benefit. Requests that reach your Varnish fill the FPC; on Adobe Commerce Cloud, Fastly's edge locations cache on top and we warm those per location. We auto-detect the CDN from response headers and report cache status for whichever layer answered.

How many URLs can you handle?

Catalogs with tens of thousands of URLs are the normal case for Magento, not the exception. Plans differ by URL volume and frequency — and because runs are paced, a big catalog warms steadily instead of hammering your origin after a flush.

What about customer groups and currency variants?

The FPC caches the guest/default variant, which is what warming fills — and it's also what every new visitor and every Google crawl sees. Logged-in and group-specific pages are personalized (cache-bypassed) in stock Magento and can't be pre-warmed by anyone.

Can I warm right after our nightly import?

Yes — that's the ideal pattern. Trigger a run via deploy hook as the last step of your import/reindex job, or schedule intervals so a pass lands right after your usual import window.

Stop paying the cold-render tax

Free for 7 days, plans from $15/month. Works with Varnish, Fastly and Adobe Commerce Cloud.

Start free trial How Varnish warming works