How to use Redis for sessions and cache

Separate the transient cache from durable sessions and queues on TurboStack.

TurboStack runs two Redis instances on each host so you can keep throwaway cache data apart from data you cannot afford to lose, such as logged-in sessions and queued jobs. Pointing each kind of data at the right instance keeps your site fast and avoids logging users out when the cache is cleared.

The two instances

Instance	Port	Local socket	Use it for	Safe to clear?
Cache	`6379`	`/var/run/redis/redis.sock`	Page, object and other transient cache	Yes - it is rebuilt on demand
Persistent	`6378`	`/var/run/redis-persistent/redis.sock`	Sessions, queues and other durable data	No - clearing it logs users out and drops queued jobs

Send transient cache traffic to 6379 and durable data to 6378. Most application types on TurboStack are already wired up this way; only change it if you configure Redis by hand.

Connect over the local socket

When your application runs on the same host as Redis, connect over the Unix socket instead of 127.0.0.1:<port>. A socket has less overhead than a network connection, which lowers latency and processor use under load. Use the socket paths from the table above.

Give each application its own database

Redis provides 16 logical databases, numbered 0 to 15. When several applications share a host, give each one its own database number (for example application A on 1, application B on 2) so they never read or overwrite each other's keys.

Don't clear the persistent store casually

Clearing the 6379 cache is harmless - it simply rebuilds. Clearing the 6378 persistent instance is not: it drops sessions (logging everyone out) and any queued jobs. The standard clear the cache command (tscli redis clear) already targets the cache instance (6379), so it is safe; only reach for the persistent instance deliberately.

Set a TTL and expiry

By default Redis does not assign a Time-To-Live (TTL) to a key unless you set one. Giving transient keys an expiry keeps memory usage in check and stops the cache from filling up.

Set a TTL when you write a key - for example one hour:

SET key value EX 3600

As a general guide:

Cache keys - set a TTL matching how long the data stays fresh (for example API responses or HTML fragments).
Sessions - use a longer TTL, around 24 hours.
Critical data - do not set a TTL for data that must persist.

Verify data is being cached

After wiring up Redis, check that keys are actually being written. Connect with redis-cli and list the keys:

redis-cli
127.0.0.1:6379> keys *
(empty array)

An empty array means nothing has been cached yet - expected right after a clear. Click around your site, then run keys * again. If it stays empty, the application is not writing to Redis and the integration needs checking.