Why ConfigHub?
ConfigHub makes it easy to configure software deployments across multiple environments.
Software is never deployed just once. It may start with a single deployment, but before you know it, you're managing a matrix of variations: minimize cost in dev, prod-parity for staging, proper scaling and monitoring for prod, and so on. Then you roll out in multiple regions, integrate to regional services and adjust for regional needs.
You end up with dozens of environments that each has some variation. Now multiply that by the total number of software components you have and deal with the entangled mess of connecting them to each other across this matrix. How do you manage this?
Fully Rendered (WET) Config
With ConfigHub, the configuration of every variant is stored independently in its native, fully rendered, WET (Write Every Time) form. There are no templates, variables, conditionals, loops, or generators that create configuration on the fly. Every value specific to an environment is stored literally in the config.
For example in a Kubernetes deployment, ingress hostnames, environment variables, image tags, service dependencies, resource requests, etc are all stored in their proper place in the YAML instead of being interpolated dynamically via template variables and input values.
That means the config is always "ready to go": Make a simple edit to the config and the live resources can be updated without going through a complex process of version-control incantations followed by CI/CD pipeline runs.
It also means that a wide variety of deterministic, composable tools can be built to read, write, and validate the configuration. The configuration data is in a standard data format with a standard schema, which is much easier to programmatically manipulate compared to code or code-like formats.
Humans can read the config and understand it. The hello-world app receives ingress on helloworld.example.com route, not {{ .Values.ingress.host }}. The VPC has port 8080 open, not var.service_port.
Configuration values can be queried across many applications and environments. Mass configuration changes are just as straightforward.
Policy enforcement can check the config directly and report results immediately unlike with templated config which has to be rendered before policy checks can be applied. Moreover, issues can be remediated automatically by updating the configuration.
Changes can easily be isolated to one environment with no risk of collateral damage because each config is independent and can be independently changed. This is unlike changes to templates and value files which, when merged, might affect many environments.
The configuration can be updated from the live state automatically, as opposed to updating complex templates manually after someone "breaks glass" and makes a change to the live state directly. Making such changes is also less necessary, since making changes through ConfigHub is more straightforward, more isolated, and faster than through a rendering and deployment pipeline.
And many more. It's a different paradigm.