# Redis production application The production Redis variant, with gates and promotion history separated from staging. 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 Teams need a way to explain why production differs, what was promoted, and which gates applied. This is the production side of the Redis environment demo. ## What this example shows - Production can receive reviewed changes after staging proves them. - Production gates live in the platform model instead of being buried in a Helm command. ## Where each setting comes from | Place | What this Space records | | --- | --- | | Starting configuration | The upstream link points to `bitnami-redis-base`, which holds the Helm-rendered Redis objects. | | ConfigHub changes | This Space sets namespace `redis-prod`, records its promotion history, and carries the production approval and deletion gates. Workload fields otherwise come from the base unless a revision says differently. | | Install work | Prerequisites come from the selected Redis base. Approval is a ConfigHub delivery rule, not a Helm value. | | Live cluster | Open delivery evidence when you need runtime status. This demo Space is the desired record, not a claim about a customer production cluster. | 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. - Redis workload YAML and revision history. - The `platform` Space for shared gates. ## Evidence and source - [Benchmark: upgrade keeps edit](https://github.com/confighub/helm-expt/blob/main/data/pilot-benchmark/task1-upgrade-keeps-edit.md) - [Gate-scope fix in org summary](https://github.com/confighub/helm-expt/blob/main/data/helm-org/summary.md) ## Limits - This is a demo production Space, not a live customer production environment.