Skip to content

Integrating with GitOps operators

ConfigHub works alongside GitOps operators such as ArgoCD, Flux, and Sveltos. Rather than committing rendered manifests to a Git repository, you publish the configuration ConfigHub manages to its built-in OCI endpoint and point your GitOps operator at that endpoint. The operator continues to reconcile the cluster; ConfigHub becomes the source of the configuration it pulls.

Note

This guide is preliminary. The exact URL to pull for a given Space and Target, and the recommended way to create the ArgoCD Application, Flux HelmRelease/Kustomization, or Sveltos resource, are still being finalized and will be documented here shortly.

The recommended way to integrate with a GitOps operator is:

  1. Create a server worker. OCI delivery is handled by a bridge hosted inside the ConfigHub server, so there is no external worker process to run.

    cub worker create --space app-dev --is-server-worker server-worker

  2. Create a Target corresponding to the cluster, with ProviderType OCI and ToolchainType Kubernetes/YAML. The OCI bridge publishes each Unit's data verbatim to ConfigHub's OCI registry; it performs no remote apply of its own.

    cub target create cluster '' app-dev/server-worker \
    --space app-dev \
    --provider OCI --toolchain Kubernetes/YAML

  3. Attach your Units to the Target. As with any Target, set each Unit's TargetID — for example with cub unit set-target or when creating a variant with cub variant create --target.

  4. Configure the GitOps operator to pull from the OCI endpoint. ConfigHub exposes an OCI endpoint at oci://oci.hub.confighub.com:443 (see the OCI document). Configure your ArgoCD Application, Flux HelmRelease/Kustomization, or Sveltos resource to pull the bundle for this Space and Target from that endpoint.

    The precise URL to pull, and the recommended shape of the operator resource that references it, are still being implemented and will be documented here.

Publishing updated configuration

Once the operator is pulling from the OCI endpoint, publish updated configuration for a variant with cub release publish. A release bundles the Units in a Space that are assigned to a given Target, captured at a point in time, and serves that bundle as an immutable OCI artifact:

cub release publish app-dev app-dev/cluster

This is the recommended way to publish an updated configuration for a variant. After you change or promote a variant, publish a new release so the GitOps operator picks up the change on its next reconcile. To pin the bundle to a tagged Revision of each Unit rather than its head, pass --revision <tag>.

See the change and apply workflow for how releasing fits into a broader change-and-rollout flow.