Helm Alternatives in 2026: Kustomize, cdk8s, Pulumi and Not Writing Charts at All

Helm is the package manager for Kubernetes, and it is good at that job: installing an ingress controller, a monitoring stack or a database operator with a few overridden values. It is less comfortable as the way a team deploys its own services, where every chart becomes Go templates wrapped around YAML, values.yaml files grow per environment, whitespace and indentation errors show up only at render time, and the chart has to be updated by hand whenever the service gains a queue or a database.

This list covers five alternatives for deploying your own services, from patching plain YAML to generating the Kubernetes resources from the application itself.

Helm alternatives at a glance

Kubernetes resources from your application code with Encore

Encore is infrastructure from code for TypeScript and Go, with a platform that provisions and deploys into your own AWS or GCP account. When you choose Kubernetes as the compute platform, Encore can provision a new GKE or EKS cluster or deploy to an existing one, and it generates what a chart for your own services would contain: a namespace per environment, a deployment and a cluster service per service with resource requests, limits and health checks, ingress with TLS, and Kubernetes Secrets bound to the service accounts that need them, as described in the Kubernetes docs.

The part a chart cannot see is what the service uses outside the cluster. In Encore, those resources are declared in the same code as the endpoints:

// orders/orders.go
package orders

import (
	"context"

	"encore.dev/pubsub"
	"encore.dev/storage/sqldb"
)

var db = sqldb.NewDatabase("orders", sqldb.DatabaseConfig{
	Migrations: "./migrations",
})

type OrderPlaced struct {
	OrderID int64 `json:"order_id"`
}

var OrderPlacedTopic = pubsub.NewTopic[*OrderPlaced]("order-placed", pubsub.TopicConfig{
	DeliveryGuarantee: pubsub.AtLeastOnce,
})

type CreateParams struct {
	Item string `json:"item"`
}

//encore:api public method=POST path=/orders
func Create(ctx context.Context, p *CreateParams) (*OrderPlaced, error) {
	ev := &OrderPlaced{}
	err := db.QueryRow(ctx,
		`INSERT INTO orders (item) VALUES ($1) RETURNING id`, p.Item).Scan(&ev.OrderID)
	if err != nil {
		return nil, err
	}
	if _, err := OrderPlacedTopic.Publish(ctx, ev); err != nil {
		return nil, err
	}
	return ev, nil
}

The migration in orders/migrations/1_create_orders.up.sql creates the table:

CREATE TABLE orders (
    id BIGSERIAL PRIMARY KEY,
    item TEXT NOT NULL
);

On deploy, the database becomes Cloud SQL or RDS and the topic becomes GCP Pub/Sub or SNS and SQS, and Encore provisions an IAM role for the service, so there is no chart value for a connection string or queue URL to keep in sync. Adding a Pub/Sub subscription or a database is a code change, and the next deploy updates both the cluster and the cloud resources. You can still use kubectl against the cluster, as covered in configuring kubectl, and install third-party charts alongside. Locally, encore run runs the same services with Postgres and an in-memory Pub/Sub, without a local cluster. A coding agent changing a service edits Go or TypeScript.

Best fit: teams on EKS or GKE who want to stop maintaining charts for their own services and have the cloud resources those services use provisioned from the same code.

Kustomize

Kustomize

Kustomize starts from plain, valid Kubernetes YAML in a base directory and applies overlays per environment that patch replica counts, images or resource limits. It is built into kubectl through kubectl apply -k, as described in the Kubernetes documentation, so there is no template language and no extra binary. It does not package or version software for others, and larger differences between environments turn into stacks of patches.

Best fit: teams with a few services and modest environment differences who want to keep plain YAML.

cdk8s

cdk8s

cdk8s, a CNCF project, defines Kubernetes resources as code in TypeScript, Python, Go or Java and synthesizes them to YAML that you apply with kubectl or a GitOps tool. Loops, functions and types replace templates, and constructs package common patterns such as a deployment with a service. It only produces manifests; applying them and managing cloud resources is still separate.

Best fit: teams who want typed, reusable Kubernetes definitions and already have a GitOps or apply pipeline.

Pulumi

Pulumi

Pulumi's Kubernetes provider manages resources directly from TypeScript, Python, Go, C# or Java, applies them with a preview step, and can deploy Helm charts as well. The same program can create the cluster, the database and the deployments, which removes the hand-off between infrastructure and application YAML. In exchange you run a state backend and maintain another program alongside the application.

Best fit: teams that want one typed program for the cluster, cloud resources and deployments.

Terraform

Terraform

Terraform's Kubernetes and Helm providers manage cluster resources and chart releases in HCL, next to the VPC, cluster and databases. It suits teams whose platform is already in Terraform. Frequent application deploys through Terraform plans are slow compared with a deploy tool, so it is common to use it for cluster add-ons and leave application rollouts to something else.

Best fit: platform teams managing cluster-level resources and add-ons alongside the rest of their Terraform.

How to choose

Keep Helm for what it does well, which is installing third-party software. For your own services, Kustomize is the smallest step away from charts, cdk8s and Pulumi add types and code, and Terraform fits cluster add-ons owned by a platform team. If the charts mostly exist to deploy your own services along with the databases and queues they need, generating the Kubernetes resources and the cloud resources from the application with Encore removes the chart instead of rewriting it.

Related guides

• Kubernetes alternatives
• Do you need Kubernetes?
• EKS vs ECS vs Fargate
• Terraform alternatives