Redis for more than one replica
Add Redis so several API replicas share live workbench connections, and what else replicas need.
The API keeps no state of its own between requests, except one thing: the live connection each workbench holds to it. With one replica, that is all in one process. With two or more, a request for a workbench can arrive at a replica that does not hold its connection, and Redis is how the replicas find each other.
Run one replica without Redis, or any number with it. The Helm chart runs two by default, and the Azure template scales from one to five, so both expect Redis.
What Redis carries
| Use | How |
|---|---|
| Remote control | The replica holding a workbench's connection keeps a short-lived presence key for it and listens on a channel for that workbench. A request on any replica checks the key, publishes the request with its own reply channel, and waits for the answer. |
| Project boards and notices | Live updates to task boards and the inbox are fanned out to every replica, so a browser connected to any of them sees the change. |
| Key-bound tokens | The proof IDs workbenches send with key-bound (DPoP) tokens are remembered across replicas, so a proof replayed against another replica is refused too. |
Sticky sessions are not needed. If a replica stops, the requests it was waiting on time out (after AIOE_RPC_TIMEOUT, 30 seconds by default) and the workbenches it held reconnect to another replica.
Redis holds nothing you need to back up: everything in it is short-lived.
Set it up
Provide Redis
Any Redis 7 works: managed (Azure Managed Redis, Amazon ElastiCache, Google Memorystore) or in the cluster. The local reference layout uses redis:7-alpine. Allow the API to connect to it, and nothing else.
Set REDIS_URL on the API
Use redis:// for a plain connection, or rediss:// for TLS:
redis://redis:6379
rediss://:<access key>@<host>:<port>Keep it in a secret: in the Helm chart, a key named REDIS_URL in the API's secret; on Azure the template sets it for you from the Redis it creates.
Share the signing key
Every replica must sign with the same key. Set AIOE_SIGNING_KEY to the same value on all of them: see Platform keys and rotation. Without it, each replica generates its own key at start and logs a warning.
Check it
Each replica logs one of these lines at start:
relay broker: redis (multi-replica)
relay broker: in-process; run one replica or set REDIS_URLThe second means the replica did not read REDIS_URL.
Rate limits
Each replica allows 600 requests a minute from one client address. The count is kept by each replica, not shared through Redis, so the effective limit grows with the number of replicas.