Introduction

Running two Helm charts with a shared Redis dependency is common when multiple services use the same cache or queue backend. The main design question is whether Redis is deployed once at platform level or as a subchart per application. Clear ownership and stable connection configuration keep this pattern reliable.

Core Sections

Choose a shared dependency strategy

You can share Redis in two common ways. One approach deploys Redis as a separate infrastructure chart and both application charts consume its endpoint. The other approach keeps Redis as a dependency in one parent chart and injects connection values to each workload.

For most teams, a standalone Redis release with explicit service naming gives cleaner lifecycle management. Application chart upgrades then do not recreate or reconfigure core stateful infrastructure unexpectedly.

Define Redis dependency in chart metadata

If using chart dependencies, declare Redis once and control enablement through values.

1# Chart.yaml
2apiVersion: v2
3name: platform-apps
4version: 0.1.0
5dependencies:
6  - name: redis
7    version: 19.0.0
8    repository: https://charts.bitnami.com/bitnami
9    condition: redis.enabled

1# values.yaml
2redis:
3  enabled: true
4
5serviceA:
6  redisHost: platform-apps-redis-master
7serviceB:
8  redisHost: platform-apps-redis-master

This keeps connection host names in one place and reduces drift between services.

Inject shared connection settings into both charts

Each chart should consume Redis host, port, and credentials via values and secrets, not hardcoded templates.

1# template snippet
2env:
3  - name: REDIS_HOST
4    value: {{ .Values.redisHost | quote }}
5  - name: REDIS_PORT
6    value: {{ .Values.redisPort | quote }}

When services need different Redis databases or prefixes, configure those separately while sharing the same endpoint.

Plan upgrade and failure boundaries

Shared dependencies create coupling. Document which team owns Redis upgrades, backup, and restore. Run integration checks after Redis version changes so both charts are validated against new behavior.

Operationally, this ownership model is more important than template style. Without clear ownership, shared dependencies become hard to evolve safely.

Verification and operational checks

After implementation, run a short verification sequence that includes one expected success path, one malformed input path, and one missing dependency path. This keeps behavior predictable and catches regressions before integration testing. Write the exact commands in your team runbook so new contributors can repeat the checks without guessing hidden assumptions.

Team adoption checklist

To keep this solution maintainable, assign ownership for version updates, runtime checks, and documentation quality. A lightweight weekly check that records tool versions and key command output is usually enough to detect drift early. When failures occur, capture the error text, environment details, and last known working revision so incident response stays efficient.

Long term maintenance guidance

To avoid repeat regressions, add one concise maintenance note that documents assumptions, supported versions, and the expected data contract or command contract. Include a date stamp and owner so future updates are accountable and easy to coordinate. Pair that note with a small automated check in CI that exercises the critical path using representative inputs.

When behavior changes because of library upgrades or infrastructure changes, update the note and test in the same pull request. That discipline keeps implementation and documentation aligned and reduces confusion during incident response. Over time, this habit lowers onboarding friction and improves confidence in production changes.

Common Pitfalls

• Deploying separate Redis instances unintentionally for each chart.
• Hardcoding Redis host names in templates instead of values.
• Coupling app releases to infrastructure upgrades without planning.
• Sharing one Redis endpoint without namespace key separation.
• Missing backup and restore ownership for stateful dependencies.

Summary

• Decide early whether Redis is platform managed or chart managed.
• Centralize dependency metadata and connection values.
• Inject endpoint settings through values and secrets.
• Define ownership for upgrades, backup, and recovery.
• Validate both services after any Redis change.