GitOps allows us describe our running environment from a Git repo. We are able to state the deployments and the Helm charts that should be part of a Kubernetes cluster. As such, we can declaratively specify the version of these deployments and charts that ought to exist in the cluster.

But, throughout development, it would be cumbersome to continue to increment image tags each time we want to deploy to a non-prod environment. And, we might not even want to do this for production either. Flux automated upgrades help with this.


  • Flux installed on the cluster
  • Helm operator installed on the cluster (optional)
    • If you’re using Azure Container Register to store helm charts, see here

When you install Flux, ensure you have added the public key for Flux as a deploy key to the Git repo so that the Flux operator can write and commit.

Also, if you’re using Azure Container Registry, ensure you have installed Flux with registry.acr.enabled=true option. This is necessary so that Flux can authenticate against Azure Container Registry and get the list of tags for a container image. Role of AcrPull should be enough.

helm upgrade -i flux fluxcd/flux \
        --set git.url=[some repo url] \
        --set registry.acr.enabled=true \
        --namespace flux \

Automated upgrades

You can enable automated image tag updates by annotating Helm release objects and Kubernetes deployments.

kind: HelmRelease
  name: realworld-backend
  namespace: realworld
  annotations: "true" glob:stg-*
  releaseName: realworld-backend
    name: realworld-backend
    version: 0.1.1
      tag: stg-6df42957762c89cda02a2ada2c32ea2810e070f4

Here, any new tags pushed to the container registry will be picked up by Flux and commit an update back to the repository. But, the tag has to follow the glob pattern of starting with stg-.

There are other types of pattern matching like semver, and regex.

Here’s a repo called helm-operator-get-started that shows how to use each of the patterns.