The dev 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.
- This lane can accept or test changes before production.
- 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 | Dev records its cost annotation and real identity-provider value as local revisions, then records the shared annotations it had to reconcile explicitly. |
| 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 dev lane includes a same-map departure that needed explicit reconciliation; that is part of the lesson.