Redis
Redis carries dispatch signals and live updates between API instances. When it is optional, when it is required, and why losing it loses no work.
Self-hosted
When you need it
| Setup | Redis |
|---|---|
| One API instance | Optional. Without REDIS_URL an in-memory queue is used. |
| Several API instances, autoscaling | Required. Dispatch and live updates must reach every instance. |
With Redis, the dispatch queue uses BullMQ with priorities and delays. A new instance learns about connected workers at once; a crashed instance's workers are forgotten after about 30 seconds, during which offers to them can go unanswered until the sweeper re-offers them.
Never the source of truth
MongoDB is authoritative. After a Redis failure or a restore without Redis data, the scheduler rebuilds dispatch from MongoDB. If Redis dies mid-task, nothing hangs: running tasks finish, and work created during the outage is dispatched when Redis returns — verified in the core's Redis tests.
Priority aging
Queued tasks age so low-priority work is not starved. BullMQ fixes a job's priority when it is added, so with Redis aging applies as of enqueue time; the in-memory queue re-evaluates it on every dispatch.
Verification status
Tested with Redis 8.10 (a Windows build), not yet on Linux or a managed Redis service.