Skip to content

ConfigHub Architecture

Service core

At the core, ConfigHub is a service that stores your configuration in a database.

We offer a multi-tenant SaaS that follows standard B2B SaaS practices. As a customer you have an organization in ConfigHub and your team members all collaborate with each other within the organization.

We also offer a self-hosted enterprise edition.

In either case, you can log in with your work account from Google Workspace and other providers and you can also set up SAML or OIDC based SSO.

The service is responsible for storing and providing access to all your config data, and orchestrating queries and change workflows. All changes to config data are revisioned so you can track what caused the change, compare to past revisions, and revert changes when necessary.

ConfigHub does not store credentials or secrets for your software infrastructure. They are stored externally however you manage them now.

Web UI, CLI, and API

ConfigHub offers a Web UI as well as a CLI. Generally all functionality is available in both the Web UI and CLI so you can choose which tool is most convenient for the task. Of course, ConfigHub also has an API.

Workers

A Worker is an API identity and also an optional software process that runs in your infrastructure and connects to ConfigHub to execute function logic.

Using a worker as an API identity allows you to write API clients that authenticate against ConfigHub with authorization-scoped access to the API.

A worker protocol makes it possible to build your own function implementations, run them in your infrastructure, connect them to ConfigHub, and let ConfigHub invoke them: external functions. This extends the built-in function library with your own code, running where your credentials and systems are. The protocol is HTTP and JSON, so a function can be written in any language; today the Go SDK is the only supported client. There are several examples of external functions that integrate existing tools, such as Kyverno, in the examples repository.

Workers used to also act as infrastructure bridges — a mechanism by which ConfigHub could reach into a Kubernetes cluster or other system to apply, destroy, refresh, and import configuration. That mechanism has been removed.

OCI Server

Configuration leaves ConfigHub by being published, not pushed.

ConfigHub provides an OCI server with Space-scoped endpoints where Releases can be downloaded as OCI images. Each Space's repository is available at oci://<host>:<port>/space/<space-slug>, and an individual Release is referenced by the latest tag or a specific manifest digest. GitOps operators such as Argo CD, Flux, or Sveltos are configured to pull from that endpoint and reconcile what they find.

This is why ConfigHub needs no access to your infrastructure. The operator already running in your cluster holds the cluster credentials and initiates every connection; ConfigHub only serves bundles. See integrating with GitOps operators.