The prod Vault environment variant in the promotion and placeholder 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
This is a careful example of custom application delivery, not just chart installation.
The important thing to inspect is how the environment records what changed and why.
What this example shows
- The environment starts from the Vault base and can carry local choices.
- Production is wired with approval gates.
- The placeholder example shows how a local real value can stay local while new safe base fields move forward.
Where each setting comes from
| Place | What this Space records |
|---|---|
| Starting configuration | The upstream link points to hashicorp-vault-demo-base, whose recipe and render record identify the Helm source. |
| ConfigHub changes | Production records spec.replicas: 3, keeps its environment settings, and requires approval before apply. |
| Install work | The base owns the chart prerequisites. Environment values, revisions, and approval gates remain separate from that setup work. |
| Live cluster | Use the linked receipts to check promotion behavior. A live-only change would still be drift, not an environment setting. |
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.
- Vault StatefulSet and Service YAML.
hashicorp-vault-demo-basefor the upstream base.
Evidence and source
Limits
- The environment is a demo lane, not a production recommendation for Vault.