Skip to main content
Container Orchestration
Technology ServicesKubernetes · PackagingHelmVirginia · US-Based

Helm Charts

Helm is the package manager for Kubernetes. A Helm chart is a collection of Kubernetes manifests parameterized by a values file, so that the same chart can deploy to development, staging, and production with different configuration rather than duplicated manifests. We write and maintain Helm charts that are easy to upgrade, easy to configure, and compatible with GitOps deployment workflows.

Helm 3Chart RepositoryValues FilesHelmfileOCI ChartsArgoCDchart-testingTerraform

Capabilities

What we do with Helm

Chart from scratch

New Chart Authoring

Writing Helm charts for application workloads: Deployment, Service, Ingress, ConfigMap, ServiceAccount, HPA, and PodDisruptionBudget templates parameterized by a sensible values.yaml with environment overrides.

Installing upstream charts

Third-party Chart Configuration

Configuring and deploying upstream Helm charts (cert-manager, ingress-nginx, Prometheus, Loki, ArgoCD) with production-appropriate values files and any necessary customization via post-renderer or values merging.

Dev · staging · prod

Multi-environment Values Management

Structuring base values and per-environment override files so that the same chart deploys to each environment with correct image tags, resource limits, replica counts, and configuration without duplicating manifest files.

OCI · Chartmuseum

Chart Repository Setup

Setting up a chart repository — ECR OCI-based or a Chartmuseum server — for hosting private charts, with versioning strategy and CI automation to package and push on chart changes.

GitOps delivery

ArgoCD and Helm Integration

Wiring Helm releases into ArgoCD Applications for GitOps delivery, including values file references, Helm parameter overrides, and sync policy configuration.

Helmfile · Multiple releases

Helmfile for Multi-chart Management

Helmfile configuration for clusters that manage many Helm releases, with environments, repositories, and dependency ordering defined declaratively in a single helmfile.yaml.

Our approach

Charts are code

A Helm chart is a template codebase. It needs the same practices as application code: consistent naming, meaningful defaults in values.yaml, comments explaining non-obvious values, and tests that validate the rendered manifests. We treat chart authoring with the same discipline as application code.

Sensible defaults, overridable everything

A well-designed values.yaml provides defaults that work for most deployments and allows overriding any value that might differ between environments. Values that are not exposed in the chart's values.yaml require forking the chart to change, which defeats the point. We expose the values that operators will actually need to change.

Version your charts

Chart versioning is separate from application image versioning. We maintain a chart version and an appVersion, increment the chart version when the chart changes, and pin the chart version in ArgoCD or Helmfile so that chart upgrades are explicit and auditable.

Test with chart-testing

The chart-testing (ct) tool lints charts and runs install tests against a real cluster. We include chart-testing in the CI pipeline for chart changes so that a malformed chart template does not reach production.

helm_spec.json
version: [
"Helm 3"
]
registry: [
"ECR OCI",
"Chartmuseum"
]
gitops: [
"ArgoCD",
"Flux"
]
tooling: [
"Helmfile",
"chart-testing",
"helm-docs"
]
infra: [
"Terraform"
]
engineering: [
"Virginia, United States"
]

All engineering work is done by US-based engineers. We do not offshore any development or architecture work.

Part of our container practice

FAQ

Common questions

Virginia · United States

Need Helm chart expertise?

If you need a new chart written or an existing chart improved, reach out and we will discuss the requirements before any work begins.