Deploy an application with Helm in ClusterPilot

Before you start

You need a ready cluster, permission for Helm operations, an application packaged as a reachable, approved Helm chart, its exact chart version and reference, an application image accessible to the cluster, and an agreed namespace. Ask the chart owner for its values schema. If you only have source code or an OCI image without a chart, prepare a chart first or agree a separate delivery path; the current UI has no general upload-from-GitHub or create-app-from-image form.

What ClusterPilot deploys

A Helm chart is a versioned package of Kubernetes objects; an installation creates a named release. Its templates may create a Deployment, Service, Ingress and more. A Deployment maintains the desired replica count, while a Service gives Pods a stable network target. ClusterPilot sends the release action through its permission-gated Helm surface and records redacted values and evidence references.

1. Install the release in the browser

1. 01

   Open the Helm surface

   Open Clusters → your cluster → Helm Releases (/clusters/{id}/helm). Use Install Helm release; this action is separate from the Add-on Catalog.

2. 02

   Enter the release identity

   Enter Namespace and Release name, then the approved Chart reference and exact Chart version. Use the chart reference format accepted by your configured repository. Confirm that the namespace exists or that your operator has provided the required setup; do not assume the form creates one.

3. 03

   Configure the chart

   Set Values profile reference if your team uses one. Enter only chart-supported settings in Values YAML, for example its documented image tag, replica count, resource requests and service port. Compare the values against the chart's schema. Do not paste long-lived credentials into a release value; use the approved secret reference mechanism.

4. 04

   Install and inspect

   Choose Install release. Open the new release detail and note its namespace, chart version, revision, result and evidence. If permission or validation fails, use the displayed reason; do not repeat an uncertain operation without checking release inventory.

2. Verify the application, not just Helm

• ✓
  Open Workloads for the same cluster and namespace. Find the Deployment, its Pods and Services; compare desired and available replicas.
• ✓
  Inspect a Pod's events and logs when it is Pending, restarting or cannot pull the image. Check registry reachability, chart values and resource requests.
• ✓
  Check the chart's readiness probe and a real application request. Readiness determines whether a Pod should receive Service traffic; a successful Helm response alone does not prove the application serves users.
• ✓
  Expose traffic only through an agreed Ingress/Service and DNS/TLS path. A release may intentionally remain internal.

3. Update or recover a release

The Helm release detail provides permission-gated update, rollback and uninstall actions. Review the current revision and target chart/values before an update. Rollback targets a recorded previous Helm revision; it does not restore database contents or persistent volumes. Confirm data protection and application compatibility separately before either action.

Monitor and troubleshoot in the browser → · Domains, ingress & TLS →