Helm in Practice

Understanding Helm Dependencies

Helm dependencies allow a chart to include other charts as subcharts. When you install your chart, Helm automatically installs all declared dependencies first to ensure the proper order of resource creation.

Dependencies are declared in Chart.yaml and can be sourced in three ways:

• Downloaded from a Helm repository
• Stored locally in the charts/ directory
• Using aliases to include the same chart multiple times with different configurations

Downloaded from a Helm Repository

The most common approach is to reference charts from public or private Helm repositories. Helm downloads these charts during the dependency build process.

# Chart.yaml
name: my-help-app
version: 0.1.0
[...]
dependencies:
  # From a public Helm repository
  - name: my-subchart-1
    version: "2.3.4"
    repository: "https://a-public-helm-repo.example.com"

  # From an OCI registry (Harbor, ECR, ACR, etc.)
  - name: my-shared-library
    version: "1.2.0"
    repository: "oci://my-registry.example.com/charts"

  # From a private Helm repository
  - name: my-internal-service
    version: "2.0.0"
    repository: "https://charts.internal.company.com"

When you run helm dependency build, Helm downloads these charts and stores them as .tgz files in the charts/ directory. This results in a charts/ folder populated with the downloaded dependencies:

my-help-app/
└── charts/
    ├── my-subchart-1-2.3.4.tgz
    ├── my-shared-library-1.2.0.tgz
    └── my-internal-service-2.0.0.tgz

Stored Locally

For charts you maintain in the same repository, or want to bundle directly, you can store them in the charts/ directory. Helm uses these files directly without downloading.

my-app/
├── Chart.yaml
├── values.yaml
├── templates/
└── charts/
    └── my-local-subchart/  # A local chart directory
        ├── Chart.yaml
        ├── values.yaml
        └── templates/

You declare them using a file:// path:

# Chart.yaml
dependencies:
  - name: my-local-subchart
    version: "1.0.0"
    repository: "file://charts/my-local-subchart"

This approach is useful for different scenarios, from monorepo setups to air-gapped environments:

• Monorepo setups: where multiple charts share common components
• Air-gapped environments: where you cannot download from external repositories
• Development workflows: where you're iterating on both parent and child charts

Aliased Dependencies

Aliases allow you to include the same chart multiple times with different configurations. This is useful when your application needs multiple instances of the same service.

Let's imagine an application that requires two PostgreSQL databases - one for primary application data and another for analytics/reporting. These databases, for some reason, need to have different configurations, versions, and resource allocations. In this case, we can use aliases to include the PostgreSQL chart twice with different settings.

# Chart.yaml
[...]
dependencies:
  # Primary PostgreSQL for application data
  - name: postgresql
    version: "16.4.3"
    repository: "https://charts.bitnami.com/bitnami"
    alias: primary-db
    condition: primaryDb.enabled

  # Secondary PostgreSQL for analytics/reporting
  - name: postgresql
    version: "16.4.3"
    repository: "https://charts.bitnami.com/bitnami"
    alias: analytics-db
    condition: analyticsDb.enabled