<p>I may just be extremely slow, but I cannot wrap my head around this.</p>
<ul>
<li>There are repositories/hubs (artifacthub, etc.) with pointers to other repos that have helm charts</li>
<li>I can add these charts as a 'dependency' in my helm Chart.yaml file, if I know the name/version/repository</li>
<li>For example, for <a href="https://artifacthub.io/packages/helm/vultr/cert-manager-webhook-vultr" rel="nofollow noreferrer">https://artifacthub.io/packages/helm/vultr/cert-manager-webhook-vultr</a> the version=1.0.0, the dependency=vultr/cert-manager-webhook-vultr, and the repo=https://vultr.github.io/helm-charts (is this correct? Why are these 3 values not super visible. It always seems like a guessing game when trying to pull down charts)</li>
<li>On artifacthub, there is a 'templates' section, which has various yaml files. Is this what properties are possible to modify on the chart? How do these helm template yamls that I define get applied to charts I have installed? (For example, if I have both nginx and traefik ingresses, will both of them get all the yamls for kind:Ingress applied to them?)</li>
<li>Why does helm require me to pull down the cluster to my local repo to use it? Do people use helm to track releases in 'the real world'?</li>
<li>In what scenario would I just do 'helm install X' as opposed to adding it to my Chart.yaml dependencies?</li>
</ul>
<p>The helm docs (and lots of tutorials) are very terse and only show one off script examples. Shouldn't I want all of my 'infrastructure as code'? I don't understand the constant suggestions to 'helm add repo' and 'helm install' and then hand wave over any customization?</p>

Papi Abi
<p>I think the interesting part of this question is the last bullet point, around what to <code>helm install</code>; the rest of it is details.</p>
<p>I can imagine four different &quot;kinds&quot; of Helm charts:</p>
<ol>
<li><p>Library charts <em>only</em> contain <code>{{- define -}}</code> template blocks, but no Kubernetes resources.  This is a first-class concept in Helm 3 but pretty rare in the wild.</p>
</li>
<li><p>&quot;Infrastructure&quot; charts contain a prepackaged piece of software, like PostgreSQL or Redis, that you're probably not directly using.  They could depend on library charts.</p>
</li>
<li><p>&quot;Application&quot; charts contain, say, a single microservice, that you are directly using.  They likely depend on infrastructure charts, for example to get a service-local database.</p>
</li>
<li><p>&quot;Umbrella&quot; charts depend on specific versions of several applications and describe the combined system.</p>
</li>
</ol>
<p>So if you have a system, that consists of several services, and you want to track their releases, you have a couple of choices.  One is to build an umbrella chart and <code>helm upgrade</code> that chart as new component builds arrive; this has the mechanical problem that Helm likes to combine dependencies, so the &quot;service-local&quot; database dependencies will all get combined into one.  You can <code>helm install</code> the application charts individually, or use a tool like <a href="https://github.com/roboll/helmfile" rel="nofollow noreferrer">Helmfile</a> or <a href="https://github.com/Praqma/helmsman" rel="nofollow noreferrer">Helmsman</a> to manage a set of adjacent installed charts.</p>
<p>Within that hierarchy, though, you generally would install &quot;umbrella&quot; or &quot;application&quot; charts, but not directly install &quot;infrastructure&quot; or library charts.  Except in early experimentation you wouldn't typically <code>helm install bitnami/redis</code>, but instead include it as a dependency of your actual application.</p>
<hr />
<p>You're basically correct on the mechanics of using dependency charts.  Each chart includes a <code>templates</code> directory, and the templated YAML files there are installed in the cluster.  Each chart also includes a <code>values.yaml</code> file at its top level, and that's the only way to configure a dependency chart.  A parent chart can <a href="https://docs.helm.sh/docs/topics/charts/#scope-dependencies-and-values" rel="nofollow noreferrer">include configuration for its dependencies</a> under a key with the dependency name</p>
<pre class="lang-yaml prettyprint-override"><code># application/values.yaml
#   Chart.yaml depends on a specific chart named &quot;infrastructure&quot;
infrastructure:
  # This would be a top-level key in values.yaml in
  # the &quot;infrastructure&quot; chart
  username: foo
</code></pre>
<p>You can't really modify the actual template content from dependency charts; you can only customize what gets produced by setting values.  Some charts have better-documented values than others, and better ones have all of the details in their <code>README.md</code> file.</p>
<hr />
<p>You ask about a couple of implementation choices, and it's hard to give concrete answers about those.  You need to download dependencies into a local <code>charts</code> subdirectory (for example, with <code>helm dep up</code>), but I'm not sure why; I can imagine use cases around offline usage, where you transport a chart and its dependencies into an isolated network and run an installation there, but I can also imagine Helm preferring a <code>charts</code> directory and automatically downloading.  Similarly, finding charts can in fact be tricky, but one part of this is that maintaining a package repository is both financially and operationally complex.  There used to be an official &quot;stable&quot; charts repository but it was discontinued.</p>
<hr />
<p>One last piece I'll bring up here is the notion of &quot;cluster infrastructure&quot;.  You can imagine wanting to run an ingress controller or a logging agent, for example, that might be packaged as a Helm chart.  In my initial hierarchy I'd consider these as &quot;applications&quot;; a service chart could have a <code>type: Ingress</code> resource but wouldn't itself depend on the Nginx or Traefik ingress controllers.  You could have a Helmfile setup for cluster infrastructure parallel to your core application setup, or manage them together if you're sure you're only running one copy of your system in a cluster.</p>
