Using Helm Dependencies for third party charts

4 min readNov 10, 2023

When you are installing packages into a Kubernetes cluster, the go-to solution for software writers is to provide a Helm chart with a default values.yaml file to allow you to easily deploy all of the required resources for their application with a few commands.

You will normally see something like this when you are looking for installation instructions via Helm.

First add our helm charts repo to your helm client

helm repo add..

Next, install our chart via helm using

helm install..

This increases in complexity depending on the number of charts required to install a full working solution (I’m looking at you istio..) Where you may have 3/4 separate charts to install with different values required.

Additionally, I am not a fan of this approach as I like to deploy all infrastructure and packages via “GitOps” which allows for change control management as well as easy restore in the event of a cluster failure (eg redeploying from a git repo with my values stored in it is easier than finding the helm repo add && helm install commands for the wide range of services I’m now running in my cluster.

Photo by brooklyn on Unsplash

The solution

The solution for these problems is to use “Dependencies” in your helm charts.

Helm docs on dependencies:

So what does this look like?

For demonstration purposes, we’ll be installing Falco in our Kubernetes cluster (as I did for this article I wrote: Falco in Kubernetes with Alertmanager notifications).

We’ll start by creating our Helm Charts.yaml file for our new project

apiVersion: v2
name: falco
description: A helm chart to deploy Falco into Kubernetes
type: application
version: 1.0.0
appVersion: 1.0.0

Now, we need to gather some information on the source helm chart before we add the dependency onto our local Helm chart.

We’ll gather this information from the Helm installation instructions provided by Falco: