How to clear the Redis cache

Flush the Redis cache on TurboStack with the CLI, what it does and does not touch, and what to expect afterwards.

Clear the Redis cache when cached data has gone stale - for example after a deploy, a configuration change, or while troubleshooting. TurboStack runs two Redis instances, so it matters which one you clear: the cache instance (6379) holds throwaway data, while the persistent instance (6378) holds sessions and queues you do not want to lose.

Before you start

SSH access to the host as the application's system user - see SSH access.
Know which instance and database your application uses - see Use Redis for sessions and cache - so you clear the cache, not the sessions.

Clear the cache with the TurboStack CLI

tscli redis clear is the usual way. It runs redis-cli flushall against the cache instance (6379), clearing all of its databases. The persistent instance (6378) is left untouched, so sessions and queued jobs survive.

tscli redis clear

Expect a short performance dip while the cache fills again.

Note

This flushes all databases on the cache instance, so every application that caches on 6379 has its cache cleared - not just one. To clear a single site, use a targeted command below or your application's own cache flush.

Clear a single database or the persistent instance

For finer control, use redis-cli directly (it connects to the cache instance on 6379 by default):

redis-cli -n 1 FLUSHDB        # clear only database 1 on the cache instance (6379)
redis-cli -p 6378 flushall    # clear the persistent instance - drops sessions and queues

Warning

The persistent instance (6378) holds sessions and queues. Clearing it logs users out and drops queued jobs - only do this deliberately.

Prefer your application's own flush

When you only need to clear one application's cache, its own command is safest because it touches just that application's keys. For example, Magento:

php bin/magento cache:flush

After clearing

The cache rebuilds on the next requests, so the first hits are slower and load is briefly higher. Warm the important pages by visiting them, or let your sitemap or a crawler do it, before judging the result.

Apply and verify

The flush is immediate. Right after it, the cache instance is empty:

redis-cli dbsize

(integer) 0 confirms it; the count starts climbing again as pages are requested.

If it did not work

Stale content after a Redis flush is usually held by another layer. The candidates are the full-page cache in Varnish, compiled PHP in the OPcache, and the application's own file cache. Keys that never return (dbsize stays 0 after browsing) mean the application is not writing to this instance. Check its socket path and database number. See Why is my site slow?, or contact support.