Redis

Besides key-value storage, Redis provides publish and subscribe messaging, in which a client publishes a message on a channel and every subscribed client receives it. Stalwart can use this messaging as the coordinator of a cluster. A cluster already requires a Redis-based in-memory store, so Redis coordination adds no service to operate. Valkey is supported in the same way.

Redis publish and subscribe does not store messages. A node that is not connected when a notification is published therefore never receives it. Stalwart compensates for this as described in Coordinator outages: a node that reconnects discards its caches and checks its queues.

Configuration

Redis coordination is selected on the Coordinator object (found in the WebUI under Settings › Cluster › Coordinator). The main decision is whether coordination shares the Redis deployment of the in-memory store or uses one of its own, and four variants cover the cases.

Default reuses the connection of the in-memory store. It has no fields, and it is used when coordination and the in-memory store share one Redis deployment. The in-memory store must then be Redis, RedisCluster, RedisSentinel or, in the Enterprise edition, Sharded. With a sharded store, the first member of the store carries the coordination messages.

The other three variants open a separate connection. Redis connects to a standalone server given in url. RedisCluster connects to a Redis Cluster given in urls, with the credentials in authUsername and authSecret. RedisSentinel connects through the Sentinels given in urls to the primary named in serviceName.

These explicit variants are used when coordination should run on a different Redis deployment from the in-memory store. They have the same fields as the corresponding in-memory store variants, including connectTimeout, allowInvalidCerts and the connection pool settings, which are described in Redis.

A separate coordinator does not remove the requirement on the in-memory store. Even with an explicit Redis coordinator, the in-memory store must be Redis-based, because the registry refuses a coordinator while the in-memory store is the local default.

The following coordinator reuses the in-memory store’s Redis connection:

{
  "@type": "Default"
}

The following coordinator connects to a separate Redis Cluster:

{
  "@type": "RedisCluster",
  "urls": {
    "redis://redis-1.example.com:6379": true,
    "redis://redis-2.example.com:6379": true,
    "redis://redis-3.example.com:6379": true
  },
  "authUsername": "stalwart",
  "authSecret": {"@type": "EnvironmentVariable", "variableName": "REDIS_PASSWORD"}
}