Skaffold with Helm: Deploy Charts in Dev and CI (2026)

Skaffold can deploy your Kubernetes applications using Helm charts, which is a powerful combination for both local development and CI/CD pipelines.

Let’s see Skaffold in action with Helm. Imagine you have a simple Helm chart for a basic web application. Your skaffold.yaml might look like this:

apiVersion: skaffold/v2beta29
kind: Config
build:
  artifacts:
    - image: my-web-app
      docker:
        dockerfile: Dockerfile
deploy:
  helm:
    releases:
      - name: my-web-app-release
        chartPath: ./charts/my-web-app
        valuesFiles:
          - ./charts/my-web-app/values.yaml

Here’s the directory structure:

.
├── Dockerfile
├── skaffold.yaml
└── charts/
    └── my-web-app/
        ├── Chart.yaml
        ├── values.yaml
        └── templates/
            ├── deployment.yaml
            └── service.yaml

When you run skaffold dev, Skaffold will:

1. Build your my-web-app Docker image.
2. Package your Helm chart locally.
3. Render the Helm chart using the specified values.yaml.
4. Deploy the rendered Kubernetes manifests to your configured Kubernetes cluster (e.g., Minikube, Docker Desktop, or a remote cluster).
5. Watch for changes in your code or chart. If you modify your application code, Skaffold rebuilds the image and redeploys. If you change your Helm chart, it re-renders and redeploys.

The core problem Skaffold with Helm solves is bridging the gap between your application’s build/packaging and its deployment to Kubernetes, especially when you’re already using Helm for managing Kubernetes resources. It provides a unified workflow for local development and a consistent, repeatable process for CI/CD.

Internally, when Skaffold encounters the helm deployer, it invokes the Helm CLI (or its internal equivalent) for you. It performs the equivalent of helm upgrade --install <release-name> <chart-path> --values <values-file>. Skaffold manages the lifecycle of these Helm releases, tracking what it deployed and enabling rollbacks or redeployments as needed. The build.artifacts section defines how your application images are built, and the deploy.helm section defines how those built images are then used within your Helm chart for deployment. Skaffold intelligently injects the newly built image tag into the Helm values during deployment, ensuring you’re always deploying the latest built artifact.

You can control the Helm deployment extensively. For instance, you can specify a namespace for the release:

deploy:
  helm:
    releases:
      - name: my-web-app-release
        chartPath: ./charts/my-web-app
        namespace: development
        valuesFiles:
          - ./charts/my-web-app/values.yaml

Or you can pass individual Helm values directly:

deploy:
  helm:
    releases:
      - name: my-web-app-release
        chartPath: ./charts/my-web-app
        setValues:
          replicaCount: 2
          image.tag: latest # Skaffold will override this with the actual built tag
        valuesFiles:
          - ./charts/my-web-app/values.yaml

Skaffold also handles multiple releases from different charts or even multiple deployments of the same chart with different configurations. This is particularly useful for microservice architectures where each service might have its own Helm chart.

When running in CI, you’d typically use skaffold run or skaffold build followed by skaffold deploy. skaffold run combines build and deploy. For a CI environment, you might disable local development features like port-forwarding and sync, focusing solely on building the image and deploying the Helm chart to your target cluster.

One aspect that often surprises people is how Skaffold manages the Helm release lifecycle. It doesn’t just run helm install or helm upgrade once. Skaffold keeps track of the deployed Helm release and, upon subsequent runs or code changes, intelligently performs an upgrade operation. If the release doesn’t exist, it will perform an install. This state management is crucial for iterative development and CI/CD, ensuring that you can reliably update your deployed application. Skaffold also allows you to specify hooks within your skaffold.yaml that can execute arbitrary commands before or after deployment, giving you fine-grained control over pre-flight checks or post-deployment validation steps.

The next step is often integrating Skaffold with different CI/CD platforms like Jenkins, GitLab CI, or GitHub Actions to automate this Helm deployment process.