How to Set Up Varnish Full Page Cache for Magento 2

To run Varnish as Magento 2's full page cache, set the caching application to Varnish Caching, generate a VCL file from Magento itself, and tell Magento where Varnish lives so it can purge pages when content changes. Once that's done, cached pages come straight from Varnish and never touch PHP.

This guide covers Magento Open Source and Adobe Commerce on your own infrastructure. Adobe Commerce on Cloud uses Fastly rather than Varnish, so it doesn't apply there.

Why use Varnish instead of the built-in full page cache?

Magento's built-in full page cache stores rendered pages in its cache backend, but every request still reaches PHP so Magento can look the page up and return it. Varnish sits in front of Magento and answers from memory when it has the page. That's why Adobe recommends Varnish for production.

Speed has a measurable business effect: in Deloitte's study for Google, a 0.1-second improvement in mobile site speed increased retail conversions by 8.4%. For the cache types Magento uses underneath, see the database and performance lesson (Arabic, with English code).

Which Varnish version works with Magento 2?

Adobe's system requirements for the latest patches, 2.4.6 through 2.4.9, list Varnish 8; earlier patches listed Varnish 7.7. There's a catch: Magento's VCL generator only includes templates for Varnish 4, 5, 6 and 7. There is no Varnish 8 template.

In practice, generate the VCL with --export-version=7 and test it thoroughly on staging, because Adobe doesn't explicitly document that combination.

How do you enable Varnish in the admin or CLI?

In the admin, go to Stores › Settings › Configuration › Advanced › System › Full Page Cache and set Caching Application to Varnish Caching. The same screen holds TTL for public content and the Varnish Configuration fields.

From the CLI, which suits production and deployment scripts:

bin/magento config:set --scope=default --scope-code=0 system/full_page_cache/caching_application 2

So Magento can purge the cache, register your Varnish server, or several separated by commas:

bin/magento setup:config:set --http-cache-hosts=192.0.2.10:6081

How do you generate the right VCL file?

bin/magento varnish:vcl:generate \
  --export-version=7 \
  --access-list=192.0.2.20 \
  --backend-host=192.0.2.20 \
  --backend-port=8080 \
  --grace-period=300 \
  --output-file=/etc/varnish/default.vcl

• --access-list: hosts allowed to send purge requests, meaning your Magento servers. From 2.4.9 it accepts CIDR ranges.
• --backend-host and --backend-port: the web server running Magento behind Varnish.
• --grace-period: how long Varnish keeps serving a stale copy while it fetches a fresh one; the default is 300 seconds.
• Without options, the defaults are localhost, port 8080 and export version 6.

Reload Varnish after generating the file so it picks up the new configuration.

What does grace mode protect you from?

When a cached page expires, Varnish doesn't make the visitor wait. It keeps serving the stale copy briefly while fetching a fresh one from Magento. That prevents a burst of PHP load when many pages expire at once, and keeps the store responsive if the backend slows down for a moment.

What should Varnish not cache?

• Checkout and customer account pages: any block marked cacheable="false" makes its whole page uncacheable, which is intentional here. Customer-specific data such as the cart loads after the page through JavaScript.
• Static files: the default VCL passes them through uncached. Adobe suggests caching them in Varnish only when you have few locales and no CDN; otherwise a CDN is the better fit.

Watch for this trap: cacheable="false" on a block in a sitewide layout such as default.xml disables caching on every page. If Varnish caches nothing, check for that first. It's a common interview scenario, covered with similar cases in the Redis, RabbitMQ and indexing lesson (Arabic).

How do you check Varnish is actually caching?

• Request the same page twice with curl -I and look at the Age header. A value above zero on the second request means the response came from cache.
• Run varnishlog or varnishstat on the Varnish server to see hits and misses.
• Give Varnish enough memory to hold your most-visited pages, or it will evict important pages early.

To see where Varnish fits in the wider architecture, from load balancer to database, read the e-commerce system design lesson (Arabic). If you're also moving Magento's own cache to Valkey, see moving Magento from Redis to Valkey.

What changed in Magento 2.4.9?

• Magento normalizes the order of query parameters before caching, so the same URL with parameters in a different order no longer creates a duplicate cache entry.
• The purge access list accepts CIDR ranges.

Varnish production checklist

• Caching Application is set to Varnish Caching
• --http-cache-hosts lists every Varnish server
• The VCL is generated with --export-version=7 and tested on staging
• The access list contains only your Magento servers
• A grace period is set
• No sitewide layout contains a cacheable="false" block
• A second request for the same page returns an Age above zero
• Varnish has enough memory for your most-visited pages