Magento Caching Explained: Varnish, Valkey and Full Page Cache

Magento uses several caches stacked on top of each other. Varnish (or Fastly on Adobe Commerce on Cloud) stores whole HTML pages in front of PHP; Valkey stores Magento's internal caches, such as configuration, layouts and blocks, plus sessions; and the browser and CDN store static files. A page request that hits Varnish never touches PHP, which is why getting Varnish right is the single biggest speed lever on most Magento stores.

This guide explains each layer, what it holds, how it gets cleared, and how to check that it is actually working.

The cache layers at a glance

Read this table from top to bottom in the order a request travels: from the visitor's browser down to the database.

Varnish: the full page cache

When a visitor requests a category page, Varnish checks whether it has a fresh copy. On a hit, it returns the HTML in milliseconds without running Magento. On a miss, the request goes to PHP, Magento renders the page, and Varnish stores the result for the next visitor.

How personal content works with a shared page

Magento caches one public version of each page and fills in personal content afterwards. Items like the customer's name and mini cart are loaded with a separate AJAX request and stored in the browser's local storage as "customer data sections". That is why a cached page can still show a logged-in customer their own cart.

How Varnish is invalidated

Magento tags each cached page with identifiers for the data it shows, such as specific products and categories. When an admin saves a product, Magento sends a purge request to the Varnish hosts listed in its configuration, asking it to drop every page carrying that product's tag. Pages that do not show the product stay cached.

Basic setup commands

On-premises, you export a VCL file for your Varnish version from the Admin (Stores > Configuration > Advanced > System > Full Page Cache), install it on the Varnish server, then point Magento at Varnish:

# Use Varnish as the caching application (2 = Varnish)
bin/magento config:set system/full_page_cache/caching_application 2

# Tell Magento where to send purge requests (placeholder host and port)
bin/magento setup:config:set --http-cache-hosts=varnish.internal:6081

Adobe's guide also recommends restricting the acl purge list in the VCL to the hosts allowed to purge. On Adobe Commerce on Cloud infrastructure, Fastly provides the full page cache instead, configured through the Fastly module.

Valkey: cache types and sessions

Valkey is an open source, in-memory key-value store. Starting with 2.4.9, Adobe's CLI tooling uses Valkey in place of Redis because of Redis licensing changes, and 2.4.9's requirements list Valkey 9. Adobe recommends separate databases for each use: 0 for the default cache, 1 for page cache (if you use the built-in page cache instead of Varnish) and 2 for sessions.

bin/magento setup:config:set --cache-backend=valkey --cache-backend-valkey-server=127.0.0.1 --cache-backend-valkey-db=0
bin/magento setup:config:set --session-save=valkey --session-save-valkey-host=127.0.0.1 --session-save-valkey-db=2

Magento's cache types are the internal caches you see with bin/magento cache:status. They include config, layout, block_html, collections, eav, translate, full_page and others. Disabling any of them on production slows every request.

Clean vs flush: the habit that matters

Adobe's documentation draws a clear line between two commands:

• cache:clean removes items only from enabled Magento cache types, and leaves other applications' data in shared storage alone.
• cache:flush empties the underlying cache storage, which may affect other processes that share it.

Adobe advises cleaning first and flushing only when problems persist. In practice, clean only the types you changed:

bin/magento cache:clean config layout
bin/magento cache:clean full_page

Teams that flush everything after every content edit throw away the whole page cache, and the next wave of visitors pays for rebuilding it.

How to check each layer is working

Common caching problems

• A single uncacheable block. One cacheable="false" in a layout used on every page disables full page caching for the whole site.
• Cookies or query strings that bypass cache. Marketing parameters can create unique cache entries for every link unless the VCL normalizes them.
• Valkey memory too small. Evictions force Magento to rebuild caches constantly.
• Purges not reaching Varnish. If the purge host list is wrong, visitors see stale prices or stock after edits.
• Cache warming missing. After deploys, top pages should be requested once so real visitors get hits.

Caching is the first group of fixes in our Magento speed optimization guide, and the services above shape what you need from a server, as covered in the Magento hosting guide.

Frequently asked questions

Do I need Varnish if I use Valkey?

They do different jobs. Valkey stores Magento's internal caches and sessions; Varnish stores full pages in front of PHP. Magento can store full pages in Valkey through its built-in cache, but Adobe recommends Varnish for production.

Why do customers sometimes see old prices?

Usually because purges are not reaching Varnish or the CDN, or because prices changed through a direct database import that did not trigger cache invalidation.

Is Redis still supported?

From 2.4.9, Adobe's tooling and requirements use Valkey. If you are upgrading from an older release on Redis, plan the switch as part of the upgrade.

Get caching right

Mistri's Magento performance optimization work starts with exactly these checks: cache hit rates, uncacheable layouts, purge configuration and Valkey sizing.

Sources

Configure Commerce to use Varnish (Adobe Experience League); Use Valkey for page cache (Adobe Experience League); Use Valkey for session storage (Adobe Experience League); Manage the cache (Adobe Experience League).