helm-operator

What is helm-operator image?

The helm-operator image runs a Kubernetes Operator that reconciles “HelmRelease” (or similar) custom resources into actual Helm releases in the cluster. Instead of running helm install and helm upgrade manually or from CI pipelines, you define desired releases in YAML, and the operator continuously ensures those charts are installed, upgraded, or rolled back to match the spec. It typically supports features like automated upgrades when chart versions change, value overrides, rollback on failure, and status reporting via Kubernetes conditions. In modern GitOps-style workflows, the helm-operator image is used to bridge Git (or another source of truth) and Helm charts, so that application releases are driven entirely by declarative config rather than ad hoc CLI usage.

How to use this image

The helm-operator image is deployed as a controller in Kubernetes, usually alongside CRDs that define Helm release resources. You don’t typically run it with docker run directly; instead you apply manifests or install a Helm chart that sets up the operator Deployment, RBAC, and CRDs.

Example (FluxCD legacy helm-operator via Helm):

helm repo add fluxcd https://charts.fluxcd.io
helm install helm-operator fluxcd/helm-operator \
  --namespace flux \
  --create-namespace \
  --set helm.versions=v3

Define a HelmRelease custom resource (simplified example):

apiVersion:helm.fluxcd.io/v1
kind:HelmRelease
metadata:
name:my-app
namespace:default
spec:
releaseName:my-app
chart:
repository:https://charts.bitnami.com/bitnami
name:nginx
version:15.0.0
values:
service:
type:ClusterIP

Once applied, the operator pulls the chart, installs or upgrades it, and reports status via the HelmRelease resource. Logs are written to stdout and collected by the cluster’s logging pipeline.

Image variants

Published most commonly under fluxcd/helm-operator, the image is available in several variants:

Many newer deployments have moved toward Flux v2’s helm-controller, but where helm-operator is still in use, pinning explicit versions is important for compatibility and upgrade safety.