I was reviewing our staging cluster's Helm chart dependencies today and noticed something interesting in the `Chart.yaml`—several of our internal dependencies are now pulling from an OCI registry instead of a classic chart repository. I knew Helm 3 supported OCI for a while, but I hadn't dug into using it for dependencies until now.
Turns out the syntax is pretty straightforward. Instead of the classic `repository` URL pointing to a Helm repo, you define the dependency with an `oci://` prefix. Here's a snippet from a test chart I was playing with:
```yaml
dependencies:
- name: redis
version: "18.0.0"
repository: "oci://registry-1.docker.io/bitnamicharts"
- name: postgresql
version: "13.0.0"
repository: "oci://ghcr.io/helm/charts"
```
After adding these, you run the usual `helm dependency update`. Helm handles the authentication if your registry requires it—you can use `helm registry login` beforehand, similar to Docker.
This has some immediate FinOps implications for us:
* **Consistency:** We can use the same OCI registry (like ECR, GAR, or ACR) for both container images and Helm charts, simplifying access control and auditing.
* **Cost tracking:** If your registry charges by storage, remember that chart layers add up. We once had a surprise bill from storing hundreds of chart versions.
* **Cache efficiency:** In air-gapped or bandwidth-constrained environments, pulling from a single registry type might reduce egress costs and latency.
Has anyone else migrated their internal chart dependencies to OCI? I'm particularly curious about:
* Any pitfalls with version constraints or dependency resolution?
* How you're handling authentication in CI/CD pipelines compared to classic repo setups?
* Whether you've seen any impact on deployment times or Helm operation costs?
Nice find. The consistency angle is spot-on, especially for teams already managing OCI registries for images. It does make auth and RBAC so much simpler when it's all in one place.
One caveat I'd watch out for in procurement is that some vendors might still publish charts exclusively to their classic Helm repos. It's worth checking their distribution strategy before committing to an OCI-only dependency model, or you might end managing both methods.
How's the performance compare for you on a `helm dependency update`? I've heard mixed reports about pull times from OCI registries versus traditional chart repos.
Trust the data, not the demo.
Good point about vendors sticking with classic repos, that's something I'll need to check for our external tools. Regarding the performance, I haven't used OCI for dependencies in production yet, but I did a quick test locally.
Running `helm dependency update` on a chart with a few OCI dependencies felt a bit slower than our usual Artifactory repo. Nothing major, maybe a second or two more per chart? Could've just been my network.
Is the performance difference something that gets more noticeable with larger charts or in a CI/CD pipeline where you're pulling a lot?