Applications¶
The dashboard lists the applications in the current namespace, one card per application.
The catalog¶
The New app button opens the catalog of available templates, by category:
| Category | Templates |
|---|---|
| Processing | Apache Hop (GUI), Apache Hop Server, Trino, Spark Connect, Apache NiFi |
| Storage | PostgreSQL, SFTP server |
| Visualization | Digdash BI |
| Governance | Apache Iceberg (Polaris catalog), OpenMetadata |
| Data science | JupyterHub, MLflow |
| DevOps | Nginx (static site) |
The Apache Iceberg, Trino and JupyterHub templates combine into a lakehouse on the platform's S3 buckets — see Lakehouse.
Forgejo, a special case
The Forgejo Git server doesn't appear in this catalog: it's a platform-wide application (a single instance for the whole cluster), managed from Settings → Git — see Git.
Anatomy of a card¶
Each card shows:
- the name (or the display name if it has been customized), the template and the deployed image;
- the status:
Running,Pending(starting up),Stopped,Error; - the CPU and RAM gauges: actual consumption against the requested resources;
- the version of the application and that of its chart (
2026R1 · chart 1.8.1), and the Upgrade available badge when a newer chart version is published; - the creation date and the author of the deployment.
Understanding the CPU and RAM gauges¶
Each gauge shows the pod's actual consumption (reported by the cluster's metrics server) measured against its limit if the application has one, otherwise against its requested quantity — see Configuring an application for the difference between the two.
0.85 / 2.00 cores: 0.85 core consumed out of a 2-core limit.3.2 Gi / 4.0 Gi: 3.2 GiB of RAM consumed out of a 4 GiB limit.n/a: the cluster's metrics server doesn't have a measurement for this pod yet (a recent restart, for example) — the gauge stays greyed out.
The bar's color indicates the consumption level against that ceiling:
| Color | Threshold | Meaning |
|---|---|---|
| 🟢 Teal | < 60% | Normal consumption |
| 🟠 Amber | 60% – 79% | Approaching the ceiling — worth watching |
| 🔴 Red | ≥ 80% | Near or at the ceiling — the application risks being throttled (CPU) or killed by the kernel (memory, OOMKill) |
In the screenshot above, CPU (42.5% of the limit) stays teal while RAM (80% of the limit) turns red — the signal to raise the application's memory limit from Configure.
Upgrading an application¶
When a newer version of the application's chart is published, its card shows the Upgrade available: 2026R2 badge (the target version of the application); if only the chart changes, the badge reads Upgrade available: chart 1.10.0. The card's Version line gives the current version.
The badge is itself the upgrade button: clicking it opens a confirmation window. It is restricted to the operator role or higher (otherwise the badge stays readable but greyed out, with the "Insufficient rights" tooltip). The card's action bar has no upgrade icon.
- the starting and target versions of the application and of the chart (
1.8.1 → 1.10.0); - a warning when the chart has a major change: read its release notes before continuing;
- the fixed vulnerabilities (CVEs), in a green box: "This upgrade fixes 3 critical CVEs:", with the identifier and title of each, then "Plus 5 high-severity CVEs." when there are any. If the target version itself has critical CVEs that the current version does not, an orange box points it out: "The new version has 1 critical CVE not present in the current one.";
- a reminder that the application restarts during the upgrade; it can take several minutes to come back.
The CVEs are read from the scan of the platform's image registry when the window opens ("Looking for fixed vulnerabilities…"). They are information only: if the scan is not available, or has nothing to report, no box appears and the upgrade remains possible.
If another upgrade of this application is already running (started by another user or in another tab), the window shows the server's message and nothing is started.
Upgrade closes the window and starts the upgrade, then restarts the application, like Restart. While it runs, the card's badge becomes Upgrade in progress… and is greyed out. A banner at the top of the dashboard follows the task, then gives the result:
- success: "tableau-de-bord upgraded: chart 1.8.1 → 1.10.0.";
- success without the restart, in orange: "tableau-de-bord upgraded: chart 1.8.1 → 1.10.0, but the restart failed: click Restart." The new version is deployed; click Restart on the card to relaunch the pods;
- failure: "Upgrade of tableau-de-bord failed: …", followed by the reason.
The banner's cross closes it at any time; closing a banner that is still running only stops its tracking. The upgrade itself keeps running on the server: the card then goes back to Upgrade available and the badge is enabled again while the upgrade runs; clicking it and then Upgrade again returns the server's message described above (upgrade already in progress).
An image pinned to a different version than the chart's (for example a tag chosen in Configure) is kept by the upgrade, and the banner says so: "Image kept at 2025R3."
Upgrade restarts, Restart does not change the version
Restart relaunches the pods with the version already deployed: only Upgrade moves the application, and its chart, to the published version. The upgrade restarts the application itself: there is no need to restart afterwards, unless the orange banner asks for it.
Available actions¶
Depending on the template and the application's state:
| Action | Effect |
|---|---|
| Open (external link) | Access the deployed application in a new tab |
| Metrics (external link) | Open the application's Grafana dashboard (pod or namespace) — shown when the platform monitoring is installed, see Cluster |
| Stop / Start | Stop or restart the application without deleting it |
| Restart | Restart the pods (rollout), without changing version |
| Configure | Change the display name, resources, environment variables… — see Configure |
| View details | Pods, services, routes, internal connection information |
| Manage access | Authorize other users — see Access and permissions |
| Delete | Uninstall the release (confirmed by retyping the name, irreversible) |
Actions specific to certain templates¶
- API compatibility test (Digdash BI, Apache Hop Server, Forgejo): checks end-to-end that the application's API responds, with a detailed result per checkpoint (Healthy or Degraded badge).
- Resync Hop connections (Apache Hop GUI): immediately regenerates the Hop project's metadata files (connections to PostgreSQL databases, to Hop servers and to the namespace's buckets), without waiting for the periodic sync.
- Resync DigDash connections (Digdash BI): reprovisions the internal Audit / Comments / Form connections to the embedded PostgreSQL.
- Hop Jobs (Apache Hop Server): monitoring and launching of scheduled pipelines and workflows — see Apache Hop Server: jobs and scheduling for details.