Why ConfigHub?
ConfigHub makes it easy to configure software deployments using API-based tools, across multiple environments.
Read and write configuration data via APIs
With ConfigHub, the configuration of every deployed instance is stored independently in a fully explicit form. There are no templates, variables, conditionals, loops, or generators that generate 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.
The configuration data is in a standard data format with standard schemas, which is feasible to programmatically manipulate, unlike code or code-like formats. It can be read and written via APIs that can be targeted at selected configurations in selected environments.
This means that a wide variety of interoperable, composable tools (e.g., RBAC, NetworkPolicy, security, scheduling, ..., EKS) can be built to read, write, and validate the configuration, as opposed to generating the configuration using templates and editing those templates and their inputs by hand to make changes.
Configuration changes can be automated via transformations driven by data values, wherever they come from.
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. Operational changes can be made directly.
Policy enforcement can check the config directly after every change and report results immediately, unlike with templated config that has to be rendered before policy checks can be applied. Moreover, issues can be remediated directly and automatically by updating the configuration.
Configuration values can be queried across many applications and environments. Mass configuration changes are just as straightforward.
AI agents can read the configuration 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.
Variant management
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?
The key to being able to both operate on configuration with tools and also keep multiple variants of the same configuration in sync is keeping track of what variants are related to one another, what properties are intentionally different and why, and what has changed since the last sync. Git does not do this, which is why many people say that branches don't work for GitOps and that they create too many merge conflicts.
Additionally, 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 global value files which, when merged, might affect many environments.