When to turn Redis on, and when to leave it alone for now

Redis is a persistent object cache. Applications that support it use it to store the result of expensive database queries, so the second request for the same data does not go back to the database.

It sits under Advanced, then Redis. One toggle, on or off.

Turning Redis on

When something you run asks for it.

Several WordPress caching and object-cache plugins look for Redis and use it automatically once it is available. The same is true of some application frameworks and a few shop platforms. Their setup documentation will say if Redis is supported and often whether it is required.

That is the whole decision. If a plugin or tool you use supports it, turn it on and point that tool at the address below. If nothing you run mentions it, there is nothing to do, and switching it on achieves nothing at all, because the cache only holds what an application asks it to hold.

Connecting to it

Once enabled, the panel shows what a tool needs to connect. The address is 127.0.0.1 and the port is 6379, and there is no password by default.

The Redis card on the panel, with its toggle switched on and text explaining that Redis is a persistent object cache for applications that support it. A blue Connection details box below gives the address as 127.0.0.1:6379 and states that there is no password by default because it is only available within the PHP container, and that a password can be set in redis.conf.

That is safe as it stands, and the reason is worth understanding. The daemon runs inside your website's own PHP container and listens on loopback only, so nothing outside that container can reach it. Your cache is not exposed to the internet and it is not shared with anyone else's website.

If a tool asks for a password, or you want one anyway, the panel has an Edit redis.conf control and a note that a password can be set there. Restart PHP afterwards so the daemon starts with the new file.

A performance article on opcode caching covers the other cache in this panel, which works at a different layer and is worth knowing alongside this one.

The configuration file

Enabling it creates redis.conf in your website's home directory, and the daemon writes its log to redis.log beside it. Both live outside public_html, so neither is reachable over the web.

Editing either is for the case where the default is wrong for your application. For most sites it never needs touching.

Leaving it off

Nothing breaks. Object caching is an optimisation, not a requirement, and a site with nothing configured to use a cache will run identically whether the toggle is on or off.

The one thing worth knowing is what happens on a cache miss, which is nothing complicated. The lookup returns nothing, and the application does its query as it always would. An enabled but unused cache is therefore inert rather than harmful, just pointless.