introduce kustomize chartHome capability to manage charts locally

[wibed]

in my setup chartHome does not only cache the helmcharts applied on a local directory, and therefor keeping netowrk traffic low.

but it also serves as a quick mockup dir where i can test adjustments on charts before making a pr, customizations etc. add additional resources. or express them as patchonmergestrategy(orwhateverkustomizecalledit)

anyways. kpt has this wierd behaviour that it does try to mount the chartHome directory or in case it does not find it downloads it into the container. (until now just as kustomize would), but the point is the --network flag.

it gives, from my point of view, the impression to give network privilege to the container but its just to open a connection to the source of the chart and able to download it.

if there is a new chart or a version change it would imply a --network flag on any call.
do i confuse something?

[dosubot]

You're not confusing things — the behavior is a bit unintuitive by design. Here's what's going on:

chartHome is a local lookup directory, not an automatic cache. The render-helm-chart function checks chartHome for the chart before attempting to pull from a remote repo [1]. If the exact chart name + version is already present there, it uses the local copy. If it's not found (e.g., new chart or version bump), it tries to fetch remotely — which requires network access.

The --network / --allow-network flag controls container-level networking. By default, kpt runs functions with --network none on the container [2], so the function literally cannot reach the internet. When you pass --network (on fn eval) or --allow-network (on fn render), it switches to --network host, giving the container full network access [3]. So yes, the flag grants general network privilege to the container — it's not scoped to just chart downloads.

Your concern about version changes is valid: any time the exact chart+version isn't already in chartHome, the function needs network access to download it. There's no incremental/delta fetch — it's either local or remote.

One important gotcha: mount support is currently disabled for fn render [4]. So if you want to mount your local chartHome directory into the container, you need to use kpt fn eval with --mount instead. With fn render, the function can't access your host filesystem's chartHome directly.

So the typical workflow for your use case (local chart testing without network) would be:

1. Keep your charts in a local directory
2. Use kpt fn eval with --mount to bind that directory as chartHome
3. Skip --network since the charts are already local

If you're using fn render in a pipeline, the mount limitation is a real friction point — you'd need --allow-network any time charts aren't baked into the container image itself.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[wibed]

using kustomize it was able to manage such a separate dir named chartHome.
that this feature is not available is unfortunate.

• to rely on a separate mount flag to make charts available, is polluting at best.
• the need to keep downloading charts increases traffic, eventually time outs on restricted endpoints.
• keeping a local registry before the registry has actually put into place.

i would like to see this feature in kpt, respecting chartHome definitions of helm charts and manage helm charts on the local filesystem, ideally at the indicated directory. (it might use a dot directory and mount the addressed chart directly)