Releases and OCI delivery

Configuration leaves ConfigHub by being published, not by being pushed.

A Release is a point-in-time snapshot of a Space's configuration, stored as an immutable OCI image. Publishing one bundles every Unit in the Space assigned to the Space's release Target, capturing each Unit at its head revision or at a specified tagged one.

In addition to the main HTTP API, ConfigHub exposes an OCI endpoint at oci://oci.hub.confighub.com:443 for pulling those bundles. Each Space has its own repository:

oci://<host>:<port>/space/<space-slug>

which is also available as Space.ReleaseURL:

cub space get app-dev -o jq='.ReleaseURL'

A Release within that repository is addressed either by the latest tag, which always resolves to the Space's most recent Release, or by a specific manifest digest, which is pinned forever.

GitOps operators such as Argo CD, Flux, and Sveltos are configured to pull from this endpoint and reconcile whatever they find. See the GitOps guide for the operator-side configuration and Publishing Releases for the commands.

Why this shape

ConfigHub needs no access to your infrastructure. The operator in your cluster initiates every connection and holds the cluster credentials, as it already did. ConfigHub only serves bundles, so there is nothing to grant it and no path from ConfigHub into your environment.

Nothing goes live implicitly. Editing configuration in ConfigHub does not change what is running; only publishing a Release does. That separation is what makes validation, review, and approval meaningful — see the change and release workflow.

What is running has a precise answer. Each Release records exactly which revision of each Unit it contains, and bundles are immutable, so a digest identifies one exact set of configuration for as long as it exists.