In-Memory Storage

Use InMemorySessionStore when one server instance can own all session metadata and losing sessions on restart is acceptable. It stores session metadata in a JavaScript Map, so it has no external dependency and no persistence. This guide focuses on when to use in-memory storage. Use the Sessions API reference for exact method behavior and the SessionStore contract.

Use it for simple single-instance servers

In-memory storage is the production default when you do not pass a custom sessionStore. It is a good fit for small deployments, local prototypes, and services where clients can reconnect after a restart.

import { MCPServer, InMemorySessionStore } from "mcp-use/server";

const server = new MCPServer({
  name: "single-instance-server",
  version: "1.0.0",
  sessionStore: new InMemorySessionStore(),
});

await server.listen(3000);

You can omit sessionStore in production when in-memory storage is the behavior you want.

Know what is stored

Session storage keeps serializable session metadata, such as client capabilities, client info, protocol version, log level, and access timestamps. It does not persist active transports, stream controllers, or runtime objects. In-memory storage means:

Sessions disappear when the process restarts.
Other server instances cannot read the same sessions.

The default stream manager is also in-memory. That separate default means server-to-client workflows only reach clients connected to the same instance.

Choose another store when sessions must survive

Use a different store when your deployment needs persistence or distribution.

Need	Use
Hot reload during local development	File System Storage
Load-balanced or distributed servers	Redis Storage
Durable metadata outside the process	Redis or a custom `SessionStore`

For distributed notifications, resource updates, or responses to server-to-client requests such as sampling and elicitation, a shared sessionStore is not enough. Configure a distributed streamManager as well.

Verify the behavior

Use this store when these checks are acceptable:

Restarting the server creates fresh sessions.
A single process handles each connected client.
You do not need to route server-to-client messages across instances.

If any check fails, choose file system storage for development persistence or Redis for distributed deployments.

Next steps

File System Storage

Keep sessions across hot reloads in local development.

Redis Storage

Share session metadata and streams across server instances.

Sessions API reference

Look up session store methods, defaults, and contracts.

ServerConfig API reference

Look up sessionStore and streamManager configuration.

Get Started

MCP Server

MCP Apps

MCP Client

MCP Agent

Tooling

In-Memory Storage

Use it for simple single-instance servers

Know what is stored

Choose another store when sessions must survive

Verify the behavior

Next steps

File System Storage

Redis Storage

Sessions API reference

ServerConfig API reference

​Use it for simple single-instance servers

​Know what is stored

​Choose another store when sessions must survive

​Verify the behavior

​Next steps

File System Storage

Redis Storage

Sessions API reference

ServerConfig API reference

Use it for simple single-instance servers

Know what is stored

Choose another store when sessions must survive

Verify the behavior

Next steps