☸️ The Complete Guide to Helm Values: From Configuration Methods to Argo CD InitContainer Secrets

Jun 22, 2026

—

Hello! If you’ve used Helm, the Kubernetes package manager, you’ve probably wondered, “Why isn’t my configured value being applied?” or “How do I set up a private repository when using external charts in Argo CD?”

Today, we’ll provide a detailed 10-minute guide covering all methods for injecting Helm values, their precedence (priority), and the InitContainer utilization techniques used by Argo CD operation experts. 🛠️

1. 📂 All Methods for Specifying Helm Values

Helm receives values in various ways for flexibility. We’ve summarized the characteristics and uses of each method.

① values.yaml file (Default)

This is the default configuration file included within the chart.

Purpose: Defines the default specifications provided by the chart developer.
Characteristic: Has the lowest precedence.

② –values or -f (External File)

Specifies a separate YAML file written by the user.

Purpose: Separating configurations by environment (Dev, Staging, Prod).
Command: helm install my-app ./my-chart -f values-prod.yaml

③ –set (Inline Flag)

Directly inputs key-value pairs from the terminal.

Purpose: Dynamically changing tags in CI/CD pipelines or modifying very simple values.
Command: helm install my-app ./my-chart –set image.tag=v2.0.0

④ –set-file (Injecting File Content as a Value)

Injects the entire content of a file (e.g., script, configuration file) as the value for a specific key.

Purpose: Injecting large configuration files into a ConfigMap.

⑤ –set-string

Forces all values to be interpreted as strings. (Prevents numbers like 0 from being recognized as booleans)

2. 🏆 Values Application Precedence

If configuration methods overlap, which value does Helm choose? Remember: “What is defined later or is more specific wins.”

Precedence	Configuration Method	Notes
1 (Highest)	–set (Inline)	The ultimate weapon that overwrites last
2	–values (-f)	Among the file list, the rightmost file takes precedence
3	Parent chart’s values.yaml	When a parent chart overwrites a child chart’s values
4 (Lowest)	Chart’s internal values.yaml	Default value

—

3. 🏗️ Argo CD Advanced Technique: Adding Helm Repos with InitContainer

When operating Argo CD, you might encounter this situation:

“We have an internal private Helm repository, and Argo CD needs to fetch charts from it every time. However, managing authentication information or repository registration declaratively each time is cumbersome.”

The solution here is to add an InitContainer to the Argo CD Repo Server to pre-register the Helm repository.

❓ What is this?

It involves launching a temporary container (InitContainer) before argocd-repo-server, an Argo CD component that communicates with Git or Helm repositories, starts, and executing the `helm repo add` command within it.

💻 How to configure it? (Based on Kustomize/Helm)

You need to modify the Argo CD installation manifest (Deployment).

YAML

# Modify argocd-repo-server Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: argocd-repo-server
spec:
  template:
    spec:
      # 1. Define a shared volume to store Helm configurations 📂
      volumes:
        - name: helm-working-dir
          emptyDir: {}

      # 2. Configure InitContainer to run before the main container 🚀
      initContainers:
        - name: helm-repo-adder
          image: alpine/helm:latest
          command: ["/bin/sh", "-c"]
          args:
            - |
              # Add internal private repository
              helm repo add my-private-repo https://charts.mycompany.com --username $REPO_USER --password $REPO_PASS
              # Update repository
              helm repo update
          env:
            - name: REPO_USER
              valueFrom:
                secretKeyRef:
                  name: repo-credentials
                  key: username
          # Important: Mount the path where added repo info is stored as a shared volume
          volumeMounts:
            - name: helm-working-dir
              mountPath: /root/.config/helm

      # 3. Mount the same volume in the main container as well 🔗
      containers:
        - name: argocd-repo-server
          volumeMounts:
            - name: helm-working-dir
              mountPath: /app/config/helm # Path where Argo CD looks for Helm configurations

✨ Reasons to use this method

Dynamic Management: Repositories are automatically registered via code when the server starts, eliminating the need for manual registration in the Argo CD UI.
Security: Credentials are injected securely via Secrets.
Dependency Resolution: When resolving third-party chart dependencies declared in Chart.yaml, a local Helm cache is pre-built, leading to faster operations.

4. 💡 Practical Application Tips

Avoid Inline (–set): When using Argo CD, prefer `values.yaml` or files stored in Git. Inline configurations are difficult to track later.
Structural Separation: It is best practice in GitOps to manage common configurations in `values.yaml` and environment-specific differences in `values-dev.yaml`, `values-prod.yaml`.
Argo CD Helm Application: Within the Argo CD Application resource, you can achieve the same effect as `–set` through `helm.parameters`.