feat(deploy): make coordination redis a first-class chart and terraform surface

[yassin-berriai]

Relevant issues

Linear ticket

Resolves LIT-3861

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Merge after #32661, which adds the general_settings.coordination_redis block this renders. The charts keep working against an older proxy either way, since an unrecognized general_settings key is ignored and the existing REDIS_* env vars still drive the fallback

Screenshots / Proof of Fix

The deploy artifacts here are chart and module templates, so the proof is tool-native rendering rather than a live proxy

Standalone Redis enabled renders the block into the proxy config

$ helm template t helm/litellm-helm --set redis.enabled=true -s templates/configmap-litellm.yaml
      general_settings:
        coordination_redis:
          host: os.environ/REDIS_HOST
          password: os.environ/REDIS_PASSWORD
          port: os.environ/REDIS_PORT
        master_key: os.environ/PROXY_MASTER_KEY

Sentinel renders sentinel_nodes and service_name instead of a host and port, because pointing a plain client at a sentinel port does not work

$ helm template t helm/litellm-helm --set redis.enabled=true --set redis.architecture=replication --set redis.sentinel.enabled=true -s templates/configmap-litellm.yaml
      general_settings:
        coordination_redis:
          password: os.environ/REDIS_PASSWORD
          sentinel_nodes:
          - - t-redis
            - 26379
          service_name: mymaster
        master_key: os.environ/PROXY_MASTER_KEY

Chart tests and lint

$ helm unittest -f 'tests/*.yaml' helm/litellm-helm
Test Suites: 9 passed, 9 total
Tests:       64 passed, 64 total

$ helm unittest -f 'tests/*.yaml' helm/litellm
Test Suites: 2 passed, 2 total
Tests:       14 passed, 14 total

$ helm lint helm/litellm-helm --set redis.enabled=true
0 chart(s) failed

$ terraform fmt -recursive -check terraform/litellm/ && echo clean
clean

$ cd terraform/litellm/aws && terraform init -backend=false >/dev/null && terraform validate
Success! The configuration is valid.

$ cd terraform/litellm/gcp && terraform init -backend=false >/dev/null && terraform validate
Success! The configuration is valid.

The new suites were mutation tested rather than trusted green: reverting the sentinel helper gate, ignoring redis.coordination.enabled, dropping the user-block guard, dropping the cluster gate, always emitting REDIS_PASSWORD, and hardcoding the cluster seed port each fail at least one test

Type

🚄 Infrastructure

Changes

The proxy is gaining general_settings.coordination_redis, an explicit block for the Redis behind cross-pod rate limits, spend tracking, and the pod lock manager. This makes it a first-class deploy surface

helm/litellm-helm renders a coordination_redis stanza into the proxy config when the bundled Redis is enabled, gated on a new redis.coordination.enabled value that defaults to true, and skipped entirely when the user already supplies their own block in proxy_config. Sentinel deployments render sentinel_nodes and service_name. The existing REDIS_* deployment env stays for back-compat

helm/litellm keeps its external-Redis env wiring; its stale comment claiming the cluster nodes variable feeds Cache() is replaced with a description of the coordination fallback, and the values comments name coordination explicitly

The terraform modules already export REDIS_HOST, REDIS_PORT and REDIS_SSL from ElastiCache and Memorystore, so the environment fallback covers them with no resource changes. The README gains a coordination-redis entry and both default examples show the explicit block

This also fixes a pre-existing bug. litellm.redis.serviceName gated its sentinel branch on the standalone architecture, but the bundled Redis subchart only serves sentinel in replication mode, and renders no master Service there. REDIS_HOST therefore pointed at a Service that never existed for every sentinel user. The helper now keys off redis.sentinel.enabled alone, which changes REDIS_HOST on that path from <release>-redis-master to <release>-redis; two tests cover it

Neither chart asserted a single Redis environment variable before, so the new suites also cover the existing wiring

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[greptile-apps]

Greptile Summary

This PR promotes coordination_redis to a first-class surface in the litellm-helm chart and both Terraform modules. The litellm-helm chart gains a template-time injection of a coordination_redis block into the proxy config when the bundled Redis subchart is enabled, with sentinel support, a user-supplied-block guard, and an opt-out flag (redis.coordination.enabled). It also fixes a pre-existing bug where the sentinel service-name helper was gated on an impossible standalone + sentinel condition, meaning REDIS_HOST previously pointed at a Service that never existed for sentinel users.

• helm/litellm-helm: new coordination_redis config injection in configmap-litellm.yaml, sentinel helper fix in _helpers.tpl, a new redis.coordination.enabled value, and 9 new unit tests covering standalone, sentinel, opt-out, and user-block cases.
• helm/litellm and Terraform modules: comment and documentation updates only — the existing REDIS_* env-var wiring is described accurately as the coordination fallback, and both Terraform example files gain a commented coordination_redis override block.

Confidence Score: 4/5

Safe to merge for the common case; the one edge case (bundled Redis with auth disabled) is non-default and would have already caused issues before this PR.

The sentinel bug fix and coordination_redis injection are correct and well-tested. The only gap is that the coordination_redis block unconditionally references os.environ/REDIS_PASSWORD even when redis.auth.enabled is false, which would cause a proxy startup failure for that non-default configuration. All other paths are covered by the new test suite.

helm/litellm-helm/templates/configmap-litellm.yaml — the unconditional password env ref in the coordination_redis block warrants a second look for auth-disabled Redis deployments.

Important Files Changed

Filename	Overview
helm/litellm-helm/templates/_helpers.tpl	Bug fix: sentinel service name now correctly keys off redis.sentinel.enabled alone instead of the impossible standalone + sentinel condition; helper logic is clean and the two new tests verify both code paths.
helm/litellm-helm/templates/configmap-litellm.yaml	New coordination_redis injection logic; correctly uses deepCopy and user-block guard. Password env ref is unconditional and will break proxy startup if redis.auth.enabled is false.
helm/litellm-helm/tests/coordination_redis_tests.yaml	Comprehensive new test suite covering standalone, sentinel, opt-out, and user-supplied-block cases; YAML pattern assertions match alphabetical serialization order.
helm/litellm-helm/values.yaml	Adds redis.coordination.enabled (default true) with clear comments explaining sentinel, env-fallback, and caching independence; no structural issues.
helm/litellm/templates/_helpers.tpl	Comment-only update clarifying that REDIS_CLUSTER_NODES feeds coordination fallback, not Cache(); no logic changes.
helm/litellm/tests/redis_env_tests.yaml	New test suite covering REDIS_HOST/PORT/PASSWORD emission, cluster-node seeding, and auth-less omission for both gateway and backend deployments.
terraform/litellm/README.md	New Coordination Redis row in the parity table and a new prose section documenting the automatic REDIS_* export and override pattern; accurate and well-scoped.

_{Reviews (1): Last reviewed commit: "feat(deploy): make coordination redis a ..." | Re-trigger Greptile}

[greptile-apps]

Password ref always emitted regardless of Redis auth config

Both the standalone and sentinel branches unconditionally add password: os.environ/REDIS_PASSWORD to the coordination_redis block. If a user deploys the bundled Redis with redis.auth.enabled: false (disabling Bitnami's auth), the Bitnami subchart will not create the <release>-redis secret and the REDIS_PASSWORD env var will not be set in the pod. At startup, litellm will attempt to resolve os.environ/REDIS_PASSWORD and fail with a key error, preventing the proxy from starting.

Consider guarding the password field on redis.auth.enabled (which defaults to true in the Bitnami subchart): {{- if ne (dig "auth" "enabled" true .Values.redis) false }}. The same guard would apply in the sentinel branch.

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_coordination_redis_deploy (4b00127) with litellm_internal_staging (131aa05)¹}

Footnotes

1. No successful run was found on litellm_internal_staging (0099c6b) during the generation of this report, so 131aa05 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[veria-ai]

Medium: Redis coordination config is ignored

coordination_redis is rendered under general_settings, but the proxy startup path does not read that key when attaching Redis to the internal usage cache used by rate-limit and spend coordination. In a multi-pod chart install that relies on this new setting, an authenticated user can exceed configured RPM/TPM limits by sending traffic across pods; either wire this block into the proxy's Redis usage cache initialization or have the chart render the existing Redis cache configuration path that startup already consumes. The same env-only assumption appears in helm/litellm/templates/_helpers.tpl.

[veria-ai]

PR overview

This pull request promotes coordination Redis configuration into the deployment surfaces for the LiteLLM Helm chart and Terraform-based installs. It adds chart rendering for the new coordination Redis settings used by multi-pod deployments.

There is one open security issue: the Helm chart renders the new Redis coordination configuration in a location that the proxy startup path does not consume, so multi-pod installs may silently run without shared Redis-backed coordination. In affected deployments, an authenticated user could distribute traffic across pods to exceed configured rate or spend limits. No issues have been addressed yet, so the PR still needs the Redis configuration path to be wired into the runtime behavior or rendered through an existing consumed cache configuration path.

Open issues (1)

• Medium: Redis coordination config is ignored — helm/litellm-helm/templates/configmap-litellm.yaml:11

Fixed/addressed: 0 · PR risk: 6/10