Deploy Helm Charts

To deploy Helm charts, you need to configure them within the deployments section of the devspace.yaml.

Examples

Component Chart

deployments:
- name: backend
  helm:
    componentChart: true
    values:
      containers:
      - image: reg.tld/username/devspace
      service:
        ports:
        - port: 3000

Component Chart Docs

The component chart is a flexible Helm chart for deploying custom applications in a standardized manner. Learn more in the Component Chart Documentation.

Custom Chart

deployments:
- name: backend
  helm:
    chart:
      name: chart-name
      repo: https://my-charts.company.tld/
    values:
      # If registry.url/repo/image was found under images as well, will be 
      # rewritten to registry.url/repo/image:generated_tag
      imageWithTag: registry.url/repo/image
      # If registry.url/repo/image was found under images.app as well, will be
      # rewritten to registry.url/repo/image
      imageWithoutTag: ${runtime.images.app.image}
      # If registry.url/repo/image was found under images.app as well, will be
      # rewritten to generated_tag
      onlyTag: ${runtime.images.app.tag}

Local Chart

deployments:
- name: backend
  helm:
    chart:
      name: ./path/to/chart
    values:
      # If registry.url/repo/image was found under images as well, will be
      # rewritten to registry.url/repo/image:generated_tag
      imageWithTag: registry.url/repo/image
      # If registry.url/repo/image was found under images.app as well, will be
      # rewritten to registry.url/repo/image
      imageWithoutTag: ${runtime.images.app.image}
      # If registry.url/repo/image was found under images.app as well, will be
      # rewritten to generated_tag
      onlyTag: ${runtime.images.app.tag}

Git Chart Repo

deployments:
- name: backend
  helm:
    chart:
      git:
        url: https://github.com/<username>/<chartrepo>.git
        # optional git configs
        branch: branchName
        tag: tag
        revision: revision
        subPath: subpath/chartdir

Chart

componentChart

The componentChart option expects a boolean which states if the Component Helm Chart should be used for deployment.

Component Chart Docs

The component chart is a flexible Helm chart for deploying custom applications in a standardized manner. Learn more in the Component Chart Documentation.

danger

If componentChart: true is configured, all options under chart will be ignored.

Default Value for componentChart

componentChart: false

Example: Component Chart Deployment

deployments:
- name: backend
  helm:
    componentChart: true
    values:
      containers:
      - image: reg.tld/username/devspace
      service:
        ports:
        - port: 3000

chart.name

The name option is mandatory and expects a string stating either:

• a path to a local chart that is stored on the filesystem
• or the name of a remote chart that is stored in a repository (one specified via repo option) or in the form of repo/name, where repo was added via helm repo add repo https://repo.url beforehand

DevSpace follows the same behavior as helm install and first checks if the path specified in name exists on the file system and is a valid chart. If not, DevSpace will assume that the name is not a path but the name of a remote chart located in a chart repository.

Example: Simple Helm Deployment

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql

Explanation:
Deploying the above example would roughly be equivalent to this command:

helm install database bitnami/mysql

chart.version

The version option expects a string stating the version of the chart that should be used.

Default Value for version

version: ""

Latest Version

If no version is specified, Helm will by default use the latest version of the chart.

Example: Custom Chart Version

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql
      version: "1.3.1"

Explanation:
Deploying the above example would roughly be equivalent to this command:

helm install database bitnami/mysql --version="1.3.1"

chart.repo

The repo option expects a string with a URL to a Helm Chart Repository. This is equivalent of using the --repo flag in helm install

Example: Custom Chart Repository

deployments:
- name: database
  helm:
    chart:
      name: custom-chart
      repo: https://my-repo.tld/

Explanation:
Deploying the above example would roughly be equivalent to this command:

helm install database custom-chart --repo "https://my-repo.tld/"

chart.username

The username option expects a string that specifies the user that should be used to access chart.repo. Will be used as value for the helm flag --username

chart.password

The password option expects a string that specifies the password that should be used to access chart.repo. Will be used as value for the helm flag --password

Values

Helm charts can be configured by overriding the default values of the chart.

values

The values option expects an object with values that should be overriding the default values of this Helm chart.

Compared to the valuesFiles option, using values has the following advantages:

• It is easier to comprehend and faster to find (no references)
• It allows you to use dynamic config variables

info

Because both, values and valuesFiles, have advantages and disadvantages, it is often useful to combine them. When setting both, values defined in values have precedence over values defined in valuesFiles.

Default Value for values

values: {}

Example: Using Values in devspace.yaml

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql
    values:
      mysqlRootPassword: ${MYSQL_ROOT_PASSWORD}
      mysqlUser: db_user
      mysqlDatabase: app_database

Explanation:
Deploying the above example would roughly be equivalent to this command:

helm install database bitnami/mysql --set mysqlRootPassword="$MYSQL_ROOT_PASSWORD" --set mysqlUser="db_user" --set mysqlDatabase="app_database"

valuesFiles

The valuesFiles option expects an array of paths to yaml files which specify values for overriding the values.yaml of the Helm chart.

Compared to the values option, using valuesFiles has the following advantages:

• It reduces the size of your devspace.yaml especially when setting many values for a chart
• It allows you to run Helm commands directly without DevSpace, e.g. helm upgrade [NAME] -f mysql/values.yaml

info

Because both, values and valuesFiles, have advantages and disadvantages, it is often useful to combine them. When setting both, values defined in values have precedence over values defined in valuesFiles.

Default Value for valuesFiles

valuesFiles: []

Example: Using Values Files

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql
    valuesFiles:
    - mysql/values.yaml
    - mysql/values.production.yaml

Explanation:
Deploying the above example would roughly be equivalent to this command:

helm install database bitnami/mysql -f mysql/values.yaml -f mysql/values.production.yaml

replaceImageTags

The replaceImageTags option expects a boolean stating if DevSpace should do Image Tag Replacement.

By default, DevSpace searches all your values (specified via values or valuesFiles) for images that are defined in the images section of the devspace.yaml. If DevSpace finds an image, it replaces or appends the image tag with the tag it created during the image building process. Image tag replacement makes sure that your application will always be started with the most up-to-date image that DevSpace has built for you.

DevSpace will replace the following things:

• registry.url/repo/name that corresponds to a images.*.image, will be rewritten to registry.url/repo/name:generated_tag

In-Memory Tag Replacement

Tag replacement takes place in-memory and is not writing anything to the filesystem, i.e. it will never change any of your configuration files.

Default Value for replaceImageTags

replaceImageTags: true

Example: Disable Tag Replacement

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql
    replaceImageTags: false

Helm Options

upgradeArgs

The upgradeArgs specifies an array of arguments that will be passed by devspace additionally to the standard arguments to helm upgrade during deployment.

templateArgs

The templateArgs specifies an array of arguments that will be passed by devspace additionally to the standard arguments to helm template during devspace render.

deleteArgs

The deleteArgs specifies an array of arguments that will be passed by devspace additionally to the standard arguments to helm delete during devspace purge.

wait

The wait option expects a boolean that will be used for the helm flag --wait.

Default Value for wait

wait: false

Example: Helm Flag Wait

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql
    wait: true

Explanation:
Deploying the above example would roughly be equivalent to this command:

helm install database bitnami/mysql --wait

displayOutput

The displayOutput option expects a boolean and allows helm output to be printed to the console after helm install and helm upgrade. This can be used to display notes.txt from your helm charts.

Default Value for displayOutput

displayOutput: false

Example: displayOutput

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql
    displayOutput: true

Explanation:
Deploying the above example would print the helm output and the notes.txt from the bitnami/mysql chart.

timeout

The timeout option expects an integer representing a number of seconds that will be used for the helm flag --timeout.

Default Value for timeout

timeout: 5m0s # defined by helm

Example: Helm Flag Timeout

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql
    timeout: 300s

Explanation:
Deploying the above example would roughly be equivalent to this command:

helm install database bitnami/mysql --timeout=300s

force

The force option expects a boolean that will be used for the helm flag --force.

Default Value for force

force: false

Example: Helm Flag Force

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql
    force: true

Explanation:
Deploying the above example would roughly be equivalent to this command:

helm install database bitnami/mysql --force

recreate

The recreate option expects a boolean that states if DevSpace should set the Helm flag --recreate-pods. It tells Helm to restart all pods for applicable resources (e.g. Deployments).

Default Value for recreate

recreate: false

Example: Enable Recreate Pods

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql
    recreate: true

atomic

The atomic option expects a boolean that states if DevSpace should pass the --atomic flag to Helm. If set, the upgrade process rolls back all changes in case the upgrade fails. This flag also sets the --wait option.

Default Value for atomic

atomic: false

Example: Enable Atomic Deployment

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql
    atomic: true

cleanupOnFail

The cleanupOnFail option expects a boolean that states if DevSpace should set the Helm flag --cleanup-on-fail. It allows that Helm deletes newly created resources during a rollback in case the rollback fails.

Default Value for cleanupOnFail

cleanupOnFail: false

Example: Enable Cleanup On Fail

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql
    cleanupOnFail: true

disableHooks

The disableHooks option expects a boolean that tells DevSpace to disable hooks when executing Helm commands.

Default Value for disableHooks

disableHooks: false

Example: Disable Hooks

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql
    disableHooks: true

v2

The v2 option expects a boolean that tells DevSpace to use the legacy version 2 of Helm instead of Helm v3.

Default Value for v2

v2: false

tillerNamespace

The tillerNamespace option expects a string that will be used for the helm flag --tiller-namespace.

Helm 2 Only

This config option is only used when v2: true is configured as well.

Deprecated

This config option is deprecated because Tiller is not necessary anymore since DevSpace supports Helm v3.

Default Value for tillerNamespace

tillerNamespace: "" # defaults to default namespace of current context

Example: Change Tiller Namespace

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql
    tillerNamespace: my-tiller-ns
    v2: true

Explanation:
Deploying the above example would roughly be equivalent to this command:

# Helm v2 CLI
helm install --name database bitnami/mysql --tiller-namespace=my-tiller-ns

path

The path option is optional and expects a string with the path of an Helm v2 binary / executable file which should be used for Helm v2 deployments.

Helm 2 Only

This config option is only used when v2: true is configured as well.

danger

Setting path makes it much harder to share your devspace.yaml with other team mates. It is recommended to add helm to your $PATH environment variable instead.

General Options

name

The name option is required and expects a string with the name of the release used to deploy this Helm chart.

Example: Deployment Name

deployments:
- name: database
  helm:
    chart:
      name: bitnami/mysql

namespace

The namespace option is required and expects a string with the namespace used to deploy the Helm chart to.

danger

Only use this option if you really need to. Hard-coding the namespace in devspace.yaml makes it harder to share the configuration with your colleagues. It is recommended to set the default namespace of the current context instead using:

devspace use namespace [some-namespace]

Example: Deployment Namespace

deployments:
- name: database
  namespace: some-namespace
  helm:
    chart:
      name: bitnami/mysql

disabled

If true, the deployment will not be deployed, rendered or purged. Can be useful in combination with config expressions or command variables.