Skip to main content
Version: 4.x

Deploy Helm Charts

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

Examples​

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

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 (either the default (stable) repository or one specified via repo option)

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: stable/mysql

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

helm install database stable/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: stable/mysql
      version: "1.3.1"

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

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

chart.repo​

The repo option expects a string with an URL to a Helm Chart Repository.

Stable Repository

The official Helm Chart Repository stable does not need to be explicitly specified. Using the stable/ prefix for the chart name is sufficient.

Default Value for repo​

repo: stable

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/"

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:

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: stable/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 stable/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: stable/mysql
    valuesFiles:
    - mysql/values.yaml
    - mysql/values.production.yaml

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

helm install database stable/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.

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: stable/mysql
    replaceImageTags: false

Helm Options​

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: stable/mysql
    wait: true

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

helm install database stable/mysql --wait

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: 180

Example: Helm Flag Timeout​

deployments:
- name: database
  helm:
    chart:
      name: stable/mysql
    timeout: 300

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

helm install database stable/mysql --timeout=300

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: stable/mysql
    force: true

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

helm install database stable/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: stable/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: stable/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: stable/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: stable/mysql
    disableHooks: true

driver​

The driver option expects a string that states the storage driver that should be used by Helm. By default, Helm 3 uses Kubneretes secrets to store the deployment configuration of a release. Alternative options include configmaps or memory.

danger

This option is not compatible with v2: true.

Default Value for driver​

driver: secrets

Example: Use Different Driver​

deployments:
- name: database
  helm:
    chart:
      name: stable/mysql
    driver: configmaps

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: stable/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 stable/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: stable/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: stable/mysql