Pin Docker Image and Dependency Versions in Helm Chart

[lucas-koontz]

Description
The current Langfuse Helm chart does not pin an exact Docker image version, instead using a version that varies with each release (values.yaml#L6). This behavior is similar to using latest, which is not explicit enough and can lead to unexpected errors for users relying on the Helm chart.

The image tag should be pinned to a specific version. As of today (February 18, 2025), the latest version is 3.28.3.

Additionally, dependencies in Chart.yaml are currently soft-locked to major versions (e.g., 16.x.x for PostgreSQL, 7.x.x for ClickHouse, etc.). This can also introduce unexpected breaking changes. Pinning dependencies to exact versions would improve stability and predictability.

Steps to Reproduce:

1. Install the Langfuse Helm chart.
2. Notice that the image tag is not explicitly pinned, leading to potential variation between deployments.

Expected Behavior:

• The Docker image version should be explicitly pinned (e.g., 3.28.3).
• Dependencies in Chart.yaml should be locked to exact versions instead of using x.x.x ranges.

Additional Context:

• Values file reference: values.yaml#L6
• Dependencies file reference: Chart.yaml

This change would improve stability and ensure that users always deploy a known, tested configuration.

[AndrewFarley]

Note: This can cause unexpected outages with no changes on our side, and it generally against the nature of how you deploy services into Kubernetes which should remain static until an engineer decides to upgrade it. Please fix urgently.

[marcklingen]

Thanks for raising this!

@Steffen911 are there planned changes related to this as part of v1 of this chart?

[Steffen911]

@lucas-koontz @AndrewFarley
Regarding the image versions: You can overwrite the appVersion on the chart or the image.tag in the values.yaml to pin the respective version. That way we do not have to tie releases of the app to releases of the chart and follow common best practices as far as I know. We have a default of 3 as this is something that many clients expect to get the latest features of Langfuse, but for anyone who wants to avoid all outside influence, pinning that to a specific patch is a viable alternative.

Regarding the sub-charts: We trust bitnami to adhere to semantic versioning and have good experience with that in the past. An option could be that we include the Chart.lock file to realize the pinning, but I'm not sure how that is consumed by tools like Terraform if they are used to deploy. And my understanding is that the chart dependencies are only resolved and updated on helm changes, i.e. they wouldn't cause any "non-interaction" outages.

[AndrewFarley]

@Steffen911 I'm not sure you're understanding what you're doing. You're effectively using "latest" and thus forcing your latest updates upon people not upon their own choosing. I believe it is important to note that this is effectively forcing others to run bleeding edge and not allowing them to choose when they are ready to update. This approach can cause downtime at unexpected times, which I've experienced multiple times first hand, including with your chart.

What you're doing is also a large security issue, in that you could push a bad update to the latest 3 tag which compromises the security or integrity if your supply chain gets compromised.

This is generally why many who practice secure supply chains have registries configured for immutable tags to prevent someone from overwriting tags. I do want to say, it is okay that you use mutable tags such as 3 for people who choose to opt-in to always use the latest in the 3 series. It can be useful eg: for a local docker compose / development usage pattern. But, when publishing things like a Helm Chart which runs in people's internal secure networks, they need to be pointed to static, immutable images.

No other helm chart of any service I'm aware of uses this anti-pattern of yours. I ask you to go check every single other helm chart out there, cluster-autoscaler, aws-load-balancer-controller, metrics-server, aws-ebs-csi-driver, aws-efs-csi-driver, external-dns, grafana, ingress-nginx, oauth2-proxy, prometheus, etc.

All of these and every Helm Chart I've ever seen use static immutable image references to specific images per published chart version, they do not use tags which refer to changing references like latest or 3. To your reference, all of the bitnami charts use specific tag references that are static, not tags which they change references to, such as 3 to my knowledge.

What you've done here is a neat trick for inside a company where you can choose to on behalf of your entire company to run bleeding edge. But, you can't and shouldn't do this on behalf of the entire open source community.

I ask, or rather beg you to reconsider. On behalf of another passionate open-source contributor who authors and supports numerous other Helm Charts. Do the right thing here.