Four ordinary Kubernetes YAML files become four ConfigHub Units without a chart or render step.
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
Many teams already have reviewed Kubernetes YAML. They should not have to wrap it in a chart or run another renderer before ConfigHub can record it.
This example proves the simple import path before promotion, delivery, or fleet operations are added.
What this example shows
- The starting files contain one Namespace, ConfigMap, Deployment, and Service.
- ConfigHub stores one Unit per Kubernetes object.
- The source and stored object-set hashes match.
- The shared catalog checks are attached after upload.
Where each setting comes from
| Place | What this Space records |
|---|---|
| Starting configuration | The four files under examples/plain-yaml/acme-web are the complete starting configuration. No Helm values or templates are involved. |
| ConfigHub changes | This base records the four supplied objects without a later ConfigHub edit. Any future change will appear in Unit revision history or a derived variant. |
| Install work | The Namespace is included. The example has no external Secret, CRD, hook, or setup Job. |
| Live cluster | No cluster apply or workload observation has run for this import example. |
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 four Kubernetes Units to read the same objects as the source files.
- The links between the Deployment, ConfigMap, and Service.
Evidence and source
Limits
- This receipt proves exact ConfigHub import. It does not prove deployment, promotion, rollback, or workload health.