How to Setup Renovate for Helm Charts in GitHub

Hey guys, thanks for taking the time to read the following blog post. I hope it will benefit you in your Kubernetes learning path and help you create a positive impact in your organization.

Let's get into it…

Keeping source code up to date is one of the most critical aspects of long-living projects. Projects that fall behind on software updates can suffer from security issues, impaired performance, and even lack support if they neglect software updates for years.

In Kubernetes, a helm chart is a package that contains all the necessary resources to deploy an application to a Kubernetes cluster. Like software updates, the helm chart that we use from the community is also under development, and we also need to keep it updated.

Some of the updates that can come with new versions of a helm chart are:

Updated docker images
Updated Kubernetes API Versions
Support for new functionality and features
Updated Values file
New or updated CRD (custom resource definitions)
etc

One of the most known tools that can help us keep our 3rd party helm charts with their latest versions is Renovate by Mend.io.

What will be covered

What is Renovate by Mend.io
Storing 3rd party helm charts
Setting Renovate Github app
Configuring renovate.json file

What is Renovate by Mend.io

Renovate by Mend.io, previously known as WhiteSource Renovate before the rebranding, is an open-source tool designed to automate the updating of software dependencies. Its primary function is to keep project dependencies up-to-date by automatically creating pull requests to update them to the latest versions. Removing from us the need to manually track the 3rd party dependencies we are using.

Renovate can automate a wide variety of dependencies across languages and tools, from npm, maven, and pip to docker images and helm charts. It can be easily implemented and is highly configurable for more advanced users. Renovate supports multiple platforms like GitHub and GitLab and has multiple deployment options.

This blog post will share how we store helm charts internally and how we use Renovate to keep them updated.

Storing 3rd party helm charts

In KubeGurus, we use an internal repo called helm-charts to store any 3rd party chart we will utilize in our Kubernetes Cluster. We are using the chart as a dependency, which provides us with extra flexibility when we are working with our charts.

For example, we will execute the following flow to add Traefik as a helm chart in our internal repo:

# Adding Traefik chart repo
helm repo add traefik https://traefik.github.io/charts
# Update repository
helm repo update
# List the current version of the chart

Once we know the Traefik version, we will create a folder in our helm-charts repo called “traefik”. Under the folder, we create and populate a chart.yaml file with the following lines

apiVersion: v2
name: traefik
description: A Helm chart for Kubernetes
type: application
version: 1.0.0
dependencies:
 - name: traefik
   version: 27.0.1
   repository

For this post, we will use Traefik in version 27.0.1 instead of the latest version so that Renovate will act once we finish his setup.

Setting Renovate GitHub App

Now, we have an outdated helm chart in our internal helm-charts repository. To keep it updated with future versions, we will install the Renovate GitHub App. Renovate has multiple implementations from which we can choose; using the GitHub App is just one of the available and more convenient options.

You can setup the Renovate app in your GitHub organization with the following link

When we install the GitHub app, we can pick any repository in the organization; for this setup, the only repo needed is our “helm-charts” repository.

Once a GitHub repository is integrated with the Renovate app, an onboarding pull request is automatically generated. Renovate can identify the underlying package manager through the repository files, suggesting potential upgrades right away. It also provides a summary of the proposed configuration. As end users, we have the flexibility to modify the Renovate behavior by modifying the renovate.json file on the Pull Request branch.

The following screenshot shows that Renovate has detected Helm charts within the repository and presents a configuration summary, outlining what to expect once the onboarding pull request is merged.

By default, Renovate adds his configuration file in the root folder, but as a convenience, I would suggest moving it over to the .github directory for a clear separation.

Configuring renovate.json File

In case you merge the PR as it is, you can expect the following to happen:

New issue for Renovate dependency dashboard (needs issue panel enabled in the repository settings).
Pull Request for our helm chart with an update to its dependencies.
Automatic Renovate runs every two hours and 30 minutes.

While for newcomers and small teams, it can be enough, we found the following added config can be beneficial:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended"
  ],
  "enabledManagers": ["helmv3"], // Check only for helm package manager in the repo
  "assignees": ["kubegurus"], // Assigned dedicated personal to the task so it would be noticed and managed
  "postUpdateOptions": ["helmUpdateSubChartArchives"], // Runs helm dependency build to update the subcharts
  "schedule": ["on saturday"], // Define a schedule, cron is also supported
  "timezone": ["israel"], // Set Israel time zone for the schedule
  "separateMinorPatch": true, // Set a seperate PR for minor (1.x) and patch (1.x.x) 
  "labels": ["renovate","{{depName}}"], // Custom PR labels
  "packageRules": 
   [
      {
        "description": "Label for major releases",
        "matchUpdateTypes": ["major"],
        "addLabels": ["major"]
      },
      {
        "description": "Label for non-major releases",
        "matchUpdateTypes": ["minor", "patch", "pin"],
        "addLabels": ["non-major"

The config shown above is just a scratch of the surface when it comes to Renovate. There are many more configurations you can add to make it fit your business needs, but the bottom line and the most important aspect is that our helm charts will be updated.

After updating the Renovate configuration file, we can close the configuration pull request. In a few minutes, the Renovate bot will open a GitHub issue with a dependency dashboard. Through the dependency dashboard, we can view which dependency Renovate found and manually trigger Renovate to create a PR with the suggested update.

To Conclude,

The automation of Helm chart updates with Renovate on GitHub not only streamlines the maintenance of Kubernetes deployments but also significantly enhances the security and efficiency of managing third-party dependencies.

By integrating Renovate into our workflows, we reduce manual operations and enable a more robust, automated update process. This practice, as outlined in our journey with the Traefik helm chart and our internal repository configurations, can be invaluable for any team looking to optimize their deployment strategies in a quickly changed technological landscape.