The Vault base used to show environment variants, placeholders, promotion, and recorded render context.
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
Vault is useful because it is sensitive and operationally specific. It forces the demo to show how config records, variants, and gates fit together.
The base is where the chart output and the recorded render context meet.
What this example shows
- A rendered chart can carry a render record next to the workload YAML.
- Environment variants can inherit from the base and add their own settings, policies, and release choices.
- Placeholder checks prevent a known placeholder value from reaching a cluster by accident.
Where each setting comes from
| Place | What this Space records |
|---|---|
| Starting configuration | The recipe and render-record Units identify the Vault chart inputs that produced the starting objects. |
| ConfigHub changes | Later base revisions add the shared telemetry and release-track annotations. Those edits are separate from the original Helm values. |
| Install work | The Vault chart page records prerequisites, placeholder policy, and any chart-specific setup work. |
| Live cluster | Live results are evidence against these Units. They do not become new desired settings automatically. |
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 render-record YAML.
hashicorp-vault-env-dev,hashicorp-vault-env-staging, andhashicorp-vault-env-prod.
Evidence and source
Limits
- The render-record pattern is shown as an example in this org, not yet one record per rendered object.