> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcp-use.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Redis Storage

> Use Redis-backed session storage for distributed TypeScript MCP server deployments.

Use Redis when session metadata or server-to-client workflows must work across restarts, deploys, or multiple server instances. Redis gives you two pieces: `RedisSessionStore` for serializable session metadata and `RedisStreamManager` for routing active stream messages across instances.

This guide focuses on choosing and wiring Redis. Use the [Sessions API reference](/typescript/api-reference/server/sessions) for constructor options, defaults, method behavior, Redis command details, and stream-manager contracts.

## Choose the Redis pieces you need

Use the session store alone when you only need session metadata persistence or ordinary request recovery across instances. Add the stream manager when active server-to-client delivery must cross instance boundaries.

| Deployment need                                                                             | Configure                                     |
| ------------------------------------------------------------------------------------------- | --------------------------------------------- |
| Sessions survive restarts on one server                                                     | `RedisSessionStore`                           |
| Load-balanced servers share session metadata                                                | `RedisSessionStore`                           |
| Notifications or resource updates must reach clients connected to another instance          | `RedisSessionStore` plus `RedisStreamManager` |
| Sampling, elicitation, or roots requests need client responses routed back across instances | `RedisSessionStore` plus `RedisStreamManager` |

`RedisSessionStore` does not store active stream controllers. Use `RedisStreamManager` for distributed server-to-client delivery.

## Install Redis support

Install a Redis client library and provide an already-connected client to mcp-use.

```bash theme={null}
npm install redis
```

The Redis classes are also compatible with clients that implement the minimal Redis client contract documented in the API reference. Distributed stream routing requires Pub/Sub support, including subscribe and unsubscribe operations on the Pub/Sub client.

## Persist session metadata

Use `RedisSessionStore` when reconnecting clients should keep session metadata after a restart or deploy.

```typescript theme={null}
import { MCPServer, RedisSessionStore } from "mcp-use/server";
import { createClient } from "redis";

const redis = createClient({
  url: process.env.REDIS_URL,
});

await redis.connect();

const server = new MCPServer({
  name: "redis-session-server",
  version: "1.0.0",
  sessionStore: new RedisSessionStore({
    client: redis,
  }),
});

await server.listen(3000);
```

Use the API reference when you need custom key prefixes, TTLs, or shutdown behavior.

## Add distributed stream routing

Use `RedisStreamManager` when an active client stream may live on one server while another server needs to send a notification or route the response to a server-to-client request. Pub/Sub needs a dedicated Redis connection, so create a duplicate client.

```typescript theme={null}
import {
  MCPServer,
  RedisSessionStore,
  RedisStreamManager,
} from "mcp-use/server";
import { createClient } from "redis";

const redis = createClient({ url: process.env.REDIS_URL });
const pubSubRedis = redis.duplicate();

await redis.connect();
await pubSubRedis.connect();

const server = new MCPServer({
  name: "distributed-session-server",
  version: "1.0.0",
  sessionStore: new RedisSessionStore({
    client: redis,
  }),
  streamManager: new RedisStreamManager({
    client: redis,
    pubSubClient: pubSubRedis,
  }),
});

await server.listen(3000);
```

Use separate Redis connections for normal commands and Pub/Sub. A client in subscriber mode cannot reliably publish or run ordinary commands.

## Verify distributed behavior

Before using Redis in production, verify these cases in an environment that resembles your deployment:

* Restarting one server does not force clients to re-initialize.
* A notification or resource update published by one instance reaches a client stream connected to another instance.
* Sampling, elicitation, or other server-to-client request responses route back to the instance waiting for them.
* Redis connection shutdown is handled when the server exits.

If you only run one instance and can lose sessions on restart, [In-Memory Storage](/typescript/server/session-management/memory-storage) is simpler.

## Next steps

<CardGroup cols={2}>
  <Card title="Redis session store API reference" icon="database" href="/typescript/api-reference/server/sessions#redissessionstore">
    Look up Redis session store options and methods.
  </Card>

  <Card title="Redis stream manager API reference" icon="radio" href="/typescript/api-reference/server/sessions#redisstreammanager">
    Look up distributed stream routing options and methods.
  </Card>

  <Card title="ServerConfig API reference" icon="server" href="/typescript/api-reference/server/server-config">
    Look up `sessionStore` and `streamManager` fields.
  </Card>

  <Card title="Session management example" icon="github" href="https://github.com/mcp-use/mcp-use/tree/main/libraries/typescript/packages/mcp-use/examples/server/features/session-management">
    Compare your setup with a runnable Redis-backed example.
  </Card>
</CardGroup>