connect-redis: Redis session storage for Express, and where it stops

The problem connect-redis solves for Express session handling

The default session store in express-session is MemoryStore, which keeps sessions in the Node process. That works for a single process and a single machine. The moment you run more than one instance behind a load balancer, a request that lands on a different process finds no session, and a restart wipes every session on the box.

connect-redis moves that state into Redis. The package describes itself as providing "Redis session storage for Express", and the README's full setup example wires a RedisStore instance into the session middleware. The audience is narrow and specific: Node teams running Express with express-session who already operate Redis, or are willing to. It is not a general session library, and it is not a Redis client. It sits between the two.

How the store talks to Redis: keys, prefixes and TTL

RedisStore implements the store interface that express-session expects. When a session is saved, the store writes the serialized session data under a key built from a prefix plus the session ID. The prefix defaults to sess:, and the README notes that it appends to whatever prefix is already set on the client itself. That detail matters if your Redis client is configured with its own namespace, because the two prefixes stack.

Expiry is where the design gets opinionated. If the session cookie carries an expires date, connect-redis uses that as the TTL. Otherwise it falls back to the ttl option, which defaults to 86400 seconds. The README states that the TTL is reset every time a user interacts with the server, and that this reset can be disabled in some instances with disableTouch. The ttl option also accepts a function that receives the session data, which is how you would generate a TTL per session rather than one global value.

The README is explicit that express-session does not update expires until the end of the request life cycle, and warns that calling session.save() manually beforehand will have the previous value. That is a real ordering constraint, not a footnote. Code that saves a session early and then reads back the expiry is working with stale data.

Installing connect-redis and wiring a first store

The README gives a single install line that pulls in the client, the store and the session middleware together. Run it in your project root:

npm install redis connect-redis express-session

After that, the README's full setup creates a Redis client, connects it, constructs the store with a prefix, and hands the store to the session middleware. The example uses the redis package's createClient and the named RedisStore export:

import {RedisStore} from "connect-redis"
import session from "express-session"
import {createClient} from "redis"

let redisClient = createClient()
redisClient.connect().catch(console.error)

let redisStore = new RedisStore({
  client: redisClient,
  prefix: "myapp:",
})

The session middleware then receives the store, with resave set to false and saveUninitialized set to false in the README's example. The comment on resave says it is required to force lightweight session keep alive, which is the touch path. What you should see after starting the app is session keys appearing in Redis under the myapp: prefix, with a TTL attached.

TypeScript users get types from the package itself. The README states plainly that you should not install @types/connect-redis.

disableTTL, disableTouch and the cleanup burden

The option most likely to cause trouble in production is disableTTL. It turns off key expiration completely, which means nothing in Redis removes a session key for you. The README says this requires the user to manage key cleanup outside of connect-redis and should only be used if you know what you are doing and have an exceptional case. It also notes that the option has no effect on express-session setting cookie expiration, so a browser cookie can expire while its Redis counterpart stays behind. If you enable disableTTL without a separate cleanup path, you are building a slow memory leak by configuration.

disableTouch is the milder trade-off. It stops the TTL reset that normally happens when express-session signals a touch. The README frames the choice: the reset keeps sessions alive when session changes are infrequent, but disabling it cuts extra calls and prevents users from holding sessions open indefinitely. It also suggests considering it when you store a lot of data on the session. The cost is that an active user can be logged out on the original TTL schedule even while they are using the app.

Serialization and the scanCount knob

Session data goes to Redis through a serializer, and the default is JSON.parse and JSON.stringify. The serializer interface is small: a parse method and a stringify method, and the README notes that parse may be async. That is the extension point for teams that need a different encoding, or that want to encrypt session payloads before they reach Redis.

scanCount controls the count parameter passed to the Redis SCAN command, used by the ids() and all() methods, with a default of 100. This is the one place the store performs bulk traversal rather than single-key reads and writes. Raising it changes how much work Redis does per SCAN call, which is a tuning decision for the size of your keyspace rather than something to set blindly.

The prefix option has a second purpose beyond namespacing. The README states that unique prefixes for different applications sharing one Redis instance limit the bulk commands exposed in express-session, specifically length, all, keys and clear, to a single application's data. Without distinct prefixes, those operations can reach across applications.

When connect-redis is the wrong tool

connect-redis only makes sense with express-session. Its peer dependencies are express-session >=1 and redis >=5, and the README's own framing is Express session storage. If your framework does not expose an express-session compatible store interface, this package has nothing to plug into.

The second boundary is operational. Choosing connect-redis means you now depend on Redis availability for session reads. That is a different failure profile from in-process memory storage, where a Redis outage is not a concern. The package does not remove that dependency, and nothing in the README suggests a fallback store.

The third boundary is version. The package.json sets engines to node >=22 and declares the redis peer dependency at >=5. If you are pinned to an older Node runtime or an older client major, the install will not line up with what this version expects.

connect-redis compared with ioredis-backed stores

The related searches show people comparing connect-redis with ioredis. The distinction is about which Redis client sits underneath, not about the store interface. connect-redis takes a client instance through its client option, and the README's example uses the redis package, which is also what the peer dependency names.

An ioredis-backed session store is a separate package that wraps ioredis instead. Both end up writing session keys to Redis with a prefix and a TTL. The practical difference is the client's feature set and connection behavior, which is where ioredis and redis diverge, and which matters if you already standardize on one of them elsewhere in the codebase. If your application already creates ioredis connections for caching or queues, adding a second Redis client library just for sessions is the cost you are weighing. The README does not document an ioredis integration for this package.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-10. The most recent release listed is v10.0.0 from 2026-07-24, following v9.0.0 in June 2025 and v8.1.0 in May 2025. The major version bumps are the upgrade signal here: v9 to v10 is a major boundary, so read the changelog before moving.

The package is MIT licensed. That is permissive and imposes no source disclosure requirement on your application, but this is a description of the licence identifier in package.json, not legal advice. The package.json declares "type": "module" and ships separate import and require entry points through its exports map, with types for each, so both ESM and CommonJS consumers are covered by the published build.

Upgrade cost is mostly the peer dependency floor. The declared peer range is express-session >=1 and redis >=5, and engines requires node >=22. A major release of connect-redis can move those floors, so the check before upgrading is your runtime version and your Redis client major, not the store API, which the README presents as a small options object.

Editorial conclusion

Adopt connect-redis when your Express app already runs express-session and you want sessions in Redis with a key prefix you control. Do not adopt it if you need a store for a framework that does not speak the express-session store interface, or if you plan to run it with disableTTL without a cleanup job. Before deploying, verify which redis client version you have (the peer dependency is redis >=5), confirm the prefix you pass does not collide with other applications on the same Redis instance, and check whether disableTouch is safe for how often your sessions change.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. tj/connect-redis on GitHub