UNOFFICIAL/EXPERIMENTAL.
For teams already running Argo CD or Flux: what changes and what stays the same when ConfigHub publishes the reviewed objects as an OCI bundle.
What stays the same
You keep your controller. Argo stays Argo. Flux stays Flux. They pull and reconcile as they do today.
ConfigHub is not asking you to replace your GitOps controller. It changes the source that the controller reads.
What changes: the source
Instead of pointing the controller at Helm values that it must render, point it at one Space release OCI published from reviewed ConfigHub Units. Every consumer reads the same Kubernetes objects. The pull URL is oci://oci.hub.confighub.com:443/space/<space>.
See cub-deployment-path.
Check the receipt for the configuration you want
There are two separate questions.
- Can one ConfigHub release OCI be consumed by Argo CD, Flux, and direct apply?
- Has the configuration you want to run been delivered and observed through your controller?
The first answer is yes. A small routed-hook fixture was published once and successfully consumed through all three paths. That proves the delivery mechanism.
The first exact catalog result is also available. The bitnami/nginx@24.0.2 http-clusterip receipt records the same release digest under Argo CD, Flux, and direct apply, with a ready NGINX workload under each.
Every other answer still depends on the catalog entry. Look for a delivery receipt on that entry's page. A receipt for the fixture or for NGINX does not prove that another selected configuration reconciled successfully.
Argo CD
An Argo Application points at the Space OCI URL, uses targetRevision: latest, and uses path .. Argo still reports sync and health as usual. The catalog records which chart/preset rows have evidence for the render, ConfigHub upload, OCI handoff, Argo sync, and live result.
Flux
Flux can use an OCIRepository plus a Kustomization for the same bundle. Flux has its own Helm path when you use Flux Helm resources. The ConfigHub OCI path is different: Flux pulls generated objects from the bundle.
Any extra work around the chart, such as hooks or setup jobs, still needs a documented action, check, target fact, blocker, or refusal. Do not assume Flux will automatically recreate Helm hook behavior in this path.
No controller
oras and kubectl can pull and apply the same Space release when you do not want a controller. This is useful for a one-shot apply or a CI step, but it also means you must be more explicit about ordering, pruning, CRDs, and setup work.
vs. raw Helm-through-Argo
Argo's native Helm support re-renders the chart inside Argo. The ConfigHub path renders first, records the inputs, and sends the reviewed objects to GitOps. That gives you one clear review point before delivery.
This does not make every Helm hook automatic. Hooks and hook-like work are handled per chart: observed, routed, target-specific, blocked, or refused. See chart-hooks-what-happens.
Hooks under GitOps
A Helm hook becomes a named piece of work, not an inherited Argo or Flux hook. For one chart the right answer may be a preflight check. For another it may be an Argo sync action, a Flux-compatible step, a target fact, or a blocker. The catalog should say which answer applies and what evidence exists.
See pathway-route-hooks-transparently.