The Socket.IO Redis adapter trusts Redis completely, and connection state recovery is still missing

Two Redis clients relay cross-server broadcasts

The adapter lets several Socket.IO servers act as one. You give createAdapter a publishing client and a subscribing client, and broadcasts are delivered to local matching clients and forwarded through Redis Pub/Sub for delivery to clients on other servers. The pattern is the same in every example: build pubClient, call duplicate() to get subClient, connect both, then pass them in.

import { createClient } from "redis";
import { Server } from "socket.io";
import { createAdapter } from "@socket.io/redis-adapter";

const pubClient = createClient({ url: "redis://localhost:6379" });
const subClient = pubClient.duplicate();

await Promise.all([
  pubClient.connect(),
  subClient.connect()
]);

const io = new Server({
  adapter: createAdapter(pubClient, subClient)
});

io.listen(3000);

Two clients are needed because a Redis connection in subscriber mode cannot also publish. The installation is a single command, npm install @socket.io/redis-adapter, and the package declares socket.io-adapter ^2.5.4 as a peer dependency.

Redis is treated as trusted infrastructure, and nothing on the channels is signed

The security notice is the most consequential paragraph in the README. The adapter assumes Redis is part of the trusted internal infrastructure. Messages on Pub/Sub are not signed, encrypted or authenticated by the adapter, and anyone able to publish to the adapter channels may be able to inject packets or control messages.

The practical rule is that Redis must not be exposed to untrusted networks or shared with untrusted clients. The project points to Redis ACLs, authentication, TLS, firewall rules, private networking and dedicated credentials or channel permissions as the protections to use. All of that sits outside the adapter. A team sharing one Redis instance between the Socket.IO cluster and an unrelated application with weaker access control has widened the set of parties who can publish into live sockets, so give the adapter its own credentials and channel permissions.

Four client setups cover redis and ioredis, standalone and cluster

The README gives a separate example for each combination. With the redis package, createClient serves a single node and createCluster takes rootNodes with one url per node, such as redis://localhost:7000 to 7002. With ioredis, new Redis() is the standalone case and new Cluster takes an array of host and port objects.

The ioredis single-node version differs in one detail: its example has no Promise.all connect step, because ioredis connects on construction. The redis examples call connect() on both clients first and use top-level await, so they need an ES module context. The default key is socket.io, which prefixes the Pub/Sub channel names, and requestsTimeout is 5_000, the point at which the adapter stops waiting for responses to a request. A third option, publishOnSpecificResponseChannel, defaults to false.

Sharded Pub/Sub needs Redis 7.0 and specific client versions

Sharded Pub/Sub arrived in Redis 7.0 to help scale Pub/Sub in cluster mode, and the adapter exposes it through a separate function, createShardedAdapter. It is a different call from createAdapter, so switching means editing the server setup.

Each client has its own floor. For redis the minimum is Redis 7.0 and [email protected]. For ioredis it is Redis 7.0 and [email protected], and the shardedSubscribers option must be set to true in the Cluster options or sharded Pub/Sub does not turn on:

const pubClient = new Cluster(
  [
    {
      host: "localhost",
      port: 7000,
    },
  ],
  {
    shardedSubscribers: true,
  }
);

The repository's own docker-compose.yml starts redis:7 on port 6379 and a grokzen/redis-cluster:7.0.10 image on ports 7000 to 7005, which is the quickest way to try both modes locally.

Connection state recovery is the one feature marked NO

The feature table lists what each Socket.IO server version needs. Socket management requires 4.0.0 and is supported since adapter 6.1.0. Inter-server communication requires 4.1.0, supported since 7.0.0. Broadcast with acknowledgements requires 4.5.0, supported since 7.2.0. Connection state recovery requires 4.6.0 and is marked NO.

That last row has a direct consequence. An application that turns on Socket.IO's connection state recovery to restore missed packets after a short disconnect cannot rely on this adapter to provide it. Applications may need to resynchronize state after reconnection because this adapter does not provide connection-state recovery. The README does not point to a workaround, so anyone who needs recovery should check whether another adapter fits before committing.

The compatibility table ties adapter major versions to Socket.IO majors

Adapter versions track Socket.IO server versions closely. 4.x pairs with Socket.IO 1.x, 5.x with 2.x, 6.0.x with 3.x and 6.1.x with 4.x. From 7.x on, the requirement is Socket.IO 4.3.1 and above. The newest release is 8.3.0, tagged on 13 March 2024, after 8.2.1 on 14 May 2023 and 8.2.0 on 2 May 2023.

The last push to the repository was on 22 June 2026, and the repository is not archived. The latest tagged release is therefore more than two years old, so a newer commit on main has not been published to npm under a version number in the information available. The package declares engines node >=10.0.0. Its three runtime dependencies are debug, notepack.io and uid2, and the compiled output ships from dist/ after the prepack step runs tsc.

Tests run against real Redis, with formatting checked first

The test script chains four steps: npm run format:check, tsc, then nyc mocha with ts-node, started through test/test-runner.ts. The dev dependencies include both redis ~5.10.0 and an alias, redis-v3, that installs redis@^3.1.2, so the suite exercises the old and new client APIs. ioredis ^5.9.1 and socket.io ^4.6.1 are present too. Prettier ^2.8.7 enforces the style on lib/ and test/.

The docker-compose.yml supplies the Redis instances those tests would talk to. Contributors should start it before running the suite, which is the only evidence in the repository of how the tests expect to reach Redis. Nothing here describes benchmark numbers or latency, so the cost of a broadcast through Redis relative to a single server is not documented and has to be measured in your own deployment.

Editorial conclusion

This adapter suits a team that already runs several Socket.IO 4.x servers behind a load balancer and keeps Redis on a private network it controls. It does not suit setups that expose Redis to untrusted clients, or that depend on connection state recovery. Before adopting it, check your Socket.IO server version against the compatibility table, then confirm that Redis authentication, TLS or network isolation is in place, since the adapter adds none of those itself.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. socketio/socket.io-redis-adapter on GitHub