What's new
Toggle Nav
My Cart
Magento glossary

What is Magento Varnish Cache ?

Varnish is the full-page cache (FPC) that Adobe recommends for Magento in production. It is an HTTP reverse proxy that sits in front of your web server and returns cached HTML without starting PHP. Magento generates the Varnish config for you with bin/magento varnish:vcl:generate and purges pages by cache tags when you save a product or CMS page. Per-customer bits like the mini-cart load separately in the browser, so one cached page works for every visitor. Varnish is free and open source (BSD licence).

Need Magento perf help? How it works

Written by Kishan Savaliya, Adobe Certified Magento & Hyvä developer, 8 years on platform

How it works

Five things Varnish actually does for your Magento store

Varnish is not a Magento module. It is a separate service, and Magento talks to it through a VCL file, response headers and purge requests. This is the order I wire it up in.

  1. 01

    Install Varnish 6 or 7 on the same box (or upstream)

    Varnish is an HTTP reverse proxy that sits in front of your web server. On a single server I install it from the OS packages (apt or dnf), let it listen on port 80 or 6081, and point its backend at nginx on 8080. Bigger setups give Varnish its own server in front of the web nodes. Check the Magento system requirements for your exact 2.4.x release to pick the right Varnish version.

  2. 02

    Tell Magento where Varnish is

    Run bin/magento setup:config:set --http-cache-hosts=127.0.0.1:6081 so Magento knows where to send purge requests. Separate several hosts with commas. The value is written to app/etc/env.php. Skip this step and pages still render, but Varnish never hears about changes, so an updated price stays stale until the cache entry expires. It is the first thing I check when a client says "I saved it but the site still shows the old one".

  3. 03

    Switch the FPC backend to Varnish in admin

    In the admin go to Stores → Configuration → Advanced → System → Full Page Cache and change Caching Application from "Built-in Cache" to "Varnish Cache". The same setting lives at system/full_page_cache/caching_application. It is one or the other: with Varnish selected, Magento stops storing pages itself. (Redis can store pages for the Built-in option, but it is not used for pages once Varnish is on.)

  4. 04

    Generate the VCL with bin/magento varnish:vcl:generate

    Magento writes the VCL (Varnish Configuration Language) file for you: bin/magento varnish:vcl:generate > /etc/varnish/default.vcl. That file handles purge by cache tags, cache key rules, ESI fetches and health checks. I keep it in the project repo and regenerate it after every Magento upgrade, then diff it against the old one, because the shipped template does change between releases.

  5. 05

    Cache tags, ESI and private content keep pages correct

    A product page is the same HTML for every visitor. The per-customer parts (mini-cart, welcome message) are not in that HTML: the browser loads them afterwards from customer/section/load. ESI is only used for blocks that declare their own TTL, such as the top menu. Every response also carries X-Magento-Tags listing what the page depends on (for example cat_p_1234). When you save that product, Magento sends a PURGE with the tag and Varnish drops every page that used it.

When to use

Four situations where Varnish is the obvious answer

The Built-in cache is fine for local development and very small stores. In these four cases I would not run without Varnish or an equivalent.

  • Production stores with real, steady traffic

    With the Built-in cache, every cache hit still boots Magento in PHP before the stored page is returned. Varnish answers a hit before the request ever reaches PHP-FPM, from memory. On a store with steady traffic that frees a lot of CPU for the requests that cannot be cached, like cart and checkout. On most production stores I set up, Varnish is part of the stack from day one.

  • Adobe Commerce Cloud (Fastly does the job)

    On Adobe Commerce Cloud you do not run Varnish yourself. Fastly, a CDN built on Varnish, is the full-page cache in Staging and Production, and Magento talks to it through the Fastly module and custom VCL snippets. The ideas are the same: cache tags, purges, ESI and uncacheable blocks. Knowing how self-hosted Varnish behaves makes most Cloud caching problems much easier to trace.

  • High-traffic seasonal peaks (BFCM, Diwali, sale launches)

    Black Friday, Diwali, a big sale launch: any event where traffic jumps for a day or two. Without a page cache in front, every category and product view runs PHP, and checkout requests queue up behind them. With Varnish, PHP only renders cache misses and the parts that are private to each shopper. Set it up and warm it well before the peak, never during it.

  • Sites running a CDN that wants an origin offload

    A CDN such as Cloudflare, Akamai or CloudFront caches at the edge, but every edge miss still lands on your server. Varnish between the CDN and Magento gives you a second layer: the CDN answers what it has, Varnish answers most of the rest, and only real misses reach PHP. Varnish also understands Magento’s cache tags, which most CDNs do not, so purges after a product save stay precise.

Common mistakes

Three traps that turn a Varnish rollout into a rescue project

Most Varnish problems I am asked to fix on Magento stores fall into one of these three. Avoid them and the cache just runs quietly in the background, which is all you want from it.

  • Caching personalised content (the cross-customer cart leak)

    The single worst mistake. If you cache the full HTML of a page that contains a mini-cart, welcome message, or "Recently viewed" block, and you skip ESI hole-punching, Varnish will serve customer A’s mini-cart to customer B. The Magento-shipped VCL does ESI correctly out of the box, but custom themes or careless block edits routinely break it. Always test with two separate browsers logged in as different customers, add different items to each cart, and confirm each session sees only its own cart. If both carts merge in either browser, you have an ESI break and a GDPR incident waiting to happen.

  • Skipping the VCL regeneration after a Magento upgrade

    Magento changes its X-Magento-Tags header format, admin-purge route, and cache-key rules between minor versions. A VCL generated on 2.4.4 will run on 2.4.7, but it will mis-handle some cache-tag patterns, leak some dynamic blocks, and miss some invalidations. Symptoms are subtle: stale prices for some products, stale stock for others, and occasional flashes of someone else’s data. Every Magento upgrade must include bin/magento varnish:vcl:generate > /etc/varnish/default.vcl followed by varnishadm vcl.load + vcl.use. Bake it into the deploy script.

  • Forgetting vcl_purge: stale pages after admin saves

    If vcl_purge is missing or misconfigured, Magento sends PURGE requests to Varnish on admin save but Varnish ignores them. Pages cache forever, prices stay stale, "Save" in admin appears to do nothing on the storefront. Debug with varnishlog -g request -q "ReqMethod eq PURGE" to see whether the purge is reaching Varnish, and add the X-Magento-Cache-Debug: srcache header to see HIT / MISS / PASS per response. The Magento-generated VCL handles this correctly: the bug is always custom overrides that drop the purge ACL or strip the cache-tag header.

Related concepts

Five neighbour concepts most readers want to look at next. Click through for the full deep-dive.

FAQ

Magento Varnish Cache: frequently asked questions

  • Varnish vs Magento built-in FPC: what is the real performance gap?
    Typically 5-10x on TTFB under load. Built-in FPC stores serialised page payloads in Redis (or filesystem); every hit costs a Redis round-trip, an unserialise, and a PHP-FPM worker. Cold-cache TTFB is 250-600 ms, warm-cache TTFB is 80-180 ms. Varnish keeps the rendered HTML entirely in RAM in front of PHP, cached TTFB drops to 10-50 ms regardless of cache state, and uncached pages don’t bottleneck because Varnish serialises the slow path away from the fast path. On a store doing 200 req/min the difference between Built-in FPC and Varnish is the difference between "site is fine" and "site falls over during a sale".
  • Do I need Varnish if I am already on Cloudflare or a CDN?
    Yes: they solve different problems and stack cleanly. A CDN caches at the edge (Cloudflare, Fastly, CloudFront, Akamai), but on a miss the CDN still hits your origin. If your origin is slow on a miss, every cache-fill takes 800 ms and the first visitor in every region pays for it. Varnish in front of Magento makes the origin fast on misses (sub-50 ms instead of sub-second), so CDN cache-fills are quick and the overall edge-cache hit rate climbs because pages don’t expire before they get warm. The standard performant Magento stack in 2026 is CDN → Varnish → nginx → PHP-FPM → Redis (block / session) + OpenSearch (catalogue) + MySQL.
  • How do I purge Varnish for one URL?
    Send a PURGE request directly: <code>curl -X PURGE -H "Host: example.com" http://127.0.0.1:6081/p/some-product.html</code>. Magento’s admin-save flow does this automatically by sending PURGE with <code>X-Magento-Tags</code> headers so Varnish can purge by tag (every page touching catalog_product_1234) rather than by URL. For manual cache flush, <code>bin/magento cache:flush full_page</code> on the Magento CLI iterates the http-cache-hosts list and issues a PURGE.* (regex-all) request to wipe everything. Always verify the purge worked by re-requesting the URL with <code>-H "X-Magento-Cache-Debug: srcache"</code> and checking for MISS → HIT transitions.
  • Why does my cart show another customer’s items?
    ESI hole-punching is broken: the mini-cart block is being cached as part of the full page instead of being fetched per-request. Three causes in order of frequency: (1) custom theme overrode the <code>minicart</code> block and dropped the <code>ttl="0"</code> / <code>cacheable="false"</code> attribute, (2) the generated VCL is missing <code>vcl_recv</code> ESI logic because it wasn’t regenerated after a Magento upgrade, (3) a CDN (Cloudflare in Full caching mode, Fastly without origin-shielding rules) is caching the full HTML in front of Varnish. Fix: regenerate the VCL, audit <code>cacheable="false"</code> on every block in customer_section_load, and add <code>Cache-Control: private</code> to the customer-section response. Test by logging in as two different customers in two different browsers and adding different items to each cart.
  • Does Hyvä change anything about Varnish?
    No: Hyvä is purely a frontend rewrite (Tailwind + Alpine.js replacing KnockoutJS), so the server-side rendering layer that Varnish caches is unchanged. X-Magento-Tags, ESI blocks, purge flow, VCL: all identical between Luma and Hyvä stores. Hyvä actually makes Varnish more valuable: because Hyvä ships ~85% less JavaScript, cached HTML pages render in under a second even on mid-tier Android, so the perf win from sub-50 ms TTFB is fully realised end-to-end. Build a 2026 Magento stack as Hyvä on the frontend + Varnish on the backend: they’re complementary, not alternatives.
  • Can I run Varnish and Redis FPC together?
    No, pick one. Magento’s full-page cache slot is exclusive: either "Varnish Cache" or "Built-in Cache" in admin, never both. If you select Built-in Cache, you can back it with Redis for storage (faster than filesystem); if you select Varnish, the Built-in FPC layer is bypassed entirely. What you can, and should, run alongside Varnish is Redis for the <strong>other</strong> cache types: block cache, config cache, session storage, and so on. The standard performant stack is Varnish for FPC, Redis instance 1 for sessions, Redis instance 2 for default + block + config cache, OpenSearch for catalogue, MySQL for the database.
Varnish audit

Want a Varnish + Redis audit on your Magento store?

Send your storefront URL: I will run a TTFB + cache-hit-ratio audit, review your VCL, and reply with a written tuning plan, fixed-price quote, and earliest start date. 24-business-hour turnaround.

Get a perf audit Hire me directly
Chat on WhatsApp