Caching

What this page is for: make a website faster with the caches that fit it — Varnish in front of it, a Memcached of its own, Redis (WordPress's object cache, or your app's own use), the WordPress page cache — and compress everything the server sends with Brotli. Each one is optional: nothing is installed and nothing runs until you turn it on.

Open the website, then Caching in its menu. The server's side of each — installing it, its memory, the websites using it — is Software.

You need

• The owner's login to change anything here. A temporary login can read the page and press Purge cache; the read-only demo shows it but changes nothing.
• Memcached, Varnish and Brotli installed from Software before a website can use them. Each card there says what it needs (memory, disk) before you press Install.

The rule that does not move: a cache only ever keeps what the app allows. A visitor who is signed in, has a cart, or carries a cookie the app reads always reaches the app, and so do the admin, the sign-in page, the cart, the checkout and anything the app marks as private.

Which cache for which website

Brotli is for the whole server: every website and every shop. A static website's Caching page has its recommendation, Purge cache and compression: nginx already serves its files from disk and tells browsers to keep them, so it has nothing else to add.

Recommended for this website

The first card on the Caching page works out which of these fit this website, and whether each one works, every time the page opens (Measure again asks once more). For Varnish, the WordPress page cache, Memcached, Redis and compression — and a static website's browser cache — one row says what it is for, whether it is on here, whether it works, a verdict (Recommended, Optional, Not needed or In use), why, and the memory it would use.

What it reads. The kind of website, and what the website's own files say it uses — names only, never a value: for WordPress an object cache in wp-content/object-cache.php and the caching plugins in wp-content/plugins; for PHP and Laravel the cache, session and queue drivers of its .env (CACHE_STORE, CACHE_DRIVER, SESSION_DRIVER, QUEUE_CONNECTION — nothing else in that file is read into the page); for Node.js and Create with AI a Redis or Memcached client in package.json; for Python requirements.txt and pyproject.toml; for Java pom.xml and build.gradle. Files are read from the live version only, and never through a link.

What it measures, on this server, just now. The website's home page is asked twice the way a visitor who is not signed in asks: the X-Cache of the second answer says whether Varnish or the page cache kept it, Content-Encoding whether it was compressed (and with what), Cache-Control and a Set-Cookie whether a cache may keep it at all. Its Redis is sent PING; its Memcached's own counters give how many lookups were found in it. A website with no certificate yet, a parked one, or one whose home page answers an error or sends visitors elsewhere is not measured, and the card says which.

The verdicts it never gives. Varnish is never recommended for a page that sets a cookie or says private, no-store or no-cache — it would keep nothing and only add a step, and a signed-in page must never be kept. A reverse proxy is offered Varnish only when its upstream says its answers may be kept (Cache-Control: max-age); a WordPress website is offered the page cache first (it uses no memory) and Varnish only as the alternative. Another plugin's object cache is never replaced. Nothing a kind cannot have is offered.

Apply does it where the panel can do it safely, and asks first, saying the memory it uses: Redis is added (as on the Database page), Brotli is switched on for the server, the WordPress page cache is ticked; for Varnish, Memcached and the object cache it presses the card's own button below, with that card's question. Where it cannot — an app has to be told to use Redis — How to connect it gives the exact steps: for Laravel the lines for its .env (REDIS_HOST is the socket, REDIS_PORT=0, CACHE_STORE=redis; Laravel 10 and older read CACHE_DRIVER), and php artisan config:clear when the app has cached its configuration.

Varnish

Varnish keeps the pages a visitor gets without signing in in memory and answers the next visitor from there — the app is not asked at all. On the website's Caching page press Turn Varnish on.

What happens, in order:

• nginx keeps the certificate. Visitors still reach the website's own nginx on HTTPS, with its Web Rules and the Cloudflare-only lock as before. nginx hands each request to Varnish, which listens on this server only (127.0.0.1:6081) — never on the internet.
• If Varnish stops, nothing goes offline. nginx then serves the website directly, as it did without Varnish, only not cached. The panel starts Varnish again by itself within a few minutes (up to 3 times a day); Software → Varnish → Start / repair does it at once.
• What is kept: pages (status 200) and "not found" answers (404 — a minute at most, unless the app says otherwise). Never a redirect, an error, a file over 10 MB, an answer that sets a cookie or says private, no-store or no-cache, and never anything for a request with a cookie the app reads, a password (Authorization), or a method other than GET and HEAD. WordPress's admin, sign-in, REST API, cart, checkout and account pages, and WooCommerce's own requests, always reach PHP. Advertising tags (?utm_source=…, ?gclid=…) are answered from the plain page's copy.
• How long: the app's own Cache-Control decides. A page that says nothing about caching is kept for the website's own time — 1800 seconds (30 minutes) for WordPress, 0 (not at all) for every other kind until you set one in the Keep a page … for field. Nothing is kept longer than a day.
• Every answer says what happened, in its X-Cache header: HIT (from Varnish), MISS (fetched and kept), PASS (not kept, by the rules above).
• WordPress: never together with the page cache. Turning Varnish on turns the WordPress page cache off; ticking the page cache in Settings turns Varnish off. Both pages say so.
• A staging site is never served through Varnish — it is tested exactly as its own server block serves it.

Its memory is set on Software → Varnish: 5 % of the server's memory by default (64 MB to 1 GB), and up to a quarter of it if you choose. A change restarts Varnish, which starts empty. Varnish runs only while at least one website uses it.

Turn Varnish off puts nginx back in front of the website alone and empties what Varnish kept for it. A WordPress website can then turn its page cache back on in Settings.

A Varnish somebody installed on the server by hand is never taken over: install it from Software after stopping your own (systemctl disable --now varnish).

Purge cache

Purge cache (on the Caching page) empties every cache the website has: Varnish, the WordPress page cache, and Cloudflare's copy of its addresses. You rarely need it — every deploy and rollback does the same, and a WordPress website behind Varnish is emptied the moment a post or a page changes. Software → Varnish → Empty everything empties Varnish for every website at once. Varnish takes no PURGE or BAN request over HTTP: a visitor reaches it from this server's own nginx, so no address could tell the panel's request from anyone else's — only the panel empties it (a plugin that sends PURGE gets 405).

Memcached

A website can have a Memcached of its own — for a PHP app, a Laravel app (CACHE_STORE=memcached), a WordPress plugin that uses Memcached (W3 Total Cache, LiteSpeed Cache …), or a Node.js, Python or Java app. On the Caching page choose its memory (64 MB to start; from 16 MB up to an eighth of the server's memory, 1 GB at most) and press Add Memcached.

What the panel makes:

• An instance that only this website can open. It runs as the website's own account, on a unix socket in a folder only that account can enter (/run/memcached-site-<name>/memcached.sock). There is no network port at all: no other website on the server, and nothing on the internet, can read or write it. (Memcached has no password, which is why the shared instance its package brings — 127.0.0.1:11211, open to every account — is never switched on.)
• The PHP extension (memcached) is turned on for this website's PHP only; the other websites' and shops' PHP do not change. It needs msgpack and igbinary loaded before it, so the ones the server's PHP does not load for everyone are turned on for the website too, and loaded first.
• The connection details on the card: the socket and the lines to paste. A Node.js app finds it in its environment as MEMCACHED_SOCKET (restart the app after adding it).

It is a cache: nothing in it is kept on disk, and it starts empty after a restart of the server, a memory change, or Start Memcached. What does not fit is dropped, oldest first.

Empty it removes everything in it now (an app that keeps its sign-ins in Memcached signs everyone out). Remove Memcached takes the instance away; an app written to need it shows errors until it is added again. The PHP extension stays on for the website.

If it stops, the panel starts it again by itself within a few minutes (up to 3 times a day); Start Memcached does it at once. A website that is being moved has it stopped on purpose.

Redis for WordPress, Node.js, Python and Java

Every website that runs code of its own can have a Redis of its own now (it is added on its Database page, with its memory and its own password, exactly as for a PHP website). What it is used for depends on the kind:

• WordPress — the object cache. On the Caching page press Keep the object cache in Redis. SixPanel installs the Redis Object Cache plugin (unless it is already there), writes the four lines it needs into wp-config.php (the socket, the password and a key prefix — the password never leaves the server), switches it on through WP-CLI as the website's own account, and checks that WordPress says Connected. It is offered, never forced. If another plugin's object cache is already in place (wp-content/object-cache.php), SixPanel does not replace it: turn that plugin's object cache off first. Take the object cache out of Redis removes what SixPanel added (the plugin too, when SixPanel installed it).
• Node.js, Create with AI, Python and Java — the app's environment carries REDIS_SOCKET, REDIS_PASSWORD and REDIS_URL. Restart the app after adding Redis. When its password is changed (Change password on the Database page), a running Node.js app is given the new one and restarted.

A WordPress website keeps its sign-ins in its own cookies and tables, so Sessions in Redis stays a choice of a plain PHP website (its PHP page).

Brotli

Brotli makes pages, scripts and stylesheets smaller than gzip. Install it from Server → Software: it comes from the distribution's own nginx modules, and Install turns it on. nginx then uses Brotli for every browser that asks for it (and for Cloudflare towards this server), and gzip for the others. It is part of nginx itself: nothing new runs. Every change is tested with nginx -t before nginx reloads.

A website behind Varnish is sent the gzip copy Varnish keeps in memory, so no page is compressed again on each visit.

If the module ever goes away (its package removed, or an nginx update it was not rebuilt for), the panel switches Brotli off at its next start, so nginx can always reload, and Health says so; gzip carries on meanwhile.

PageSpeed

There is no PageSpeed module. Google's ngx_pagespeed and mod_pagespeed are retired upstream, build against no current nginx, and have no build for ARM servers. Varnish (pages from memory) and Brotli (smaller files) are the server-side part of what it did; image and script optimisation belongs in the website itself or at Cloudflare.

What a temporary login can do

Read the Caching page and press Purge cache. Turning Varnish on or off, adding, sizing, starting, emptying or removing Memcached, the object cache, and everything on Software are the owner's.

How to check it worked

• The Recommended for this website card: each row that is on says Works or Not working, with what was measured. Press Measure again after a change.

HIT for a page that may be kept. A page that should be kept and says PASS carries a cookie or a Cache-Control that forbids it; the app decides.

• Memcached: the card shows Running, the memory used and how many lookups were found in it.
• Server → Health has a row for each: Websites' Memcached, Varnish, Brotli compression.

If it went wrong

• A signed-in page shows to a visitor who is not signed in — that page reached Varnish without the cookie that marks the visitor, or the app sent it without private/no-cache. Press Purge cache, then set the page's Cache-Control in the app (or set Keep a page … for to 0, which keeps only what the app explicitly allows).
• Varnish is not running — nothing is down (nginx serves the websites directly). Press Start / repair on Software → Varnish; the job's log says what it found. Over SSH, journalctl -u varnish is Varnish's own log.
• Memcached does not start — press Start Memcached; the panel tries again by itself. Over SSH, journalctl -u sixpanel-memcached@<name> is its own log.
• The object cache will not turn on — the job's log says why: another plugin's object cache is in place, WordPress is not installed yet, or the website has no Redis.