Skip to content

feat(standalone): support Redis Sentinel connections - #54

Open
omarzeineddine-ai wants to merge 2 commits into
pontusab:mainfrom
omarzeineddine-ai:feat/standalone-redis-sentinel
Open

feat(standalone): support Redis Sentinel connections#54
omarzeineddine-ai wants to merge 2 commits into
pontusab:mainfrom
omarzeineddine-ai:feat/standalone-redis-sentinel

Conversation

@omarzeineddine-ai

Copy link
Copy Markdown

Problem

Closes #44

The standalone Docker image only accepts REDIS_URL, so Sentinel-managed Redis deployments can't use it — there's no way to hand BullMQ a sentinel connection.

Solution

Connection config moves to a small, tested connectionFromEnv() module with two modes:

Variable Role
REDIS_SENTINELS Comma-separated host:port list (port defaults to 26379). Enables Sentinel mode.
REDIS_SENTINEL_NAME Master group name (e.g. mymaster). Required with REDIS_SENTINELS.
REDIS_SENTINEL_PASSWORD Auth for the sentinel nodes themselves.
REDIS_USERNAME / REDIS_PASSWORD / REDIS_DB Optional, apply to both modes.

ioredis (via BullMQ) resolves the current master through the listed sentinels and follows failovers automatically. The same connection object flows into the alert store, so alert persistence follows the master too.

REDIS_URL behavior is unchanged — the URL path emits the exact { url } connection object the old code inlined (pinned by a unit test). One deliberate change: a container started with no connection config now fails fast with Set REDIS_URL (single instance) or REDIS_SENTINELS + REDIS_SENTINEL_NAME (Sentinel) instead of the old { url: undefined }, which made ioredis silently dial localhost:6379 inside the container.

Docs updated: standalone README env table + Sentinel example, and the standalone-docker docs page.

Verification

  • 9 unit tests (connection.test.ts): sentinel parsing (defaults, malformed entries), mode precedence, required-name validation, auth/db passthrough, and the exact URL-mode output shape.
  • Ran the built bundle against a plain Redis via REDIS_URL: healthcheck and /api/queues serve live counts — single-instance behavior unchanged.
  • Verified the fail-fast error on a container with no connection config.
  • tsc --noEmit, bun build, and biome all pass.

Heads-up for reviewers: I did not run a live Sentinel failover topology against the built image — sentinel mode is verified at the config-shape level (the options object handed to BullMQ is standard ioredis sentinels/name config). Happy to add a compose-based sentinel smoke test if you'd like one in-repo.

The standalone server only accepted REDIS_URL, so Sentinel-managed
Redis deployments couldn't use the Docker image. Connection config now
comes from connectionFromEnv():

- REDIS_SENTINELS (comma-separated host:port, port defaults to 26379)
  plus REDIS_SENTINEL_NAME select Sentinel mode; ioredis resolves the
  current master through the sentinels and follows failovers.
- REDIS_SENTINEL_PASSWORD, REDIS_USERNAME, REDIS_PASSWORD and REDIS_DB
  are optional and apply to both modes.
- REDIS_URL behavior is unchanged, except a container started with no
  connection config at all now fails fast with a clear message instead
  of silently dialing localhost:6379 inside the container.

Closes pontusab#44
@vercel

vercel Bot commented Jul 17, 2026

Copy link
Copy Markdown

@omarzeineddine-ai is attempting to deploy a commit to the Pontus Abrahamsson's projects Team on Vercel.

A member of the Team first needs to authorize it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support for Redis Sentinel in standalone

1 participant