Helm

Infrastructure integration · 12 node(s).

00Overview

Install, upgrade, roll back and uninstall Helm releases on your cluster from a flow, and inspect what is already deployed — list releases, read their status and history, and render or lint a chart before it goes anywhere near the cluster. Pair it with the Kubernetes nodes to build a full release pipeline.

Every field below is exactly what you see in the Flomation editor. Fields marked ● live picker let you choose from a list pulled live from your account — no IDs to look up.

01Connecting Helm

1. Helm talks to the same cluster as the Kubernetes nodes and takes the same credentials — set up the API Server URL and Authentication exactly as described on the Kubernetes page. The service account will need permission to manage the resources the chart creates, and to read and write secrets in the release's namespace (that is where Helm records its release history).
2. The nodes that change or render a release — Install, Upgrade, Rollback, Uninstall, Test, Template, Lint and Show — run the helm command, so it has to be available to the Flomation runner. The runner takes it from Helm Binary Path if you set one, otherwise from the helm on its PATH; failing both it downloads a pinned release and verifies its checksum before running it (set Helm Version to pin a different one). On a locked-down or air-gapped runner your administrator can pre-install helm on the host instead — see the installation guide. The read-only nodes — List Releases, Get Release, Release Status and Release History — talk to the cluster directly and need no helm command at all.
3. For a chart from a public repository, put the repository in Repository URL (e.g. https://charts.bitnami.com/bitnami) and the chart's name in Chart. You can also give Chart an OCI reference (oci://ghcr.io/org/chart) or a direct .tgz URL and leave the repository blank.
4. For a private chart repository, fill in Repository Username and Repository Password, storing the password as an environment secret. If the repository sits behind an internal certificate authority, paste that CA into Repository CA Certificate (PEM).
5. Pin Chart Version on anything you care about — left blank, an install picks up whatever the repository currently calls latest, which is rarely what you want in a repeatable flow.

02Chart

Helm Lint Chart

infrastructure/helm/chart_lint · Action

Check a chart for errors and best-practice violations with helm lint, without touching the cluster.

Returns: output, passed, tool_result, success, error

Helm Show Chart

infrastructure/helm/chart_show · Action

Read a chart's metadata, default values, README, or all of them, without installing it.

Returns: output, tool_result, success, error

Helm Template Chart

infrastructure/helm/chart_template · Action

Render a chart to Kubernetes YAML locally, without touching the cluster — preview exactly what an install would apply.

Returns: manifest, tool_result, success, error

03Release

Helm Get Release

infrastructure/helm/release_get · Action

Read a Helm release revision — the whole release, or just its values, rendered manifest, notes or hooks.

Returns: id, result, text, revision, tool_result, success, error

Helm Release History

infrastructure/helm/release_history · Action

List every revision of a Helm release, oldest first — revision, status, chart, app version and when each was deployed.

Returns: results, count, tool_result, success, error

Helm Install Release

infrastructure/helm/release_install · Action

Install a Helm chart as a new release on a Kubernetes cluster, optionally waiting for it to become ready.

Returns: id, result, revision, status, tool_result, success, error

Helm List Releases

infrastructure/helm/release_list · Action

List the Helm releases in a namespace, or across every namespace — name, revision, status, chart and app version.

Returns: results, count, tool_result, success, error

Helm Rollback Release

infrastructure/helm/release_rollback · Action

Roll a Helm release back to a previous revision. Requires explicit confirmation.

Returns: id, tool_result, success, error

Helm Release Status

infrastructure/helm/release_status · Action

Report a Helm release's status — its lifecycle state, chart, app version and when it was last deployed.

Returns: id, status, revision, description, last_deployed, chart, app_version, result, tool_result, success, error

Helm Test Release

infrastructure/helm/release_test · Action

Run a Helm release's chart tests and report whether they passed, optionally dumping the test pod logs.

Returns: id, output, passed, tool_result, success, error

Helm Uninstall Release

infrastructure/helm/release_uninstall · Action

Permanently remove a Helm release and every resource it created. Requires explicit confirmation.

Returns: id, tool_result, success, error

Helm Upgrade Release

infrastructure/helm/release_upgrade · Action

Upgrade an existing Helm release to a new chart version or new values, optionally creating it if missing.

Returns: id, result, revision, status, tool_result, success, error

04Notes & Limitations

Behaviours and constraints worth knowing before you build with these nodes.

• The install, upgrade, rollback, uninstall, test, template, lint and show actions run the helm executable on the Flomation runner — taken from Helm Binary Path, then the runner's PATH, and otherwise downloaded and checksum-verified on first use — so on an air-gapped runner an administrator should pre-install it or point the runner at an internal mirror; the read-only actions (List, Get, Status, History) read the release straight from the cluster and need no binary at all.
• Upgrade, Rollback and Uninstall refuse to run unless Confirm Destructive Action is set, and because that field accepts a variable you can bind it to an upstream approval or check (for example ${var.approved}) so the change is authorised at run time rather than at design time.
• Upgrade applies only the values you supply and resets anything set on the previous revision, so enable Reuse Values when you intend to change one setting and leave the rest of the release's existing configuration intact.
• Uninstall with Keep History switched off removes the release's revision history along with its resources, which means the release cannot be rolled back afterwards.
• Without Wait for Ready, Install and Upgrade return as soon as the cluster accepts the manifests and before the workload is actually running, so enable it (and size the Timeout, which defaults to 300 seconds) whenever a downstream step depends on the release being live.
• The Namespace and Release Name dropdowns only populate when Authentication is set to Service Account Token; with client-certificate or pasted-kubeconfig authentication the pickers fall back to manual entry, though the flow itself still runs normally.