> ## Documentation Index > Fetch the complete documentation index at: https://docs.celum.io/llms.txt > Use this file to discover all available pages before exploring further. # Supervisor overview > The page a supervisor opens on: its five tabs, Refresh Cache, the Continue shortcut, the licence strip, and the Helm Releases panel for the supervisor's own releases. A supervisor's **Overview** is the page Celum opens when you pick a supervisor. It is the first entry in the sidebar, at `/s/`. It sums the supervisor up and sends each area to its own page. Opening it needs `supervisor:GetSummary` on `krn:celum: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. | Surface | How | | - | - | | UI | **Refresh Cache** in the header | | API | `POST /api/supervisors//refresh`. It answers `202` with `"status": "refreshing"` before the rebuild finishes. | | MCP | `refresh_supervisor` | Refreshing needs `supervisor:Refresh` on `krn:celum: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](https://docs.celum.io/administration/settings.md#licence). ## The tabs | Tab | Shown when | What it holds | Read more | | - | - | - | - | | **Summary** | always | rollups, tenant clusters, the cluster agent, the supervisor's facts and its Helm releases | [Summary](#summary), below | | **Infrastructure** | the supervisor's label is `talos` | the node board | [Infrastructure & nodes](https://docs.celum.io/platform-health/infrastructure.md) | | **Storage** | label `talos`, and you hold `ceph:GetStatus` | the storage backends the supervisor runs | [The Storage tab](https://docs.celum.io/storage/storage-tab.md) | | **Monitoring** | label `talos`, and you hold `monitoring:GetStatus` | scrape targets, the monitoring stack, exporters and the ClickHouse flow store | [Monitoring](https://docs.celum.io/platform-health/monitoring.md) | | **Cluster API** | label `talos`, and you hold `capi:GetStatus` | the kinds of tenant cluster this supervisor offers, its CAPI providers and the guest add-on engine | [Clusters overview](https://docs.celum.io/clusters/overview.md#the-capi-engine) | 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](https://docs.celum.io/get-started/register-a-supervisor.md). 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. | Card | Shown when | What it shows | | - | - | - | | **Gateway API needs attention** | label `talos`, and the Gateway API CRD bundle on the supervisor is incomplete or behind | Which CRDs are missing, and a button that adds them or re-applies the bundle. Below the bundle's minimum Cilium version, it tells you to upgrade Cilium first and offers no button. | | **Nodes**, **CPU**, **Memory**, **Storage (raw)** | the infrastructure read answered | The same rollup that opens the [Infrastructure board](https://docs.celum.io/platform-health/infrastructure.md#the-cluster-rollup). | | **Tenant Clusters** | always | The tenant clusters on this supervisor that you may see. See [Clusters overview](https://docs.celum.io/clusters/overview.md). | | **Monitoring** | label `talos` | The Grafana and Prometheus addresses on the supervisor's gateway, where they are published. | | **Power profile** | label `talos` | The CPU energy profile. See [Power profiles](https://docs.celum.io/platform-health/infrastructure.md#power-profiles). | | **Cluster agent** | always | The version the supervisor's own agent runs, how many of its pods are ready, and whether a newer version is available. You move the agent to another version from here. | | **Kubernetes Versions**, **Availability Zones**, **VM Classes** | the supervisor reports any | The versions, failure domains and VM sizes it offers. | | **Helm Releases** | label `talos`, and you hold `helm-release:List` | Every Helm release on the supervisor. See [Helm releases](#helm-releases). | The same data over the API and MCP: | Data or action | API | MCP | Permission | | - | - | - | - | | Summary: tenant clusters, versions, zones, VM classes | `GET /api/supervisors//summary` | `get_supervisor_summary` | `supervisor:GetSummary` on `krn:celum:supervisor:` | | Rollups and node board | `GET /api/supervisors//infrastructure` | `get_supervisor_infrastructure` | `supervisor:GetSummary` | | Gateway API bundle state | `GET /api/supervisors//onboarding/gateway-api-drift` | none | `cilium:GetDefaults` on `krn:celum:supervisor::cilium:*` | | Add the missing CRDs or re-apply the bundle | `POST /api/supervisors//onboarding/gateway-api-repair` | none | `cilium:Apply` on `krn:celum:supervisor::cilium:*` | | Read the cluster agent | `GET /api/supervisors//cluster-agent` | `get_supervisor_cluster_agent` | `supervisor:GetSummary` | | Move the cluster agent | `POST /api/supervisors//cluster-agent/upgrade` | `upgrade_supervisor_cluster_agent` | `supervisor:Bootstrap` on `krn:celum:supervisor:` | ## 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::cluster::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: | Source | Meaning | | - | - | | **Flux** | A Flux HelmRelease manages the release. Celum changes the HelmRelease, and helm-controller does the Helm work. | | **CAPVC** | The vCluster provider installed it for a VCluster resource. | | **Manual** | No HelmRelease manages it: someone ran `helm install`. Celum runs Helm itself, and nothing corrects drift. | | — | Celum could not tell, because the HelmRelease list did not answer. | ### 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](https://docs.celum.io/gitops/app-catalog.md). 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. > [!NOTE] > > 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. | Surface | How | | - | - | | UI | **Install App** on the Helm Releases panel | | API | `POST /api/clusters//helm-releases?supervisor=`, with `appId`, `releaseName`, `namespace`, `chartVersion`, `values`, `templateParams`, `createNamespace` and `mirrorViaHarbor`. It streams server-sent events. A client that adds `follow=rollout` to the query is followed like the dialog: `done` with release status `deployed`, `error` with helm-controller's reason, or `done` with status `reconciling`. Without it, `done` comes once the HelmRelease is written, with status `reconciling`; the `Accept` header does not change that. | | MCP | `install_app`, with `name` and `supervisor` both set to the supervisor. Read an app's parameters first with `get_app_params`. It returns once the HelmRelease is written, with status `reconciling`; poll `list_cluster_helm_releases` until the release is `deployed`. | Installing needs `helm-release:Install` on `krn:celum:supervisor::cluster::helm-release:*`. The chart list needs `app:List` on `krn:celum:app:*`, and the namespace list needs `discovery:ListNamespaces` on `krn:celum: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. > [!NOTE] > > 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. | Surface | How | | - | - | | UI | The pencil on a row, then **Save & Upgrade** | | API | Read: `GET /api/clusters//helm-releases//values?supervisor=&releaseNamespace=`. Change: `PUT /api/clusters//helm-releases/?supervisor=` with `values`, `releaseNamespace`, `chartName` and `chartVersion`, plus `repoUrl` only for a version change. It answers `202` with a job `id`; poll `GET /api/clusters//helm-releases//upgrade-status/?supervisor=`. For a Flux release the job ends with `result.status` `deployed`; or `failed` with helm-controller's reason; or `succeeded` with `result.status` `reconciling` and a `message` saying where it stood, which is not done. | | MCP | No MCP tool changes a release's values or version. `get_helm_release_values` and `get_helm_upgrade_status` call the read routes above. `get_helm_release_values` describes itself as a tool for tenant clusters. | Reading values needs `helm-release:GetValues`, and saving needs `helm-release:Upgrade`, both on `krn:celum:supervisor::cluster::helm-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. > [!WARNING] > > 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 nuvira.dev/source=app-install`. | Surface | How | | - | - | | UI | The bin on a row, then **Uninstall** | | API | `DELETE /api/clusters//helm-releases/?supervisor=&releaseNamespace=`. A platform release answers `409`. | | MCP | None: no tool in the assistant's catalog destroys data. See [Celum AI and MCP](https://docs.celum.io/concepts/celum-ai.md#what-it-will-not-do). | Uninstalling needs `helm-release:Uninstall` on `krn:celum:supervisor::cluster::helm-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](https://docs.celum.io/platform-health/infrastructure.md). **Storage** shows whatever provides storage on the supervisor, one panel per backend. See [The Storage tab](https://docs.celum.io/storage/storage-tab.md). **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](https://docs.celum.io/platform-health/monitoring.md) and [ClickHouse instances](https://docs.celum.io/security/pipeline-and-runtime.md#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](https://docs.celum.io/clusters/overview.md#the-capi-engine). ## Permissions | Task | Action | KRN | | - | - | - | | Open the Overview | `supervisor:GetSummary` | `krn:celum:supervisor:` | | Refresh the cache | `supervisor:Refresh` | `krn:celum:supervisor:` | | See the Storage tab | `ceph:GetStatus` | `krn:celum:supervisor::ceph:*` | | See the Monitoring tab | `monitoring:GetStatus` | `krn:celum:supervisor::monitoring:*` | | See the Cluster API tab | `capi:GetStatus` | `krn:celum:supervisor::capi:*` | | Move the cluster agent | `supervisor:Bootstrap` | `krn:celum:supervisor:` | | List Helm releases | `helm-release:List` | `krn:celum:supervisor::cluster::helm-release:*` | | Install an app | `helm-release:Install` | `krn:celum:supervisor::cluster::helm-release:*` | | Read or edit a release's values | `helm-release:GetValues` / `helm-release:Upgrade` | `krn:celum:supervisor::cluster::helm-release:` | | Uninstall a release | `helm-release:Uninstall` | `krn:celum:supervisor::cluster::helm-release:` | ## Related * [Platform health overview](https://docs.celum.io/platform-health/overview.md): the status model every panel shares. * [Register a supervisor](https://docs.celum.io/get-started/register-a-supervisor.md): where the label is set. * [Platform onboarding](https://docs.celum.io/get-started/platform-onboarding.md): what fills these tabs. * [App catalog](https://docs.celum.io/gitops/app-catalog.md): the charts **Install App** offers. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.