Skip to main content
“Install this on that cluster” means two different things depending on who owns the result, and Celum keeps them apart. A platform team publishing a curated component wants one definition reused everywhere, reconciled, and surviving a rebuild. Someone debugging a tenant wants Helm, right now, on one cluster, and wants it gone again afterwards. This group explains which is which.

​
The two routes

One endpoint, and the target picks the mechanism. POST /api/clusters/{target}/helm-releases installs a catalog app. If the target names a supervisor it becomes a Flux HelmRelease; otherwise it becomes a CAAPH HelmChartProxy against the guest cluster. Setting imperative takes the direct-Helm route instead. You do not choose the mechanism — you choose the cluster, and the mechanism follows.The install streams: a 200 arrives when the stream opens, not when the install finishes. Read to the terminal done or error event. Treating the 200 as success is the single most common way to misread this endpoint.
“Pull through local Harbor” is a supervisor-only option. A guest-cluster install pulls the chart with the guest’s own credentials, so the mirror path — which stocks a supervisor registry and wires its pull secret onto a supervisor HelmRepository — has nothing to attach to. Asking for it on a guest target is refused rather than silently ignored.This is not the same mechanism as the platform’s chart sources, and the two are easy to conflate because both get called “the mirror”. A guest’s platform add-ons — CNI, the telemetry and metrics agents, the cloud-controller-manager — do resolve through the supervisor’s declaration and are written into each HelmChartProxy as an oci:// URL. That is onboarding state every guest inherits; the option refused above is a per-install choice on a catalog app. See Registry mirroring in depth.
The catalog route is declarative and survives a cluster rebuild. Direct Helm is imperative and lives only in the cluster’s own Helm state, which is exactly why it is the right tool for a fix and the wrong tool for a standard.

​
Nothing goes through Git

Celum keeps no Git repositories and commits nothing. A cluster is applied to the supervisor’s Kubernetes API when it is created, and a catalog install writes a HelmRelease or a HelmChartProxy directly; the objects on the supervisor and the Helm state in the cluster are the record. The GitOps-to-GitLab integration that once committed cluster manifests was removed in 1.202.0 — see Repositories & manifests. “GitOps” in Celum now means one thing: Flux reconciling the HelmReleases Celum applies. So the question “what is running on this cluster” has exactly one authoritative answer — GET /api/clusters/{cluster}/helm-releases, which talks Helm through the cluster’s own kubeconfig. There is no second, declared list to reconcile it against.

​
Where Flux fits

Flux runs on the supervisor. It reconciles the HelmRelease objects behind platform components — the CNI, storage backends, monitoring, cert-manager, the Cluster API stack — and behind any catalog app installed onto a supervisor. Every chart panel in the onboarding wizard is ultimately a Flux HelmRelease, which is why installing Flux is a prerequisite step rather than an option. Guest clusters have no Flux. Their catalog installs arrive as CAAPH HelmChartProxy objects reconciled from the supervisor, and their one-off installs arrive over Helm directly. Flux’s job stops at the supervisor boundary. The status probe is deliberately blunt:
installed: false means the flux-system namespace is absent or unreachable — with a message field carrying the reason when it is the latter. installed: true, ready: false means the namespace exists but not all three controllers (source-controller, helm-controller, kustomize-controller) report ready. The install is idempotent: re-running it against a healthy supervisor completes in seconds with every resource unchanged.

​
Permissions

One family covers this group:
The Image Library has its own actions, image:* on krn:celum:image:…, so granting the catalog does not grant golden images, and the other way round.
Chart discovery reads (GET /api/charts/versions, GET /api/charts/mirror-status) use platform:GetDefaults on krn:celum:platform:charts, and ArtifactHub search reuses app:List.

​
The GitOps pages

App catalog

Authoring app definitions — chart source, values template, render preview, chart validation, import and export.

Repositories & manifests

Where the GitOps repositories went, and what replaced them.

Charts & the mirror

Finding charts, the platform catalogue’s pinned versions, and mirror health.

Registry mirroring

Charts and images travel separately — what reaches a guest cluster, what stays on the supervisor, and which half is Harbor-specific.

Day-2 operations

Direct Helm against a tenant — install, upgrade, rollback.
Celum AI answers these questions from the same endpoints — list_apps for the catalog, list_cluster_helm_releases for what is actually running on a cluster, and install_app for the install itself.