How to Use Nexus Repository and Helm for CI/CD

This article is based on a post originally authored by Gaurav Agarwal and syndicated via the Security Bloggers Network from the Sonatype Blog. The original post covers Nexus Repository and Helm integration for CI/CD.

What Is Helm and Why Does It Matter for Kubernetes?

Helm is widely regarded as the de facto package manager for Kubernetes. It allows DevOps teams to version, distribute, and manage Kubernetes applications as reusable, parameterized units called charts. As Kubernetes adoption grows — especially in microservices architectures with hundreds of interacting containers — managing raw YAML manifests becomes increasingly error-prone and unscalable. Helm addresses this directly.

Why Use Helm? Three Core Benefits

1. Templating Kubernetes Applications

A Docker image acts as a reusable template for creating multiple containers. Raw Kubernetes YAML manifests do not offer the same flexibility — deploying two instances of the same application (for example, two PostgreSQL databases with different configurations) traditionally requires duplicating and manually editing manifest files.

Helm solves this with charts and values files. You define a single generic chart and supply different variable values to produce separate, independently configurable releases. This dramatically reduces repetition and the risk of configuration drift.

# Install a PostgreSQL release named "pg-production"
helm install pg-production stable/postgresql --set postgresqlPassword=secret1

# Install a second release named "pg-staging"
helm install pg-staging stable/postgresql --set postgresqlPassword=secret2Code language: PHP (php)

2. Semantic Versioning of Kubernetes Applications

Storing Kubernetes manifests in a source-code repository is a common starting point, but it comes with a significant limitation: manifests stored this way are not semantically versioned as deployable artifacts. Rolling back to a specific release requires checking out a specific commit and re-applying files manually — a fragile workflow in production.

Helm packages an application as a versioned chart (e.g., myapp-1.4.2.tgz) and stores it in a Helm repository. This means you can:

• Pin deployments to a specific chart version.
• Roll back to any previously published version with a single command.
• Audit which version of an application is running in each environment.

# Roll back a release to revision 2
helm rollback my-release 2Code language: PHP (php)

3. Reusing and Sharing Charts

Just as Docker Hub provides a public registry for container images, Helm repositories allow teams to publish and consume charts. Public charts for popular software (NGINX, PostgreSQL, Redis, and many others) are available via community repositories such as the Artifact Hub. Internal teams can publish private charts to a self-hosted repository, making it easy to share approved, production-tested application packages across projects and teams.

Where Nexus Repository Fits In

Sonatype Nexus Repository Manager supports Helm chart repositories natively, allowing organisations to host private Helm repositories alongside their other artifact types (Maven, npm, Docker, PyPI, etc.) in a single, centrally managed platform. This integration is particularly valuable in enterprise CI/CD pipelines for the following reasons:

• Centralised artifact governance: Security policies, access controls, and audit logs can be applied to Helm charts using the same tooling already in place for other artifacts.
• Proxy and caching: Nexus can proxy upstream public Helm repositories, caching charts locally to improve build reliability and speed, and to reduce dependency on external network access.
• Private hosted repositories: Internal charts that should not be published publicly can be stored securely in a hosted Nexus Helm repository.
• CI/CD pipeline integration: Build pipelines can push newly packaged charts to Nexus after a successful build, and deployment stages can pull the exact versioned chart required for a given environment.

Typical CI/CD Workflow with Helm and Nexus

A representative CI/CD pipeline integrating Helm and Nexus Repository might follow these stages:

1. Develop: Write or update application code and the corresponding Helm chart in source control.
2. Build & Test: The CI server builds the Docker image, runs tests, and packages the Helm chart using helm package.
3. Publish: The CI server pushes the versioned chart archive (.tgz) to a hosted Helm repository in Nexus.
4. Deploy to Staging: The CD pipeline pulls the chart from Nexus and installs or upgrades the release in a staging Kubernetes cluster using helm upgrade --install.
5. Promote to Production: After validation, the same chart version (unchanged) is deployed to the production cluster, guaranteeing parity between environments.
6. Rollback if needed: If a problem is detected, helm rollback restores a previous release instantly using the artifact stored in Nexus.

# Package the chart
helm package ./my-chart

# Push to Nexus (using curl; Nexus exposes an HTTP upload endpoint)
curl -u user:password \
  --upload-file my-chart-1.0.0.tgz \
  https://nexus.example.com/repository/helm-hosted/

# Add Nexus as a Helm repo on the deployment host
helm repo add my-nexus \
  https://nexus.example.com/repository/helm-hosted/ \
  --username user --password password

helm repo update

# Deploy a specific version
helm upgrade --install my-release my-nexus/my-chart --version 1.0.0Code language: PHP (php)

Key Takeaways

• Helm brings Docker-style packaging and versioning to Kubernetes application deployment.
• Charts enable reusable, parameterized Kubernetes configurations that scale well in microservices environments.
• Nexus Repository provides enterprise-grade hosting, proxying, and governance for Helm charts.
• Together, they enable reproducible, auditable, and rollback-capable Kubernetes deployments within a CI/CD pipeline.

For a deeper walkthrough of configuring Nexus Repository as a Helm chart host and integrating it into a real pipeline, refer to the Sonatype Nexus Repository documentation.