Pulumi vs. Helm

Pulumi and Helm solve different problems that often appear in the same workflow. Pulumi is an infrastructure as code platform that provisions resources across any cloud or SaaS platform from general-purpose languages. Helm is a package manager for Kubernetes that installs applications onto a cluster from templated YAML charts. Many teams use them together: Pulumi provisions clusters and cloud resources, then installs Helm charts inside the same program.

This page covers what each tool is, a feature-by-feature comparison, the most important differences in detail, the patterns for using Pulumi and Helm together, and the available paths for adopting Pulumi alongside or in place of Helm.

What is Pulumi?

Pulumi is an infrastructure as code platform for provisioning and managing resources across any cloud or SaaS platform. Pulumi programs are written in general-purpose programming languages — Python, TypeScript, JavaScript, Go, .NET, and Java — as well as YAML. The Pulumi Registry covers all major clouds, including first-party native providers that are generated from upstream API schemas for same-day coverage of new platform features. The Pulumi CLI and SDKs are open source under the Apache 2.0 license. Pulumi Cloud is the commercial product that adds managed state, secrets, RBAC, audit logs, policy management, and other features for running Pulumi at organizational scale.

For Helm users, the most relevant entry points are the Pulumi Kubernetes provider and its first-class Helm support through the helm.v4.Chart and helm.v3.Release resources, which let a Pulumi program install Helm charts directly without invoking the helm CLI.

What is Helm?

Helm is a graduated Cloud Native Computing Foundation project that packages Kubernetes applications as charts — directories of templated YAML manifests, a values.yaml file of default inputs, and metadata. The helm CLI renders chart templates using Go template syntax and either installs the resulting manifests into a cluster as a release or prints them to stdout. Charts are distributed through Helm repositories and indexed publicly on Artifact Hub. Helm is open source under Apache License 2.0; the project does not ship a commercial tier.

Detailed comparison

Key differences

Language support and the authoring experience

Helm charts are YAML manifests interleaved with Go templates, and dynamic behavior comes from template helpers and a values.yaml file. The model keeps charts portable across clusters but couples templating logic to text manipulation, which becomes harder to read as charts grow. Pulumi programs are written in general-purpose languages, so authors get typed inputs and outputs, loops, conditionals, classes, IDE features (autocomplete, refactoring, go-to-definition), and the testing frameworks that already exist in those ecosystems. Pulumi also supports YAML for users who prefer a markup format.

Scope of resources managed

Helm manages Kubernetes resources only. A chart can install Custom Resource Definitions, workloads, services, and other manifests into a cluster, but anything outside the cluster — a managed database, a DNS record, an IAM role, a managed Redis instance — needs another tool. Pulumi manages those resources and Kubernetes resources in one program through the Pulumi Registry, which covers AWS, Azure, Google Cloud, Kubernetes, and SaaS platforms like Datadog, Auth0, GitHub, and Cloudflare.

Execution and rollbacks

Helm runs locally as the helm CLI against a Kubernetes cluster, recording each install or upgrade as a numbered release revision stored in the cluster. helm rollback restores a release to a prior revision from that history. Pulumi runs through the local CLI, programmatically through the Automation API, or remotely through Pulumi Deployments. Failed Pulumi updates leave the stack in a partially-updated state; you roll forward by reverting program code and running pulumi up. The two models trade off differently between fast revision-based rollback (Helm) and direct, scriptable control across resources from many providers in one update (Pulumi).

Secrets handling

Pulumi treats secrets as a first-class primitive. Values marked as secrets are encrypted in transit and at rest in the state file, anything derived from a secret is also encrypted, and each stack has its own encryption key. The default encryption provider can be replaced with AWS KMS, Azure Key Vault, Google Cloud KMS, or HashiCorp Vault. Helm has no built-in secrets primitive; secret values are typically pulled from external stores like AWS Secrets Manager, Vault, or sealed-secrets controllers in the cluster, or stored encrypted on disk through community plugins such as helm-secrets.

Policy as code

Pulumi Policies is open source and free. Policies can be written in Python, TypeScript, or Open Policy Agent Rego, and Pulumi Cloud adds centralized management, policy groups, and enforcement across stacks. Pulumi Cloud commercial plans also include Pulumi-maintained policy packs for common compliance frameworks (CIS, PCI DSS, HITRUST, NIST). Helm has no native policy engine; cluster operators typically rely on Kubernetes admission controllers like Kyverno or OPA Gatekeeper to enforce constraints on the manifests a chart installs.

Modularity and reuse

Pulumi’s Component Resources are runtime objects with explicit parent/child relationships, so a component and the resources inside it form a coherent unit in plan output, deletion, and state. Components authored in one language can be consumed from any other supported language by publishing them as a Pulumi Package. Helm composes through chart dependencies, subcharts, and library charts, all of which operate at the YAML manifest level.

Automation API

The Automation API lets a host application drive Pulumi without shelling out to the CLI. Practical uses include embedding stack creation in a SaaS product, building an internal developer platform that provisions environments per team or per branch, generating ephemeral preview environments from CI, and orchestrating cross-cloud deployments where Kubernetes is one step in a larger workflow. Helm’s official SDK is Go-only; other languages typically shell out to the helm CLI.

Using Pulumi and Helm together

Helm and Pulumi are commonly used in combination rather than as substitutes. Pulumi handles cluster provisioning and any non-Kubernetes resources, then installs Helm charts inside the same program — either upstream charts from the broader Helm ecosystem or charts authored in-house. Three patterns cover most production deployments:

1. Orchestrating a production-ready cluster end-to-end. A single Pulumi program creates the cluster (EKS, AKS, or GKE), configures networking and IAM, and installs the operational stack — for example cert-manager, ingress-nginx, and external-dns — through helm.v4.Chart or helm.v3.Release. The EKS guide walks through this pattern end-to-end.
2. Wiring Pulumi outputs into chart values. Resource outputs from elsewhere in the program — a database connection string from aws.rds.Instance, a KMS key ARN, a managed Redis endpoint, a Cloudflare zone ID — flow into a chart’s values input as typed Pulumi outputs. Pulumi resolves the values at deploy time and orders the chart install after its dependencies, so charts can consume infrastructure that did not exist when the program started.
3. Picking the right Helm resource for the job. The Pulumi Kubernetes provider exposes Helm two ways. helm.v4.Chart renders the chart’s templates and registers each resulting Kubernetes object as a typed Pulumi resource — useful when you want every child in plan output, drift detection, and state. helm.v3.Release uses the embedded Helm SDK and produces a real Helm release in the cluster, preserving Helm-specific behaviors like chart hooks, post-rendering, and release history — useful when a chart depends on those behaviors.

The Kubernetes YAML and Helm Charts migration guide covers both resources in depth, including chart values, namespaces, and resource transformations.

When to choose Pulumi vs. Helm

Choose Pulumi when you:

1. Manage infrastructure beyond Kubernetes — cloud accounts, networking, databases, SaaS platforms — and want one tool for all of it.
2. Want to author infrastructure in a general-purpose language with the testing frameworks, package managers, and IDE tooling that already exist in that ecosystem.
3. Need an embeddable SDK (Automation API) to drive deployments from a host application — internal developer platforms, SaaS products, or ephemeral preview environments per pull request.
4. Want built-in secrets encryption, pluggable KMS providers, and per-stack encryption keys without bolting on a separate service.

Choose Helm when you:

1. Publish or consume charts from the broader Helm ecosystem (Artifact Hub, vendor-maintained repositories) and want compatibility with the standard helm CLI.
2. Have a narrowly Kubernetes-scoped workflow where templated YAML and revision-based rollback are a good fit.

Use both when Pulumi handles cluster provisioning and non-Kubernetes resources and you install third-party Helm charts inside that Pulumi program. This is the most common pattern among Pulumi users who already work with Helm.

Adoption: coexistence, conversion, and import

There are several common paths for adopting Pulumi alongside or in place of Helm, and they can be combined:

1. Use Helm charts directly from a Pulumi program. helm.v4.Chart and helm.v3.Release install upstream or in-house charts inside a Pulumi program, with chart values supplied as typed Pulumi inputs. This is the most common adoption pattern.
2. Convert chart manifests to Pulumi resources. helm.v4.Chart already does this implicitly by registering each rendered Kubernetes object as a typed Pulumi resource. For a full migration off Helm, render the chart with helm template and convert the resulting YAML with pulumi convert --from kubernetes to produce native Pulumi code in the language of your choice.
3. Import existing in-cluster resources. pulumi import and the import resource option bring already-provisioned Kubernetes resources under Pulumi management and generate the corresponding code.

For a complete walkthrough including coexistence patterns and chart conversion, see Migrating from Kubernetes YAML or Helm Charts to Pulumi.

Frequently asked questions

Can I use Helm charts in a Pulumi program?

Yes. The Pulumi Kubernetes provider exposes Helm charts as first-class resources through helm.v4.Chart and helm.v3.Release. A Pulumi program can pull charts from any Helm repository (public or private), pass values as typed Pulumi inputs — including outputs from other Pulumi resources — and manage chart lifecycle alongside other infrastructure.

What’s the difference between helm.Chart and helm.Release?

helm.v4.Chart renders chart templates locally and registers each Kubernetes object the chart produces as an individual Pulumi resource, so every child shows up in plan output and state. helm.v3.Release uses the embedded Helm SDK and creates a real Helm release in the cluster, preserving Helm-specific behaviors like chart hooks, post-rendering, and release history. Choose Chart for fine-grained visibility into every rendered resource; choose Release when the chart relies on hooks or other Helm-specific lifecycle behavior.

Can Pulumi replace Helm?

It can, but it doesn’t have to. Pulumi can install Helm charts directly through helm.v4.Chart and helm.v3.Release, so teams that want to keep using upstream charts (cert-manager, ingress-nginx, and others) can do so from inside a Pulumi program. Teams that want to move off Helm entirely can render charts with helm template and convert the YAML with pulumi convert --from kubernetes to produce native Pulumi code.

How do I pass values from other Pulumi resources into a Helm chart?

Supply them on the chart’s values input. The values input accepts the same shape as a values.yaml file, but each leaf can be a typed Pulumi output — a database connection string from aws.rds.Instance, a KMS key ARN, a Cloudflare zone ID, or any other resource output. Pulumi resolves the values at deploy time and orders the chart install after its dependencies.

Does Pulumi support private Helm repositories?

Yes. Both helm.v4.Chart and helm.v3.Release accept repository options for authenticated chart pulls, including username, password, and TLS certificate fields, so charts can be installed from private HTTP repositories or OCI registries.

How do I migrate from Helm to Pulumi?

You have three options that can be combined. Install existing charts directly from a Pulumi program with helm.v4.Chart or helm.v3.Release and migrate incrementally; render a chart with helm template and convert the YAML to native Pulumi code with pulumi convert --from kubernetes; or pulumi import already-provisioned in-cluster resources. See the migration guide for a full walkthrough.

Is Pulumi a package manager like Helm?

No. Pulumi is an infrastructure as code platform, not a Kubernetes package manager. The closest Pulumi concept to a Helm chart is a Component Resource published as a Pulumi Package, which packages a reusable abstraction in any supported language and can be consumed from any other supported language. The Pulumi Registry is the discovery surface for those packages.

Next steps

• Get started with Pulumi on Kubernetes
• Pulumi Kubernetes provider
• Pulumi vs. Kubernetes YAML and DSLs
• Migrating from Kubernetes YAML or Helm Charts to Pulumi