Introduction

Adding NGINX Ingress and cert-manager as Helm chart dependencies is technically possible, but it changes your chart from an application chart into an umbrella chart that also manages cluster-level infrastructure. That can be useful in tightly controlled environments, but it also introduces upgrade, CRD, and ownership concerns that are easy to underestimate.

Core Sections

Declare dependencies in Chart.yaml

Helm dependencies are defined in Chart.yaml. A minimal example looks like this:

1apiVersion: v2
2name: my-app
3version: 0.1.0
4dependencies:
5  - name: ingress-nginx
6    version: 4.11.0
7    repository: https://kubernetes.github.io/ingress-nginx
8    condition: ingressNginx.enabled
9  - name: cert-manager
10    version: 1.15.3
11    repository: https://charts.jetstack.io
12    condition: certManager.enabled

Then fetch the charts:

helm dependency update

That populates the charts/ directory or updates the dependency lock information for reproducible installs.

Pass values to the dependency charts

Subchart configuration is normally supplied through the parent chart's values.yaml using the dependency name as the top-level key.

1ingressNginx:
2  enabled: true
3
4certManager:
5  enabled: true
6  installCRDs: true

The exact keys depend on the chart you are consuming, so always confirm them against the dependency chart's documentation rather than guessing the value structure.

Why this is not always the best design

Ingress controllers and cert-manager are often cluster-shared infrastructure, not app-local components. That means one application chart installing them as dependencies can create awkward ownership boundaries:

• multiple apps may try to install the same controller
• upgrades become tied to one app release
• uninstalling the app may remove shared infrastructure
• cluster administrators may want separate lifecycle control

For many teams, the better pattern is:

1. install ingress-nginx separately
2. install cert-manager separately
3. let the app chart depend only on their existence

That keeps application releases smaller and avoids turning one chart into the owner of foundational cluster services.

cert-manager CRDs need special attention

cert-manager uses Custom Resource Definitions. That makes it more sensitive than a normal dependency because CRDs affect the cluster itself, not just one namespace.

A common configuration is:

certManager:
  installCRDs: true

This can work in a new cluster bootstrap flow, but it is risky in shared clusters where CRDs are managed centrally. CRD upgrades should be treated carefully because they can affect every namespace and every cert-manager resource in the cluster.

Use dependencies only when you control the environment

Bundling ingress-nginx and cert-manager is most defensible when you control the full environment, such as:

• an internal platform chart for ephemeral clusters
• a local development stack
• a demo or training environment
• a single-tenant cluster with one release owner

In those situations, an umbrella chart can be convenient because one install brings up the full stack.

Common Pitfalls

• Treating cluster-wide infrastructure like a harmless app-local dependency.
• Installing cert-manager CRDs from an application chart without agreeing on cluster ownership.
• Using the wrong dependency value keys because the parent chart did not mirror the subchart structure correctly.
• Expecting uninstall behavior to be safe when multiple applications rely on the same ingress controller or certificate manager.
• Tying upgrades of ingress-nginx or cert-manager to one application release when they should have their own lifecycle.

Summary

• You can add ingress-nginx and cert-manager as Helm dependencies in Chart.yaml.
• Parent charts configure subcharts through namespaced keys in values.yaml.
• This pattern works best for umbrella charts in environments you fully control.
• In shared clusters, these components are often better installed and upgraded separately.
• cert-manager is especially sensitive because CRDs make it a cluster-level concern, not just a namespace-level dependency.