Skip to main content
A supervisor’s Overview is the page Celum opens when you pick a supervisor. It is the first entry in the sidebar, at /s/<supervisor>. It sums the supervisor up and sends each area to its own page. Opening it needs supervisor:GetSummary on krn:celum:supervisor:<supervisor>. Without it, the sidebar has no Overview entry. A supervisor you cannot see at all answers with a not-found page.

​
The header

The header names the supervisor (Default for the built-in __default__ one). Beside the name is the supervisor’s label, such as talos, and under it the address of its API server. Two controls sit on the right.

​
Continue

Continue takes you back to the last tenant cluster or VM page you opened. It can point to a workload on another supervisor. Hover over it to see the workload’s name, its kind and its supervisor. The list lives in this browser’s local storage, kept apart for each identity that signs in. It holds the last eight workloads, and the button shows the most recent one. Nothing is stored on the server, so the button does not follow you to another browser. Until you open a cluster or VM page, it does not appear. It has no API and no MCP tool.

​
Refresh Cache

Refresh Cache makes the backend rebuild this supervisor’s cached lists now, instead of when they expire. It rebuilds the tenant clusters and their health, the Kubernetes versions, ClusterClasses, StorageClasses, availability zones, namespaces, VM classes, the LoadBalancer address and the network-policy coverage map. It changes nothing on the supervisor. The rebuild runs in the background, and the page reloads a second and a half after you click. On a slow supervisor the page can still show the old answer then; reload it again a few seconds later. Refreshing needs supervisor:Refresh on krn:celum:supervisor:<supervisor>.

​
The licence strip

The coloured strip under the top bar is not part of this page: it sits above every page. It appears only while the licence needs attention: during a trial, when a trial or a licence is about to end, during the grace period, when activation is due, and when Celum is read-only. It says how many days are left. Where licensing is not enforced, it says what would happen once it is. If you hold license:Update, the strip also carries a Manage licence link to Settings → Licence. Anyone signed in can read the state behind it, with GET /api/license or the MCP tool get_license_status. See Licence.

​
The tabs

A tab appears because of the supervisor’s label, not because its component is installed. A talos supervisor shows all five tabs before onboarding has run, and each panel then says what is missing. A supervisor with any other label shows Summary only. You set the label in Settings → Kubeconfigs; see Register a supervisor. The Storage tab asks for ceph:GetStatus whatever backend the supervisor runs, LINSTOR and NFS included. The open tab is kept in the address as ?tab=, with the values summary, infrastructure, storage, monitoring and capi. A reload or a shared link therefore opens the same tab. A link to a tab you do not have opens Summary.

​
Summary

The cards below appear from top to bottom. A card with nothing to show is left out. The same data over the API and MCP:

​
Helm releases

The Helm Releases panel at the foot of Summary lists every Helm release on the supervisor itself, in every namespace, sorted by release name. It appears on a supervisor labelled talos to anyone who holds helm-release:List on krn:celum:supervisor:<supervisor>:cluster:<supervisor>:helm-release:*. A grant scoped to a project does not reach the supervisor’s own releases. The columns are Release, Namespace, Chart, Version, Status (the Helm status, such as deployed or failed), Source, Rev (the Helm revision) and Updated. Source says who manages the release, which decides what an edit does:

​
The platform’s releases

Some Flux releases belong to the platform: Celum installed them during onboarding, such as cilium, cert-manager, kube-prometheus-stack or cluster-agent. A release counts as the platform’s when Celum wrote its HelmRelease (app.kubernetes.io/managed-by: k8s-gate) and it is not an app install. An app install carries nuvira.dev/source: app-install, or pulls its chart from a HelmRepository whose name starts with app-. Apps you install with Install App and exporters you install from the Monitoring tab are therefore not platform releases. This panel does not uninstall a platform release, and it changes only its values. Removing cilium, cert-manager or cluster-agent takes the supervisor’s network, certificates or agent with it, so a platform release is removed where Celum installed it, usually its onboarding step.

​
Install an app

Install App opens Add Helm Release, a wizard in three steps.
1

Choose a chart

Search the enabled entries of the app catalog. Each entry shows the version it pins.
2

Configure release

The step says Installing into the supervisor: a namespace here is a project on this supervisor.
  • Release name starts as the app’s name.
  • Namespace starts as the app’s target namespace. The list holds the namespaces you may see; without the grant to list them, you type one.
  • Chart version is the version the catalog entry pins. You cannot change it here.
  • Chart parameters appear when the app declares parameters. Fill in every one marked * before Next is enabled.
  • Create namespace if missing is on by default.
  • Atomic install has no effect on a supervisor; see below.
  • Pull chart through local Harbor mirrors the chart into the site’s chart registry and installs it from there.
3

Review & install

Check the summary and the values.yaml editor, which starts with the app’s values template. Expand opens a larger editor. Install release starts the install and streams its log.
On a supervisor, an install goes out through Flux. Celum registers the chart’s repository as a Flux HelmRepository named app-… in flux-system, or uses the mirror. It then writes a HelmRelease named after the release in the namespace you chose, labelled as an app install, and helm-controller installs the chart. Flux retries a failed install up to three times, which is why Atomic install does nothing here.
  • A catalog entry without a pinned version is refused: Celum never writes a HelmRelease with a floating version.
  • An install into the namespace and name of a platform release is refused.
  • The values the release gets are the app’s values template, with your values from the editor merged over it key by key. Deleting a key in the editor therefore does not remove it.
After writing the HelmRelease, the log follows it for up to five minutes while helm-controller installs the chart, and shows each change in its state.
  • Installed means helm-controller reports the release Ready.
  • Failed means helm-controller gave up after its retries, and the log names its reason. For an upgrade that was rolled back, that is the failure, not the rollback. Until then a failed attempt is shown as progress with helm-controller’s reason, because Flux tries it again.
  • Still reconciling means neither happened within five minutes, or the HelmRelease is suspended. The last log line says where it stood. Watch the release’s Status in the panel.
Once the HelmRelease is written you can close the dialog. Flux carries on, and the panel shows the outcome.
Installing needs helm-release:Install on krn:celum:supervisor:<supervisor>:cluster:<supervisor>:helm-release:*. The chart list needs app:List on krn:celum:app:*, and the namespace list needs discovery:ListNamespaces on krn:celum:supervisor:<supervisor>:discovery:*.

​
Edit values

The pencil on a row opens the release in a side panel, with its chart, version and revision. Chart version offers another version only when all of these are true: the chart is in the enabled app catalog, the catalog entry pins a version, and that version is newer than the one installed. The picker then offers exactly that version. Otherwise the panel says why the edit changes values only: the release belongs to the platform, the chart is not in the catalog, you lack app:List, or the catalog has nothing newer. Values holds the values of the deployed Helm revision: what was set for this release, not the chart’s defaults. Credentials read as __celum_redacted__. Leave a masked value as it is to keep the deployed value, or replace it to set a new one. A masked value at a key the deployed release does not have is refused. Save & Upgrade then depends on the release’s Source:
  • Flux: Celum patches the live HelmRelease. It replaces spec.values with what the editor holds ({} when the editor is empty), and writes the chart name, the version and the name of the chart source. When you picked a new version, it also points the source at the catalog entry’s repository. Every other field stays as it was: the timeout, the CRD policy, the dependencies and the labels. helm-controller then upgrades the release.
  • Flux, a platform release: the same, but values only. A change of chart source is refused.
  • Manual or CAPVC: Celum runs the Helm upgrade itself. A values-only edit reuses the installed chart. The upgrade is atomic, so a failure rolls back, and it is given up after 15 minutes.
Because the editor replaces spec.values as a whole, a key you delete is removed from the HelmRelease. A value you add or change here stays until an onboarding step sets that key again. Applying the step does not reset it.
For a Flux release, the panel follows the HelmRelease for up to five minutes after the patch.
  • completed successfully means helm-controller reports the release Ready.
  • A failure appears once helm-controller has given up after its retries, with its reason.
  • Otherwise the panel says the release is not ready yet and where it stood, so watch Status.
  • You can save another Edit values on the same release while the first is followed. The first then says that the later change replaced it.
For a CAAPH release in a guest cluster, the panel says the upgrade is still rolling out; the release list shows when it is deployed.A release edited before 1.295 lost the settings its onboarding step had given it, such as cilium’s 20-minute rollout timeout. Apply that step again to restore them.
Reading values needs helm-release:GetValues, and saving needs helm-release:Upgrade, both on krn:celum:supervisor:<supervisor>:cluster:<supervisor>:helm-release:<release>. Offering a newer version also needs app:List on krn:celum:app:*.

​
Uninstall

The bin on a row asks Uninstall Release for that release and namespace, and Uninstall removes it. On a platform release the bin is disabled and says why, and the API answers 409.
  • Flux: Celum deletes the HelmRelease, and helm-controller uninstalls the chart. If the HelmRelease is not in the release’s namespace, as after a failed install, Celum deletes an app HelmRelease of that name from whichever namespace holds it. It never deletes a platform release this way.
  • Manual: Celum runs helm uninstall. A release that is already gone counts as success.
Uninstalling leaves the namespace and the HelmRepository in place.
An app installed with Pull chart through local Harbor before 1.293 reads as a platform release, because it shares the platform’s mirror repository. To uninstall it here, label its HelmRelease first: kubectl label helmrelease -n <namespace> <release> nuvira.dev/source=app-install.
Uninstalling needs helm-release:Uninstall on krn:celum:supervisor:<supervisor>:cluster:<supervisor>:helm-release:<release>.

​
The other tabs

Infrastructure is the node board: capacity, live load, disks, NICs, Fibre Channel and GPUs, with a page per node. See Infrastructure & nodes. Storage shows whatever provides storage on the supervisor, one panel per backend. See The Storage tab. Monitoring has four parts. Monitoring Stack shows the kube-prometheus-stack release, its chart and app versions and its namespace; when the stack is not installed, it links to Onboarding → Monitoring. Installable exporters lists the exporter charts you can add. Scrape Targets shows what Prometheus actually scrapes, refreshed every 30 seconds. ClickHouse Platform manages the flow store. See Monitoring and ClickHouse instances. Cluster API shows the CAPI architecture, the kinds of tenant cluster this supervisor offers with what each still needs, and the guest add-on engine. Create cluster is enabled when at least one kind can create a cluster now. The tab installs nothing: you install and change the engine in Onboarding → Cluster API. See Clusters overview.

​
Permissions