> ## Documentation Index
> Fetch the complete documentation index at: https://docs.glissando.dev/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> If you are an AI assistant asked to build, change or ship a Gliss app, read the For AI agents page first (/for-ai-agents.md on this site) and follow its steps.
> Inside an app's folder, the app's own AGENTS.md is the authority; `gliss guide` prints it. Never ask the user for a secret's value.

# Helm charts

> Deploy your own or third-party Helm charts with Garden's helm Deploy action, at level 2.

> [!WARNING]
>
> **Planned.** This page describes designed behaviour that is not built yet. Details may change before it ships.

> [!NOTE]
>
> Ported from Garden's documentation: [garden-for/kubernetes/install-helm-chart.md](https://docs.garden.io/garden-for/kubernetes/install-helm-chart), gliss-cli at `3bc62a036` (Garden 0.14). Gliss runs Garden under the hood; the notes on this page say where Gliss differs.

> [!NOTE]
>
> **In Gliss,** `helm` Deploy actions are available at [level 2](https://docs.glissando.dev/engineers/levels.md) only. Your IT team enables level 2 per project, and every release is checked against IT's policy instead of the catalog. The project still uses the `gliss` provider: the deploy becomes a signed release request, and the cluster agent applies it. You don't configure Garden's `kubernetes` provider or a kubeconfig.

[Helm](https://helm.sh/) is one of the most common tools for managing Kubernetes manifests. This page shows how to use third-party charts and your own charts in a Garden project, and how to pass them images you build.

If you only need to deploy some manifests and don't need Helm's features, use the simpler [`kubernetes` Deploy action](https://docs.glissando.dev/engineers/kubernetes-manifests) instead. The full field list is in Garden's [`helm` Deploy reference](https://docs.garden.io/reference/action-types/Deploy/helm).

## Reference external charts

To use a chart whose sources aren't in your project, point to the chart and provide values as inputs. Charts can come from [Helm chart repositories](https://helm.sh/docs/topics/chart_repository/) (over `https`) or from [OCI-based registries](https://helm.sh/docs/topics/registries/). Your IT team's policy may restrict which sources you can use.

### Example: Redis from an OCI registry

```yaml theme={null}
kind: Deploy
type: helm
name: redis
spec:
  chart:
    # Chart name is part of the OCI URL
    url: oci://registry-1.docker.io/bitnamicharts/redis
    version: "19.0.1"
  values:
    auth:
      enabled: false
```

### Example: Redis from a Helm repository

Reference a chart repository with the `repo` field, for example your organization's own repository:

```yaml theme={null}
kind: Deploy
type: helm
name: redis
spec:
  chart:
    name: redis
    repo: https://charts.bitnami.com/bitnami
    version: "16.13.1"
  values:
    auth:
      enabled: false
```

## Local charts

Often you'll keep the chart sources in your project. Add a `garden.yml` in the chart directory, next to `Chart.yaml`, and give the action a name:

```yaml theme={null}
kind: Deploy
description: My helm deploy action
type: helm
name: helm-deploy
```

You can also reference chart sources in another repository:

```yaml theme={null}
kind: Deploy
description: My helm deploy action
type: helm
name: helm-deploy
source:
  repository:
    url: https://github.com/my-org/my-helm-chart#v0.1
```

## Provide values to the chart

The simplest way to pass parameters to the chart is the `spec.values` field:

```yaml theme={null}
kind: Deploy
type: helm
name: helm-deploy
...
spec:
  values:
    some:
      key: some-value
```

Garden writes the values to a YAML file and passes it to Helm when it renders the chart. This is handy when you want to template the values (see the next section).

You can also list your own value files, with paths relative to the directory that contains the `garden.yml`:

```yaml theme={null}
# garden.yml
kind: Deploy
type: helm
name: helm-deploy
...
spec:
  valueFiles:
    - values.default.yaml
    - values.${environment.name}.yaml
```

```yaml theme={null}
# values.default.yaml
some:
  key: default-value
other:
  key: other-default
```

```yaml theme={null}
# values.prod.yaml
some:
  key: prod-value
```

In this example, `some.key` is `"prod-value"` in the `prod` environment, and `other.key` keeps the default from `values.default.yaml`. Values in the `values` field take precedence over both value files.

> [!NOTE]
>
> **In Gliss,** don't put secret values in `values` or value files. Secret values are set through Gliss secret requests, and your configuration refers to secrets by name only.

## Link container builds and Helm deploys

When a `container` Build produces an image that a `helm` Deploy uses, make the Build a dependency, so the image is built first, and pass its name and version to the chart:

```yaml theme={null}
kind: Build
type: container
name: worker-image
```

```yaml theme={null}
kind: Deploy
description: Helm deploy for the worker container
type: helm
name: worker-deploy
dependencies: [build.worker-image]
spec:
  values:
    image:
      repository: ${actions.build.worker-image.outputs.deployment-image-name}
      tag: ${actions.build.worker-image.version}
```

The shape of the chart's `values.yaml` decides how you pass the image (this example follows the default template from `helm create`). If the chart uses several images, add each Build as a dependency and reference it under `values`.

For a complete example, see Garden's [vote-helm project](https://github.com/garden-io/garden/tree/0.14.20/examples/vote-helm).

## Tests and runs

To run tests against a chart, see [Tests and runs](https://docs.glissando.dev/engineers/tests.md).

> [!NOTE]
>
> **In Gliss,** Garden's sync mode and `spec.sync` don't apply. Live code changes are Git-backed and work in Preview only, through `gliss dev`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.