My last two posts (1, 2) introduced the concept of Configuration as Data. This post introduces ConfigHub.
Configuration Data is Authoritative
As you might guess, in ConfigHub, configuration is represented, stored, and managed as structured data. It is serialized using standard data formats, such as YAML, and stored in a database within ConfigHub, with revision history and some significant metadata.
Code that operates on configuration is separate from the data, and the data is authoritative. Because the data is authoritative, the configuration does not need to be generated in a single, monolithic, unidirectional generation step using a single approach. The configuration can be modified in many steps over time by different mechanisms.
WET Configuration
The configuration data is not parameterized. 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. You also don’t need to write and maintain patches by hand the way you do with Kustomize. Every value specific to an environment is stored literally in the config.
For example in a Kubernetes Deployment, environment variables, image tags, service dependencies, resource requests, and so on are all stored in their proper places in the YAML instead of being interpolated dynamically via template variables and input values. A hello-world app receives ingress on the helloworld.example.com route, not {{ .Values.ingress.host }}.
That means the config is always “ready to go”: Make a simple edit to the config and the live resources can be updated more quickly and with fewer, simpler steps than deploying through git and CI/CD pipelines. The configuration is still versioned, however, and also can be reviewed and approved prior to applying the configuration.
Additionally, validation and policy enforcement tools 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 directly.
An API for Configuration
ConfigHub enables configuration reads and writes to be performed via API rather than through code-oriented processes and tools. The configuration data is in a standard data format with a standard schema, not code or in a code-like format that only humans and AI can manipulate.
This enables a wide variety of deterministic, composable tools to be built to read, write, and validate the configuration, in addition to AI agents. Furthermore, configuration values can be queried across many applications and environments, and mass configuration changes are just as straightforward.
Live Operations with ConfigHub
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 also 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.
Why?
These capabilities are intended to make it easier to configure software deployments across multiple environments, to unify and centralize configuration management, and to simplify how we manage operations in production.
This was a high-level introduction to ConfigHub. Future posts will show concrete examples of the experience of using ConfigHub. I’ll also dive deeper into how we approach configuration management with ConfigHub, and how it is different than and similar to Infrastructure as Code (IaC) and GitOps.
If you’ll be at KubeCon in Atlanta, you may also be interested in our session, GitOps without variables. We also have a session at FluxCon, Building the Next-Gen GitOps-based Platform With ConfigHub.
We’ve been using Infrastructure as Code (IaC) for so many years that we stopped questioning whether it was the best way or the only way, even there were plenty of reasons to question it.
IaC tools were relatively low cost to build. They reused version control for source code and sometimes reused existing templating mechanisms. They also pushed a lot of redundant work onto users. They’re not necessarily the easiest to use. However, if you’re happy with your current tools, keep using them!
On the other hand, if you are dissatisfied by current Kubernetes configuration tools and are interested in giving configuration as data a try with ConfigHub, we’re preparing to open up preview access soon for feedback, so stay tuned! If your challenges are more with application configuration or infrastructure configuration, we’re working on those and would love to hear from you about your challenges.
Feel free to email us at hello@confighub.com, or send me a message on LinkedIn, X/Twitter, or Bluesky.
If you found this interesting, you may be interested in other posts in my Infrastructure as Code and Declarative Configuration series or in my Kubernetes series.