Native Helm Components and `atmos helmfile template`

Atmos now treats Helm as a first-class component type. Define a Helm release — local chart, remote repository chart, or OCI chart — in your stack configuration, then template, diff, apply, and delete it through the Helm Go SDK. No helm or helmfile binary required. And because Atmos owns rendering, values, lifecycle events, and credentials, an apply can publish the rendered manifests to a Git deployment repository instead of a cluster — the producer side of a GitOps workflow.

For existing Helmfile users, we also added atmos helmfile template, which renders a Helmfile component to manifests and can deliver them to the same provision targets — closing the long-standing request in #2069.

What Changed

components.helm.<name> is a native component type with the same stack semantics as Terraform and Kubernetes — vars, env, auth, metadata, settings, dependencies, hooks, inheritance, and overrides — plus Helm-specific chart, version, repositories, values, values_files, and namespace:

components:
  helm:
    monitoring:
      chart: prometheus-community/kube-prometheus-stack
      version: "65.1.1"
      repositories:
        - name: prometheus-community
          url: https://prometheus-community.github.io/helm-charts
      namespace: monitoring
      values:
        grafana:
          adminPassword: !secret grafana_admin_password
      dependencies:
        components:
          - cert-manager

The component values: map is the chart's values, merged through Atmos inheritance. Charts can be local (chart: .), from a repository, or OCI (chart: oci://...). The Helm Go SDK renders everything in-process, so atmos helm template works with no cluster and no credentials.

Why This Matters

Helm has no native secrets concept — the ecosystem reaches for the helm-secrets plugin and SOPS. Atmos provides it directly: secret values flow in through the !secret YAML function and are masked automatically. Helm has no native dependency ordering across releases — Atmos provides it through the component DAG (dependencies.components), so atmos helm apply --all and --affected deploy in the right order.

How to Use It

Render, preview, and deploy:

atmos helm template monitoring -s plat-ue2-dev
atmos helm diff monitoring -s plat-ue2-dev
atmos helm apply monitoring -s plat-ue2-dev

Publish to a GitOps repo instead of a cluster:

components:
  helm:
    monitoring:
      provision:
        default: cluster
        targets:
          cluster:
            kind: kubernetes
          deployment-repo:
            kind: git
            repository: deployments
            path: "clusters/{{ .vars.stage }}/monitoring"

atmos helm deploy monitoring -s plat-ue2-dev --target deployment-repo

Real diffs — no plugin required

atmos helm diff (alias plan) shows a true unified diff, not just a dry-run dump. Atmos renders the chart client-side and compares it with the helm-diff engine embedded directly in the binary — so you get the familiar +/- output without installing the helm-diff CLI plugin. Secret values are redacted automatically.

It diffs against whichever baseline fits your workflow:

# Against the deployed release (requires cluster access).
atmos helm diff monitoring -s plat-ue2-dev

# Against a local baseline manifest — fully offline.
atmos helm diff monitoring -s plat-ue2-dev --from-manifest=current.yaml

# Against the GitOps deployment repository — the producer-side
# "what will this change in the repo?" diff, offline (git access only).
atmos helm diff monitoring -s plat-ue2-dev --against=target

In CI, the diff is published to the job summary as a collapsible block (Secrets omitted), matching the native Kubernetes component.

Already on Helmfile? Render and publish without migrating:

atmos helmfile template echo-server -s tenant1-ue2-dev --target deployment-repo

Get Involved

See the atmos helm and atmos helmfile template docs to get started, and the examples/helm example for a runnable local-chart project.