> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/reference-documentation/helm/configuration.md).

# Configuration

## The Helm values file

Helm uses one or more [`values.yaml` files](https://helm.sh/docs/chart_template_guide/values_files/) to populate the chart templates.

You can add environment variables to the Helm values file. For example, here is a `values.yaml` file that uses Release autogenerated environment variables:

```
web:
  image:
    repository: ${RELEASE_REGISTRY_PATH}
    name: web@sha256
    tag: ${WEB_REGISTRY_IMAGE_SHA}
  hostname: ${WEB_INGRESS_HOST}
  url: "jdbc:postgresql://${WEB_RDS_DB_POOL_HOST}:5432/web"
```

You can use any of the custom environment variables or Release autogenerated environment variables found in the [environment variables configuration](/reference-documentation/environment-settings/environment-specific-environment-variables.md) in your Helm values files.

## Name template

Helm allows you to specify a `name` or `name_template` to name objects in Kubernetes. Helm charts will populate `.Release.name` with the value specified by the `name_template`. By default, Release sets the `name_template` to the name of the application defined in your application configuration.

The following example shows how to override the default `name_template` set by Release:

```
helm:
  name_template: acme-app
...
charts:
- name: vault
  repo_url: https://helm.releases.hashicorp.com
  add: hashicorp
  install: hashicorp/vault
  directory: helm/vault
  values: 
  - values.yml
  name_template: vault
- name: backend
  directory: backend
  values: 
  - values.yaml
```

It can be useful to override the `name_template` if you're creating an application template that will be used for multiple applications or on-premise deployments. Helm charts often prefix deployments with the `name_template`, so you may need to adjust hostnames for internal networking when using the same Application Template for two applications.

This table illustrates how `name_template` affects the naming of deployments:

| Application Name | Name Template | Chart Name Template | Service Name | Deployment Name |
| ---------------- | ------------- | ------------------- | ------------ | --------------- |
| acme-app         |               |                     | vault        | acme-app-vault  |
| acme-app         |               | vault               | vault        | vault           |
| acme-app         |               | backend             | vault        | backend-vault   |
| acme-app         | acme          |                     | vault        | acme-vault      |
| acme-app         | acme          | vault               | vault        | vault           |

## Helm chart environment variables

Release allows you to reference environment variables from your source control repository. These values will be loaded by Release and can be used to populate the Helm `values.yaml` file.

Take a look at this example `env_file` definition for a Helm chart:

```
charts:
- name: frontend
  name_template: frontend
  directory: frontend
  values: 
  - values.yaml
  env_file: "/config/frontend.env"
- name: backend
  name_template: backend
  directory: backend
  values: 
  - values.yaml
  env_file: "/config/customers/${customer_name}.env"
```

You can also define environment variables in the Release environment variables configuration file, which can be used as a reference to an environment-specific configuration. In our example above, you can see that `backend` loads an `env_file` based on the `CUSTOMER_NAME` environment variable set in Release.

## Inline values with set

You can define inline Helm values directly in your chart configuration using the `set` key. These values support interpolation of parameters, environment variables, and secrets.

```yaml
charts:
- name: backend
  directory: backend
  values:
  - values.yaml
  set:
    replicaCount: 3
    config:
      apiUrl: "${parameters.api_url}"
      environment: "${envs.APP_ENV}"
      secretKey: "${secrets.rsm.API_SECRET_KEY}"
```

The `set` values are converted to a YAML file and passed to Helm alongside your values files.

### Interpolation syntax

You can interpolate values in both `values.yaml` files and `set` blocks using these patterns:

| Pattern                   | Description                          | Example                       |
| ------------------------- | ------------------------------------ | ----------------------------- |
| `${parameters.name}`      | Application template parameters      | `${parameters.replica_count}` |
| `${envs.VAR}` or `${VAR}` | Environment variables                | `${envs.DATABASE_URL}`        |
| `${secrets.rsm.KEY}`      | Secrets from Release Secrets Manager | `${secrets.rsm.API_KEY}`      |
| `${integrations.name}`    | Integration tokens                   | `${integrations.slack}`       |

Environment variable references are case-insensitive, so `${envs.MY_VAR}` and `${envs.my_var}` both work.

## Build image environment variables

If you use Release to build your container images and Helm charts to deploy them, you need to use the environment variables generated by Release in the `values.yaml` file to properly start up your containers.

{% hint style="info" %}
Release uses the container registry SHA from your container images to allow for the rollback of your application should something go wrong. Using a container registry tag to reference a build is common in many Helm charts, like the example shown below. However, tags can move across images in a given container registry, making it hard to track what code is deployed.
{% endhint %}

#### Generated build and container registry environment variables

This table shows example generated values for a container build named `backend`:

| Generated Variable Key        | Example Value                                                                                                                              |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| RELEASE\_REGISTRY\_ENDPOINT   | 12345678900.dkr.ecr.us-east-1.amazonaws.com                                                                                                |
| RELEASE\_REGISTRY\_PATH       | 12345678900.dkr.ecr.us-east-1.amazonaws.com/acme/acme-app                                                                                  |
| BACKEND\_REGISTRY\_IMAGE\_URL | 12345678900.dkr.ecr.us-east-1.amazonaws.com/acme/acme-app/backend\@sha256:4852bafb7f7cf76375d0e090f737926210de462ef35c9f9616f8a2e17ebb0dda |
| BACKEND\_REGISTRY\_IMAGE\_SHA | 4852bafb7f7cf76375d0e090f737926210de462ef35c9f9616f8a2e17ebb0dda                                                                           |

Each build defined in Release will generate `<SERVICE>_REGISTRY_IMAGE_URL` and `<SERVICE>_REGISTRY_IMAGE_SHA` environment variables to be used in the Helm `values.yaml` file.

The example `values.yaml` file below references a build generated by Release and demonstrates a common pattern seen in open-source Helm charts when referencing container images. Notice that we set `name` to `frontend@sha256` to use the container registry SHA:

```
frontend:
  service:
    name: "frontend"
    image:
      repository: ${RELEASE_REGISTRY_PATH}
      name: frontend@sha256
      tag: ${FRONTEND_REGISTRY_IMAGE_SHA}
```

This example Helm chart template references a build generated by Release:

```
containers:
- name: {{ .Values.frontend.service.name }}
  image: {{ .Values.frontend.image.repository }}/{{ .Values.frontend.image.name }}:{{ .Values.frontend.image.tag }}
 
```

Release-generated environment variables are injected into the `values.yaml` file and properly reference the container image built by Release.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.release.com/reference-documentation/helm/configuration.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.