Magento VPS Performance: Varnish Full Page Cache, Redis Sessions and Separate Cache Databases

The biggest Magento performance gains on a VPS come from two caching layers: Varnish in front of the web server for full page cache, and Redis for the default cache and PHP sessions, each in its own Redis database. Adobe's documentation treats Varnish as the recommended full page cache, and its Redis guide gives the exact bin/magento commands, so the setup below is mostly about putting those pieces in the right order and checking each one works.

PHP memory, OPcache and OpenSearch sizing are covered in our earlier Magento VPS requirements guide.

Prerequisites

• A working Magento (Adobe Commerce or Magento Open Source) install on nginx and PHP-FPM.
• Root access to install Varnish and Redis. Every VPSWala plan includes full root access.
• A staging copy or a maintenance window; cache changes can briefly break the storefront.
• Enough RAM for PHP-FPM, MySQL, OpenSearch, Redis and Varnish's cache storage together.

Step 1: Put Varnish in front of nginx

Adobe's Varnish page describes the layout: Varnish accepts HTTP traffic on port 80 and forwards requests to the web server on a backend port such as 8080. Move nginx's storefront listener to 8080 and install Varnish on 80.

Varnish does not handle TLS. Adobe's known-issues list says "Varnish does not support SSL", so terminate HTTPS first, typically in an nginx server block on port 443 that proxies to Varnish:

browser :443 -> nginx (TLS) -> Varnish :80 -> nginx :8080 -> PHP-FPM

Step 2: Generate the VCL from Magento

In the Admin, go to Stores, Settings, Configuration, Advanced, System, Full Page Cache, set Caching Application to Varnish, fill in the backend host and port (127.0.0.1 and 8080 here) and the access list allowed to purge, then export the VCL for your Varnish version. Replace Varnish's default.vcl with the exported file and restart Varnish.

If the storefront returns a 503 from Varnish during setup or long imports, Adobe suggests adding .first_byte_timeout = 600s; to the backend default block.

Step 3: Move the default cache to Redis

Adobe's Redis cache page gives this command for the default cache:

bin/magento setup:config:set --cache-backend=redis \
  --cache-backend-redis-server=127.0.0.1 \
  --cache-backend-redis-db=0

The port option is --cache-backend-redis-port and defaults to 6379. Redis page cache (database 1) is an alternative to Varnish, not an addition; with Varnish handling full page cache you can leave it unconfigured.

Step 4: Move sessions to Redis

File-based sessions on a busy store create lock contention and lots of small files. Adobe's session guide uses:

bin/magento setup:config:set --session-save=redis \
  --session-save-redis-host=127.0.0.1 \
  --session-save-redis-port=6379 \
  --session-save-redis-db=2

The same page lists defaults worth knowing:

Adobe is explicit that "if you use Redis for more than one type of caching, the database numbers must be different". The suggested layout is database 0 for default cache, 1 for page cache and 2 for sessions. On a larger store, run sessions in a separate Redis instance with persistence enabled, so flushing the cache never logs customers out.

Verify each layer

• redis-cli ping should answer PONG.
• redis-cli monitor should show Magento activity such as select and hget commands while you browse.
• Adobe's check for Varnish: once it is configured correctly, var/page_cache under the Magento root stays empty.
• Request a category page twice with curl -I and compare the response headers; the second request should be served from cache.

Common problems

• Stale pages after manual cache deletion: Adobe notes that if you delete var/cache by hand you should restart Varnish.
• Customers logged out after a cache flush: sessions and cache share a Redis database or instance.
• Purges failing: the server's address is missing from the purge access list in the Admin.
• Redirect loops on HTTPS: the TLS proxy is not passing the original scheme to Magento.

Choosing the VPS

A caching stack moves load from PHP to memory, so RAM is usually the first limit. Before ordering, write down a memory budget: the PHP-FPM pool (worker count times the memory each worker uses on a category page), the MySQL buffer pool, the OpenSearch heap, the Redis maximum memory for cache and sessions, and the storage you give Varnish for cached pages. Add a margin for the operating system and for cron jobs such as indexers, which can briefly use as much memory as several PHP workers. If the total is close to the plan's RAM, choose the next size up rather than letting the kernel start swapping during a sale.

VPSWala's KVM cloud VPS plans scale up to 48 vCPU and 128 GB of RAM on RAID NVMe storage. For stores where uncached requests (checkout, cart, search) dominate, the Ryzen 9 9950X VPS plans with 16 to 64 GB of DDR5 give faster single-thread PHP. Plans are unmanaged unless agreed in writing, so you own updates and backups.

Sources

• Adobe Commerce: Configure and use Varnish
• Adobe Commerce: Configure Redis for session storage
• Adobe Commerce: Use Redis for default cache