The Redis starting point for the environment promotion demo.
Start here when you open this Space in Hub. This page explains the problem this example is meant to show, what to inspect, why it matters, and where the evidence lives.
Why this example exists
Helm can install Redis. The harder operations problem is what happens after install, when teams create staging and production versions and later upgrade the chart.
This example keeps the base chart output and the later environment changes separate enough to audit.
What this example shows
- A chart render can become an application base instead of a one-off install.
- The base receives upstream chart refreshes. Environment Spaces can then take those refreshes without losing their local edits.
- This is the beginning of the 25.5.3 to 27.0.0 Redis upgrade story.
Where each setting comes from
| Place | What this Space records |
|---|---|
| Starting configuration | The base started as the recorded bitnami/redis default Helm render at 25.5.3, and was later refreshed from the recorded 27.0.0 render. |
| ConfigHub changes | The base carries the shared chart output. Environment-only decisions belong in staging or production revisions, not in this base. |
| Install work | Use the Redis chart page for the selected base's Secret requirement and other prerequisites. |
| Live cluster | The upgrade proof compares the reviewed desired objects with a throwaway cluster; cluster state does not rewrite this base. |
If an upstream change and a local ConfigHub revision touch the same field, review the overlap before promotion.
What to inspect in Hub
- This README.
- The Redis workload YAML to see the captured render.
bitnami-redis-stagingandbitnami-redis-prodto see environment versions.
Evidence and source
Limits
- The Redis demo is a worked example, not a claim that every Redis values combination has been proven.