Introduction

Using a private Helm repository with CDK and EKS is mostly a question of where chart authentication happens. The chart itself is easy to install once the cluster can reach the repository, but private repositories add credential handling, network access, and deployment-tooling constraints that are not present with public chart URLs.

Understand the Deployment Boundary

When you write CDK code such as an EKS Helm chart deployment, there are usually three moving parts:

• the CDK application that synthesizes the deployment
• the mechanism that installs the chart into the cluster
• the private chart registry or repository that requires authentication

The important question is: who authenticates to the private repo?

That answer determines whether the simplest solution is:

• a local chart asset
• an HTTP(S) private Helm repository with credentials
• an OCI-based registry such as ECR

The Simplest Private Option: Use a Local Chart Asset

If the chart is owned by your team, the easiest path is often to keep the chart in the repository and let CDK deploy it from local files rather than from a remote private repo.

1import * as eks from 'aws-cdk-lib/aws-eks';
2
3cluster.addHelmChart('MyChart', {
4  chart: './helm/my-app',
5  release: 'my-app',
6  namespace: 'default',
7  values: {
8    replicaCount: 2,
9  },
10});

This avoids remote-repo authentication entirely and is often the cleanest answer for internal charts.

Remote Private Repo: Authentication Is the Hard Part

If the chart must come from a private remote repo, you need a way for the deployment process to authenticate.

In principle, the Helm install command needs something equivalent to:

helm repo add my-private-repo https://repo.example.com/charts \
  --username my-user \
  --password my-password

The challenge in CDK is not Helm itself. It is securely passing those credentials into the deployment path without hardcoding them into source code or CloudFormation templates.

That is why many teams avoid raw private Helm repos and instead choose either local assets or OCI-backed registries.

OCI Registries Are Often Cleaner

Helm charts can be stored as OCI artifacts in a registry. In AWS-centric environments, an OCI-capable registry such as ECR is often easier to integrate operationally than maintaining a classic private Helm repository.

This is attractive because:

• authentication can align with AWS IAM
• registry access fits existing AWS workflows
• artifact storage and permissions are centralized

Whether CDK uses that directly or your CI pipeline pulls and installs it, OCI often simplifies the private-chart story compared with legacy repo credentials.

CDK and Values Injection Still Work the Same

Regardless of where the chart comes from, you still configure release values in CDK the same way.

1cluster.addHelmChart('MetricsServer', {
2  chart: 'metrics-server',
3  repository: 'https://kubernetes-sigs.github.io/metrics-server/',
4  namespace: 'kube-system',
5  values: {
6    args: ['--kubelet-insecure-tls'],
7  },
8});

The difference with private repos is that the repository field alone is not enough unless the deployment path can also authenticate.

Practical Strategy Choices

A pragmatic rule is:

• if you own the chart and deploy it from the same codebase, use a local chart asset
• if you need centralized chart distribution across teams, prefer a registry model that fits your auth system well
• if you must use a classic private Helm repo, plan the secret-management story first

Security and operability matter more here than the chart syntax itself.

Common Pitfalls

The biggest mistake is assuming repository: 'https://private.example.com' is enough for a private chart. Repository URL and repository authentication are separate problems.

Another mistake is hardcoding repo credentials into CDK source code or plaintext values files.

A third issue is choosing a remote private chart repo when a local chart asset would have been simpler and more maintainable.

Finally, do not debug only the Helm chart content. With private repos, network reachability, credentials, and deployment-role permissions are often the actual root cause.

Summary

• Private Helm repos with CDK EKS are mainly an authentication and delivery problem.
• The easiest solution is often to deploy a local chart asset instead of a remote private repo.
• Remote private repos require a secure credential strategy outside the chart URL itself.
• OCI-based registries can be operationally simpler than classic private Helm repositories.
• CDK values injection works the same once chart access is solved.
• Pick the chart-distribution model that matches your security and deployment workflow, not just the one that looks most familiar.