# How to use Redis for sessions and cache

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](clear-the-cache.md) 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:

```bash
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:

```bash
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.

## Related

- [Configure Redis](configure.md)
- [Clear the Redis cache](clear-the-cache.md)
- [Inspect Redis with Redis Insight](inspect-with-redis-insight.md)
- [Performance tuning](../../concepts/performance-tuning.md)