Pulumi Blog: Pulumi Content Team

Best Kubernetes Infrastructure as Code Tools in 2026

Pulumi Content Team — Fri, 14 Aug 2026 00:00:00 +0000

There is no single best Kubernetes infrastructure as code tool, because “Kubernetes IaC” actually spans three different jobs. For provisioning the cluster and its cloud dependencies, Pulumi and Terraform (or OpenTofu) are the strongest general-purpose options. For templating and packaging workloads, Helm and Kustomize dominate. For continuous reconciliation once things are running, Argo CD and Flux lead the GitOps category. The right stack usually combines one tool from each layer, not a single tool that claims to do all three.

What counts as infrastructure as code for Kubernetes?

Kubernetes infrastructure as code work splits into three layers that get conflated constantly, and the confusion is where most tool comparisons go wrong.

The cluster and cloud layer provisions the things Kubernetes itself sits on top of: the managed control plane (EKS, GKE, AKS), node pools, the VPC and subnets, IAM roles, load balancers, and cluster add-ons. Terraform, Pulumi, and cloud-native tools like CloudFormation operate here.

The in-cluster workload layer defines what runs on the cluster once it exists: Deployments, Services, ConfigMaps, CustomResourceDefinitions, and the Helm charts or Kustomize overlays that template them. This is where Helm, Kustomize, and Crossplane’s custom resources live.

The delivery and reconciliation layer keeps what’s declared in Git in sync with what’s actually running on the cluster, continuously, rather than as a one-shot apply. Argo CD and Flux own this layer, and they consume the output of the other two rather than replacing them.

Most real Kubernetes platforms use tools from at least two of these layers together. A team might provision EKS with Terraform, package its application with Helm, and let Argo CD reconcile it continuously. Knowing which layer a tool actually addresses, rather than treating “Kubernetes IaC” as one shopping list, is the first decision that matters.

Pulumi provisions the cluster and the workloads on it in the same language

Pulumi is a general-purpose infrastructure as code platform that supports Python, TypeScript, Go, C#, Java, and YAML, backed by a dedicated Kubernetes provider that covers both the cluster layer and the workload layer in the same program. A single Pulumi stack can create an EKS cluster, its VPC and node groups, and the Deployments and Services that run inside it, with full dependency tracking between the two: Pulumi knows a Deployment depends on a cluster that does not exist yet, and sequences accordingly.

For workloads, Pulumi offers two distinct ways to work with Helm charts. kubernetes.helm.v4.Chart renders a chart client-side via helm template into individual resources, giving full Pulumi state, diffing, and policy visibility into every object a chart creates, at the cost of not producing a real Helm release. kubernetes.helm.sh/v3.Release installs through the embedded Helm SDK instead, producing an actual release with hooks, and can even import releases installed by the Helm CLI. Teams pick based on whether they need release semantics or resource-level visibility; Pulumi’s documentation is upfront that these are genuinely different tradeoffs, not that one supersedes the other. Kustomize overlays are supported directly through kubernetes.kustomize.v2.Directory.

As of the v4 provider, Server-Side Apply is the default for managing resources, which lets Pulumi share ownership of an object with other controllers safely instead of overwriting whatever they changed. Await and readiness logic (waiting for a Deployment’s rollout to finish before considering it “done”) is handled natively for common resource types, with skipAwait and waitFor escape hatches for anything unusual. As Pulumi engineer Bryce Lampe put it when the improved await logic shipped, “One of the advantages of using Pulumi to manage Kubernetes resources is that it natively and intuitively handles this problem of readiness and dependencies,” which matters more than it sounds: a naive apply-and-move-on model is a common source of flaky CI in Kubernetes pipelines.

Pulumi also plugs into an existing GitOps workflow rather than requiring you to replace it: the Kubernetes provider’s renderYamlToDirectory option renders manifests to disk instead of applying them directly, a pattern Pulumi’s own provider documentation calls out as an Argo CD Config Management Plugin use case. The provider currently labels this a developer-preview beta feature, disabled by default, so treat it as a bridge worth piloting rather than a settled default for a GitOps handoff. For CRDs, crd2pulumi generates strongly typed SDKs from CRD definitions, so a custom resource gets the same autocomplete and type-checking as a built-in one. Teams running Pulumi as a standing service inside the cluster can use the Pulumi Kubernetes Operator to drive stack updates from in-cluster custom resources.

The honest tradeoff: Pulumi is a commercial platform with an open-source core, and a team fully committed to a YAML-only, kubectl-native workflow will find a general-purpose language layer to be more machinery than it needs for a handful of static manifests. Materialize, which runs multi-region Amazon EKS clusters, adopted Pulumi from day one to manage that complexity in Python, after finding that tools like Terraform required developers to learn a proprietary configuration language and created unnecessary friction; new engineers reach their first meaningful contribution in a week rather than the month the team estimates it would otherwise take. A team with one cluster and no cross-region variation may not have that problem to solve.

Terraform and OpenTofu remain the default for the cluster layer, with real friction at the workload layer

Terraform (and its community-governed fork, OpenTofu, since HashiCorp’s Business Source License change) is still the most widely deployed way to provision the cluster itself: the AWS, Google, and Azure providers are mature, and the Kubernetes and Helm providers (currently at 3.2.1 and 3.2.0 respectively) let the same HCL codebase reach into the cluster afterward. That reach is also where the friction shows up. Terraform plans at plan time, before it has ever talked to a live cluster, so it frequently cannot know what a CRD’s schema actually looks like until it’s already been applied; this is a well-documented source of “plan differs from apply” surprises when CRDs and their consumers live in the same configuration. The common workaround is a two-stage apply, provisioning the cluster in one Terraform run and the workloads that depend on its CRDs in a second, which works but adds operational ceremony that a single-language, single-run tool doesn’t need. Our practical guide to Terraform and Kubernetes walks through where that friction shows up day to day and how a general-purpose language changes the testing and CRD story.

HCL itself is also a genuine limit at the workload layer: templating a Deployment’s environment variables across ten similar services means either heavy use of for_each and dynamic blocks, or accepting a lot of copy-pasted HCL, because HCL was designed as a configuration language rather than a general-purpose one with functions and reusable abstractions. None of this makes Terraform a poor choice for the cluster layer, where it remains a defensible default with a huge ecosystem of examples and modules. It’s a reason many Terraform shops hand workload templating off to Helm rather than fighting the Kubernetes provider for it.

Helm is the default packaging format, and now defaults to safer applies

Helm is the de facto package manager for Kubernetes: charts bundle a set of manifests with a templating layer and values files, and the public Artifact Hub ecosystem aggregates charts from vendors and the community, so most common software (databases, ingress controllers, observability stacks) has a chart available, official or otherwise. Helm 4 made Server-Side Apply the default instead of the old three-way merge against a stored last-applied-configuration annotation, which reduces a class of drift bugs that plagued Helm 3 installs sharing objects with other controllers. It also added WASM-based plugins and an experimental v3 chart format.

Helm’s real weakness is templating itself: charts are YAML run through Go’s text/template engine, which has no real type system, awkward conditionals, and error messages that point at rendered output rather than the source template. Values files also tend to sprawl as a chart tries to expose every possible customization, and a chart author’s defaults are a starting point you inherit rather than infrastructure you designed. Helm is excellent for consuming someone else’s well-maintained chart and mediocre as an authoring experience for your own complex, multi-service application, which is exactly why tools like Pulumi and Kustomize exist to sit on either side of it.

Kustomize is the built-in choice for environment-specific overlays

Kustomize ships inside kubectl and takes a patch-based approach instead of a templating one: you write a base set of plain YAML manifests, then layer environment-specific overlays (a different replica count for staging, a different image tag for production) that patch the base without touching it. That model avoids Helm’s templating-language problem entirely, at the cost of being far less expressive for anything beyond structural changes to existing YAML: generating a resource conditionally, or computing a value, is awkward or impossible.

The practical friction is version lag: the Kustomize binary bundled inside a given kubectl release trails the standalone Kustomize CLI’s releases, so a team relying on kubectl’s bundled version can be several minor versions behind what’s documented upstream. Teams that hit this usually install the standalone kustomize binary directly rather than depend on kubectl’s copy.

Crossplane turns cloud resources into Kubernetes-native APIs

Crossplane, which graduated to a CNCF top-level project on November 6, 2025, takes a fundamentally different approach: instead of a CLI that applies configuration, cloud resources become managed resources, native Kubernetes custom resources that a control-plane cluster reconciles continuously, overriding drift back to the desired state, the same way Kubernetes reconciles a Deployment. This is a genuinely different mental model from Terraform, Pulumi, or Helm, and it’s the right one for platform teams building a self-service layer where application teams request infrastructure (an S3 bucket, a Postgres instance) through the same kubectl apply and RBAC model they already use for everything else.

Crossplane v2 removed native patch-and-transform composition and introduced namespaced Composite Resources (XRs) alongside an alpha “Operations” feature for one-off imperative tasks. Claims, the v1 abstraction that let application teams request infrastructure without touching the (cluster-scoped) XR directly, were already namespaced; what changes in v2 is that they aren’t supported by the new namespaced or cluster-scoped XRs at all, and survive only when an XRD opts into the LegacyCluster scope for backward compatibility. Teams on Crossplane v1 migrating to v2 should plan to move application teams onto namespaced XRs directly rather than assume claims carry forward as-is. It also means Crossplane’s learning curve is steeper than a CLI-based tool: composing custom APIs out of managed resources requires understanding Crossplane’s own compositional model in addition to the cloud provider’s resource shapes. Teams that don’t need a self-service internal platform, and just want to provision infrastructure for their own team, usually find Terraform or Pulumi a faster path to the same cloud resources.

Argo CD and Flux reconcile what’s running, and assume something else already authored it

Argo CD (CNCF graduated December 2022, now at 3.5.1) and Flux (CNCF graduated November 2022, now at 2.9.4) are the two dominant GitOps controllers: both watch a Git repository and continuously compare the cluster’s actual state against what’s declared there, surfacing drift as it appears and correcting it automatically when self-healing is enabled, rather than waiting for the next scheduled apply. This is the delivery layer from the three-layer breakdown above, and it’s genuinely complementary to, not competitive with, Terraform, Pulumi, Helm, and Kustomize: Argo CD and Flux consume rendered manifests or chart references, they don’t generate cloud infrastructure or author application configuration themselves.

The CNCF’s 2025 annual survey found that GitOps adoption tracks organizational maturity closely: 58% of self-identified “cloud native innovators” use GitOps extensively, compared to 23% of “adopters” earlier in their journey, which suggests GitOps is a practice teams grow into rather than a day-one requirement. Neither Argo CD nor Flux replaces the need for a provisioning tool at the cluster layer; a common and reasonable pattern is Terraform or Pulumi for the cluster and cloud dependencies, then Argo CD or Flux reconciling the workloads that run on it, with Pulumi’s renderYamlToDirectory option (currently a developer-preview beta feature) designed to feed that second stage.

cdk8s and kro bring code and native APIs to workload definitions

cdk8s applies the AWS CDK model to Kubernetes manifests: you define Deployments, Services, and other objects in TypeScript, Python, Java, or Go, and cdk8s synthesizes plain YAML at build time, which plays nicely with existing GitOps pipelines since the output is still just manifests. It’s a narrower tool than Pulumi in scope, generating Kubernetes YAML only rather than also provisioning the cluster and cloud resources around it, and it has no equivalent to Pulumi’s state-tracked diffing or drift detection since it only emits manifests for something else to apply. The core cdk8s library is stable on the 2.x line; the higher-level cdk8s+ construct libraries are versioned and released separately per supported Kubernetes version.

kro takes Crossplane’s “infrastructure as a native API” idea and generalizes it: it composes any native Kubernetes resource as well as any CRD installed in the cluster, Crossplane’s managed resources included, into a new custom API that platform teams expose to their users. kro recently moved into the kubernetes-sigs organization as a SIG Cloud Provider subproject, which is a credibility signal, but it remains genuinely alpha (v1alpha1 APIs, releases still in the 0.7 to 0.9.3 range) and is not yet a CNCF top-level project. It’s worth watching and piloting, not yet a safe default for anything you can’t easily rebuild.

A handful of other projects are worth knowing about without needing a full section: Timoni applies CUE’s type system to Kubernetes packaging as a Helm alternative; KubeVela builds an application-delivery abstraction on top of the Open Application Model; Tanka uses Jsonnet for templated manifests in the Grafana Labs ecosystem; and Ansible’s Kubernetes modules remain common in shops that already standardized on Ansible for configuration management generally.

How the tools compare across cluster, workload, and delivery layers

Reconciliation model is the dimension most roundups leave out, and it matters as much as authoring language: a one-shot apply tool and a continuously reconciling controller solve different problems even when they touch the same YAML.

Tool	Authoring language	Provisions cloud + cluster?	Reconciliation model	Maturity / governance	Best fit
Pulumi	Python, TypeScript, Go, C#, Java, YAML	Yes	One-shot apply (`pulumi up`), continuous via Kubernetes Operator	Open-source core, commercial platform	Teams wanting one codebase for cluster + workloads
Terraform / OpenTofu	HCL	Yes	One-shot apply	Terraform: HashiCorp/IBM; OpenTofu: Linux Foundation	Cluster and cloud provisioning, HCL-standardized shops
Helm	YAML + Go templates	No (workload only)	One-shot install/upgrade	CNCF graduated	Packaging and consuming shared application charts
Kustomize	YAML (patch-based)	No (workload only)	One-shot apply	Built into `kubectl`, part of Kubernetes SIG-CLI	Environment overlays on plain manifests
Crossplane	Kubernetes YAML / CRDs	Yes (via managed resources)	Continuous reconciliation	CNCF graduated Nov 2025	Self-service internal platforms
Argo CD	Kubernetes YAML (consumed)	No (delivery only)	Continuous reconciliation	CNCF graduated	GitOps delivery, UI-driven ops
Flux	Kubernetes YAML (consumed)	No (delivery only)	Continuous reconciliation	CNCF graduated	GitOps delivery, GitOps Toolkit composability
cdk8s	TypeScript, Python, Java, Go	No (workload only)	One-shot synth to YAML	Stable 2.x core, CNCF Sandbox	Code-first manifest generation feeding existing GitOps
kro	Kubernetes YAML / CRDs	Yes (composes existing CRDs)	Continuous reconciliation	Alpha, `kubernetes-sigs` subproject	Composing custom platform APIs, early adopters

The same task in Terraform and Pulumi

The clearest way to see the practical difference is the same job in both: create a managed EKS cluster and deploy a single workload onto it.

Terraform provisions the cluster with the AWS provider, then reaches into it with the Kubernetes provider in the same configuration:

resource "aws_eks_cluster" "main" {
 name = "app-cluster"
 role_arn = aws_iam_role.eks.arn

 vpc_config {
 subnet_ids = aws_subnet.private[*].id
 }
}

provider "kubernetes" {
 host = aws_eks_cluster.main.endpoint
 cluster_ca_certificate = base64decode(aws_eks_cluster.main.certificate_authority[0].data)
 token = data.aws_eks_cluster_auth.main.token
}

resource "kubernetes_deployment" "app" {
 metadata {
 name = "app"
 }

 spec {
 replicas = 3

 selector {
 match_labels = { app = "app" }
 }

 template {
 metadata {
 labels = { app = "app" }
 }

 spec {
 container {
 name = "app"
 image = "myorg/app:1.4.0"
 }
 }
 }
 }
}

Pulumi, in TypeScript, does the same two-stage job with the dependency between them tracked automatically, rather than requiring a separate provider block wired up by hand:

import * as aws from "@pulumi/aws";
import * as eks from "@pulumi/eks";
import * as k8s from "@pulumi/kubernetes";

const cluster = new eks.Cluster("app-cluster", {
 instanceType: "t3.medium",
 desiredCapacity: 3,
});

const provider = new k8s.Provider("k8s-provider", {
 kubeconfig: cluster.kubeconfig,
});

const app = new k8s.apps.v1.Deployment("app", {
 spec: {
 replicas: 3,
 selector: { matchLabels: { app: "app" } },
 template: {
 metadata: { labels: { app: "app" } },
 spec: {
 containers: [{ name: "app", image: "myorg/app:1.4.0" }],
 },
 },
 },
}, { provider });

Both are legitimate. Terraform’s version separates concerns across a provider block and requires knowing the Kubernetes provider’s HCL shape for a Deployment resource; Pulumi’s version is fewer moving pieces because the cluster’s kubeconfig flows directly into the next resource as a normal object reference, and the whole thing can be unit tested with the same test framework used for the application code it deploys.

How to choose a Kubernetes IaC tool

Most teams end up combining tools across the three layers rather than picking one. Working through these five steps in order avoids the most common mistake, which is picking a workload-layer tool (like Helm) and then trying to stretch it to also provision the cluster.

Decide who provisions the cluster and its cloud dependencies (VPC, node pools, IAM), and pick a cluster-layer tool for that job: Pulumi or Terraform/OpenTofu for most teams, or a cloud-native tool if you’re single-cloud and want the tightest console integration.
Decide how workloads get packaged. If you’re consuming other people’s software (databases, ingress controllers, observability agents), Helm’s chart ecosystem is hard to beat. If you’re authoring your own application manifests, Kustomize overlays or a code-first approach (Pulumi, cdk8s) usually scale better than hand-templated Helm charts.
Decide whether you need a self-service internal platform. If application teams should be able to request infrastructure through kubectl apply without touching Terraform or Pulumi directly, Crossplane or kro are worth the steeper learning curve. If your platform team is the only one touching infrastructure, you likely don’t need this layer yet.
Decide whether you need continuous reconciliation or a one-shot apply is enough. A small team deploying a few times a week can live with terraform apply or pulumi up in CI. A team running many clusters, or one where configuration drift is a recurring incident cause, benefits from Argo CD or Flux catching and correcting drift automatically.
Match the result to your team’s actual skills, not the tool with the most GitHub stars. A team of application engineers who already write Python or TypeScript daily will move faster in a tool that speaks their language than in a new DSL, and a platform team that already lives in YAML and kubectl will get more value from Kustomize and Argo CD than from introducing a new language to learn.

Is Terraform or Pulumi better for Kubernetes?

Neither is universally better; the choice depends on what happens after the cluster exists. Terraform’s ecosystem of provider modules and examples is larger for pure cluster provisioning, and HCL is a smaller thing to learn than a full programming language. Pulumi’s advantage shows up once workloads enter the picture: because the cluster and its workloads live in the same general-purpose language, dependencies between them are tracked automatically, the same testing and CI tools used for application code apply to infrastructure code, and CRD-heavy workloads avoid the plan-time unknowns that come from HCL not having talked to a live cluster yet. Teams already standardized on HCL across their infrastructure will find less reason to switch; teams that want one codebase and one language for cluster and workloads together tend to prefer Pulumi.

What are the alternatives to Helm?

Kustomize is the most common alternative for teams that find Helm’s templating language awkward, trading some expressiveness for patch-based simplicity on plain YAML. cdk8s replaces Helm’s templating with a real programming language that synthesizes YAML at build time. Pulumi can render Helm charts directly through kubernetes.helm.v4.Chart for full state visibility, or install them as genuine Helm releases through kubernetes.helm.sh/v3.Release, without requiring a separate templating tool at all. Timoni applies CUE’s type system as a more strictly typed alternative to Helm’s Go templates. None of these fully replace Helm’s chart ecosystem for consuming third-party software; they’re strongest for authoring your own application’s manifests.

How do you manage a managed Kubernetes service like EKS, GKE, or AKS as code?

Managed Kubernetes services expose the control plane as a cloud resource like any other, so the tools that provision it are the same cluster-layer tools used for the rest of your cloud footprint: Terraform, OpenTofu, or Pulumi, using each cloud’s native provider (aws_eks_cluster, google_container_cluster, azurerm_kubernetes_cluster, or Pulumi’s equivalent resources and the higher-level @pulumi/eks package). The node pools, VPC, subnets, and IAM roles the control plane depends on get provisioned in the same run. What happens after the cluster exists, deploying and reconciling workloads, is a separate decision covered by the workload and delivery layers above, not something the cluster-provisioning tool needs to also own.

Is GitOps a replacement for infrastructure as code?

No. GitOps tools like Argo CD and Flux reconcile what’s already declared in Git against what’s running on the cluster; they don’t generate that declaration or provision the cloud infrastructure underneath it. A GitOps workflow still needs something upstream producing the manifests it reconciles, whether that’s Helm charts, Kustomize overlays, cdk8s output, or Pulumi’s renderYamlToDirectory rendering a stack to disk. GitOps is a delivery and drift-correction practice layered on top of infrastructure as code, not a substitute for the provisioning step itself.

Do you need Kubernetes-specific IaC tooling at all?

Not always. A team running a single small cluster with a handful of stable workloads can reasonably manage everything with plain kubectl apply against version-controlled YAML and skip templating tools entirely; the complexity Helm, Kustomize, and Crossplane solve only shows up once you have multiple environments, multiple similar services, or multiple teams needing self-service access. The honest signal that it’s time to adopt tooling is repetition: the same YAML copied and hand-edited across environments, or the same cluster-provisioning steps run manually more than once, is worth automating before it causes an incident.

Which Kubernetes IaC tool should you choose?

There’s no single winner because “Kubernetes IaC” spans three different jobs. Most production setups combine a cluster-layer tool (Pulumi or Terraform), a workload-layer tool (Helm, Kustomize, or a code-first option), and often a delivery-layer tool (Argo CD or Flux) once the team is large enough to need continuous reconciliation. The five-step framework above is a better starting point than any single ranked list, because the right combination depends on your team’s language preferences, how many environments you run, and whether you need to expose infrastructure to other teams as a self-service API.

Frequently asked questions

Does Pulumi replace Helm and Kustomize?

Not entirely. Pulumi can render Helm charts and apply Kustomize overlays directly from its Kubernetes provider, so a team can consume the existing Helm and Kustomize ecosystems from inside a Pulumi program rather than needing a separate CLI step. For authoring new manifests from scratch, Pulumi’s general-purpose language is an alternative to writing Helm templates or Kustomize bases, but plenty of teams use Pulumi for the cluster layer while still authoring workload manifests as Helm charts.

Can you use more than one of these tools together?

Yes, and most real deployments do. A common combination is a cluster-layer tool (Terraform or Pulumi) for the control plane and cloud dependencies, a workload-layer tool (Helm or Kustomize) for packaging what runs on it, and a delivery-layer tool (Argo CD or Flux) for continuous reconciliation. The three-layer breakdown at the top of this post exists precisely because these tools are usually complementary rather than competing for the same job.

Is Crossplane a replacement for Terraform or Pulumi?

Not for most teams. Crossplane’s strength is exposing infrastructure as native Kubernetes APIs so application teams can self-serve through kubectl, which is a platform-engineering pattern, not a general substitute for a cluster-provisioning tool. A platform team still typically uses Terraform or Pulumi to provision the Crossplane control-plane cluster itself and configure Crossplane’s provider credentials.

Why did the CNCF’s 2025 survey findings matter for this comparison?

The CNCF’s 2025 Annual Cloud Native Survey found 82% of container users now run Kubernetes in production, up from 66% in 2023, and 47% cited cultural change, more than training or security, as the top adoption challenge. Those numbers matter for tool choice because Kubernetes adoption has moved well past early adopters into mainstream production use, which means the tooling decision is increasingly about fitting an existing team’s skills and processes rather than picking a tool for a greenfield experiment.

Where to go next

For the cluster-provisioning layer specifically, the Pulumi Kubernetes getting-started guide walks through creating a cluster and deploying a first workload. The Pulumi vs. Helm comparison and Pulumi vs. Crossplane comparison go deeper on the workload- and platform-layer tradeoffs summarized here, and the Pulumi vs. Terraform comparison covers the cluster-layer decision in more depth than a roundup can. If your infrastructure spans more than Kubernetes, our broader infrastructure as code tools roundup compares the cloud-provisioning landscape beyond the cluster.

For running AI workloads specifically on Kubernetes, our companion piece on provisioning and governing infrastructure for AI agents covers GPU-aware scheduling, credentials, and where policy as code and Pulumi’s Neo agent fit into that picture. And if a self-service platform for other teams is the eventual goal, Pulumi’s IDP documentation covers the components, templates, and policy guardrails that turn infrastructure code into something other teams can safely consume without needing to understand Pulumi themselves.

Whatever combination you land on, the layer breakdown here is the durable part: know whether you’re solving a cluster problem, a workload problem, or a reconciliation problem before you compare tools, because most of the disagreement in “best Kubernetes IaC tool” debates comes from comparing tools that were never solving the same problem in the first place.

Terraform and Kubernetes: A Practical Guide for 2026

Pulumi Content Team — Fri, 07 Aug 2026 00:00:00 +0000

Yes, Terraform can manage Kubernetes: the official hashicorp/kubernetes provider lets you declare Deployments, Services, and other objects as HCL resources, and community providers like kubectl fill in the gaps. It works well for many teams. The friction shows up around two well-documented limits — provider ordering and plan-time API access — and around testing, where a general-purpose language changes what’s possible.

That friction matters more in 2026 than it did a few years ago. Kubernetes infrastructure now sits next to AI-driven engineering workflows: agents that propose changes, run previews, and open pull requests need infrastructure code they can read, test, and reason about with the same tools they use for application code. A cluster definition written in HCL and a workload definition written in YAML are both harder for an agent — and a person — to unit test, refactor, or type-check than the equivalent in TypeScript, Python, or Go.

This guide is about the operating model for Kubernetes infrastructure: how the cluster, the platform layer, and the workloads on top of it get provisioned, tested, and shipped. It’s a different question from “should I write my Kubernetes manifests in YAML, HCL, or a real language,” which we cover in detail in YAML, Terraform, or Pulumi: what’s the smart choice for deployment automation with Kubernetes? Read that post first if you’re deciding how to author manifests; read this one for the wider workflow — provisioning, testing, policy, and where AI agents fit.

How does Terraform manage Kubernetes today?

The hashicorp/kubernetes provider (current release v3.2.1, requiring Terraform 1.0.0 or later) is the primary path, and teams typically combine it with one or two others depending on what they’re deploying:

Approach	What it’s for	Notes
Typed resources (`kubernetes_deployment_v1`, `kubernetes_service_v1`, etc.)	Core, well-known object types	Full HCL validation and typed attributes for the objects the provider models explicitly
`kubernetes_manifest`	Custom resources or object types the provider doesn’t model yet	Requires live API access during `terraform plan`, which shapes how it can be sequenced (details)
`hashicorp/helm` provider	Installing Helm charts	Wraps the Helm SDK; chart internals aren’t individually visible to Terraform’s plan/diff
Community `kubectl` provider (`alekc/kubectl`, a maintained fork of `gavinbunney/kubectl`)	Applying free-form YAML manifests	Common workaround for `kubernetes_manifest`’s plan-time requirement; newer versions support Terraform 1.10+ ephemeral resources so secrets don’t have to land in state

What are the hard parts of managing Kubernetes with Terraform?

Two limitations show up often enough in practice that HashiCorp documents them directly, and they’re worth quoting rather than paraphrasing:

Plan-time API access. From the kubernetes_manifest resource docs: “This resource requires API access during planning time. This means the cluster has to be accessible at plan time and thus cannot be created in the same apply operation. We recommend only using this resource for custom resources or resources not yet fully supported by the provider.” In practice this means you can’t create a cluster and populate it with kubernetes_manifest resources in a single terraform apply — the cluster has to exist and be reachable before Terraform can even plan the manifest resources.
Provider-credential ordering. From the provider’s own index documentation: “When using interpolation to pass credentials to the Kubernetes provider from other resources, these resources SHOULD NOT be created in the same Terraform module where Kubernetes provider resources are also used. This will lead to intermittent and unpredictable errors which are hard to debug and diagnose. The root issue lies with the order in which Terraform itself evaluates the provider blocks vs. actual resources.” HashiCorp’s prescribed fix, also verbatim: “The most reliable way to configure the Kubernetes provider is to ensure that the cluster itself and the Kubernetes provider resources can be managed with separate apply operations. Data-sources can be used to convey values between the two stages as needed.”

Both are solvable — split cluster provisioning and workload deployment into separate applies (or separate Terraform workspaces/modules), and pass values between them with data sources or remote state. It’s a real pattern, and plenty of teams run it in production. It does mean two-stage pipelines and extra state plumbing wherever a cluster and its workloads are managed together.

At a glance, here’s how Terraform’s Kubernetes provider and Pulumi differ on the points that matter most for cluster-plus-workload management:

	Terraform (`hashicorp/kubernetes`)	Pulumi
Cluster and workloads in one run	Requires a two-stage apply or separate modules	Single program, single `pulumi up`
Custom resources / CRDs	`kubernetes_manifest` needs live API access at plan time	Typed CRD support generated from cluster schema, no plan-time cluster requirement
Provider-credential ordering	Documented pitfall; HashiCorp recommends separate applies	Ordinary language-level dependency, resolved by the runtime
Testing	Native `.tftest.hcl` tests with `mock_provider` (GA since Terraform 1.7), in a separate test language	Standard test frameworks (pytest, Jest, Go testing, etc.) in the same suite as application code, plus `pulumi preview`
Language	HCL only (community `kubectl` provider as a workaround for free-form YAML)	Python, TypeScript, Go, C#, Java, or YAML/HCL

What changes when Kubernetes infrastructure is written in a general-purpose language?

Pulumi’s Kubernetes provider is generated directly from the Kubernetes OpenAPI specifications (current version v4.33.0), so it stays current with the Kubernetes API surface automatically, and it runs inside a single Pulumi program in TypeScript, Python, Go, C#, Java, or YAML. Because the cluster resource and the workloads that depend on it are ordinary values in that program, sequencing them doesn’t require splitting into separate applies — Pulumi’s dependency graph resolves the ordering, and Server-Side Apply (the provider’s default since v4.0) handles upserts consistently across resource types.

The provider also has built-in await logic for common object types — it knows a Deployment isn’t “done” until its replicas are available, a Service isn’t ready until it has endpoints or a load balancer ingress, and a Pod isn’t ready until its readiness probe passes. That behavior is tunable with annotations: pulumi.com/skipAwait, pulumi.com/timeoutSeconds, the experimental pulumi.com/waitFor (supports a JSONPath value check, a JSONPath existence check, condition=Synced, or a JSON array of conditions), and pulumi.com/deletionPropagationPolicy.

For Helm, there are three options with different tradeoffs:

Resource	How it works	Best for
`helm.sh/v4.Chart`	Renders the chart client-side and manages each object as a distinct Pulumi resource; implemented as a component, so it works the same way across every Pulumi language, including Java and YAML; supports OCI registries	Teams that want every rendered object visible in the resource graph, diffable, and enforceable by policy
`helm.sh/v3.Chart`	Same client-side rendering approach, the previous major version	Existing usage; Pulumi has said it expects to deprecate this in a future release in favor of `v4.Chart`
`helm.sh/v3.Release`	Embeds the real Helm SDK and creates an actual Helm release, including hooks; can import chart releases installed via the Helm CLI	Charts that rely on Helm hooks, or environments already managed with the Helm CLI

The practical distinction: Chart resources give you a resource graph you can diff and enforce policy against, one object at a time, but no Helm hooks and no CLI interop. Release gives you full Helm behavior, but policy enforcement can’t reach into the resources a Helm release creates.

For CRDs, crd2pulumi reads a CustomResourceDefinition’s OpenAPI schema and generates strongly typed classes in your language, so custom resources get IDE autocompletion and compile-time checking instead of the untyped apiextensions.CustomResource path. For plain manifests and Kustomize output, current guidance favors the versioned APIs — yaml/v2.ConfigFile, yaml/v2.ConfigGroup, and kustomize/v2.Directory — over their unversioned predecessors.

How do you manage Kubernetes infrastructure with Pulumi?

A typical workflow for standing up an application on Kubernetes with Pulumi looks like this:

Install the Pulumi CLI and create a new project with pulumi new kubernetes-typescript (or the -python, -go, -csharp, or -java variant for your language).
Configure the target cluster context — either point Pulumi at an existing kubeconfig, or provision the cluster itself in the same program using your cloud provider’s Pulumi provider (EKS, AKS, GKE, and so on).
Import the Kubernetes provider package for your language and instantiate a Provider resource if you need a non-default context or credentials.
Define your workloads as typed resources — a Deployment, a Service, a ConfigMap — using the same objects, loops, and functions you’d use in any other program in that language.
For existing Helm charts, use helm.sh/v4.Chart to render and manage the chart’s resources individually, or helm.sh/v3.Release if you need full Helm hook support.
For CustomResourceDefinitions, run crd2pulumi against the CRD’s schema to generate typed classes, then instantiate custom resources the same way as built-in types.
Run pulumi preview to see a diff of what will change, and pulumi up to apply it — Server-Side Apply and the provider’s await logic handle upsert and readiness semantics automatically.
Wire the stack into CI by running pulumi preview on pull requests and pulumi up on merge, using the same pipeline and secrets store your application code already uses.

Here’s step 4 in TypeScript, deploying a Deployment and a Service together in one program:

import * as k8s from "@pulumi/kubernetes";

const appLabels = { app: "my-service" };

const deployment = new k8s.apps.v1.Deployment("my-service", {
 spec: {
 selector: { matchLabels: appLabels },
 replicas: 3,
 template: {
 metadata: { labels: appLabels },
 spec: {
 containers: [{
 name: "my-service",
 image: "my-registry/my-service:1.4.0",
 ports: [{ containerPort: 8080 }],
 }],
 },
 },
 },
});

const service = new k8s.core.v1.Service("my-service", {
 spec: {
 selector: appLabels,
 ports: [{ port: 80, targetPort: 8080 }],
 type: "LoadBalancer",
 },
});

export const serviceIp = service.status.loadBalancer.ingress[0].ip;

And the same shape in Python:

import pulumi
import pulumi_kubernetes as k8s

app_labels = {"app": "my-service"}

deployment = k8s.apps.v1.Deployment(
 "my-service",
 spec=k8s.apps.v1.DeploymentSpecArgs(
 selector=k8s.meta.v1.LabelSelectorArgs(match_labels=app_labels),
 replicas=3,
 template=k8s.core.v1.PodTemplateSpecArgs(
 metadata=k8s.meta.v1.ObjectMetaArgs(labels=app_labels),
 spec=k8s.core.v1.PodSpecArgs(containers=[
 k8s.core.v1.ContainerArgs(
 name="my-service",
 image="my-registry/my-service:1.4.0",
 ports=[k8s.core.v1.ContainerPortArgs(container_port=8080)],
 ),
 ]),
 ),
 ),
)

service = k8s.core.v1.Service(
 "my-service",
 spec=k8s.core.v1.ServiceSpecArgs(
 selector=app_labels,
 ports=[k8s.core.v1.ServicePortArgs(port=80, target_port=8080)],
 type="LoadBalancer",
 ),
)

pulumi.export("service_ip", service.status.load_balancer.ingress[0].ip)

Because deployment and service are ordinary values in the program, Pulumi resolves their dependency order automatically — there’s no separate apply stage to sequence by hand, even if the cluster itself were provisioned earlier in the same program.

How do you test Kubernetes infrastructure code before it ships?

Testing is one of the sharpest differences between the two approaches, and it’s worth being precise about what each side actually offers:

Capability	Terraform	Pulumi
Unit tests (no cloud calls)	`.tftest.hcl` files with `command = plan`, plus `mock_provider` (GA since v1.7.0) for provider-free assertions	`pulumi.runtime.setMocks` (TypeScript), `pulumi.runtime.set_mocks` (Python), or `pulumi.WithMocks` (Go), run inside the same test framework as application code
Integration tests (real infra)	`.tftest.hcl` files with `command = apply` against a real or ephemeral environment	Automation API drives real preview/up/destroy cycles against ephemeral stacks, orchestrated from your own code
Test language	A second, declarative, test-specific language (`.tftest.hcl`)	The same language and test runner already used for application code — Jest, pytest, `go test`, xUnit
Policy enforcement	Sentinel or OPA/Rego, evaluated against the plan	Pulumi Policies (policy packs in TypeScript/JavaScript or Python) or OPA/Rego via `pulumi-policy-opa`, evaluated against the resource graph of a stack written in any Pulumi language

terraform test with mock_provider is a legitimate, GA capability, and teams that have standardized on HCL testing patterns can write real infrastructure-free unit tests with it. The practical difference isn’t “Terraform can’t test” — it’s that Terraform tests live in a separate language and toolchain from the application code they support, while Pulumi’s tests run in the same Jest, pytest, or go test suite a team already runs on every commit. Because Kubernetes objects created through Chart, ConfigGroup, or CustomResource resources appear individually in Pulumi’s resource graph, Pulumi Policies apply to them the same way they’d apply to a cloud resource — there’s no separately named “Kubernetes policy” product, only the same policy-as-code engine applied to whatever’s in the graph.

Where do AI agents fit into Kubernetes infrastructure management?

An AI agent operating on infrastructure needs to read the current state, propose a change, preview its effect, and — ideally — get that change reviewed like any other pull request. That loop is much easier for an agent to execute reliably against a TypeScript or Python program than against HCL or raw YAML, because the agent can use the same static analysis, type checking, and test suite a developer would use, rather than reasoning about a domain-specific configuration language from scratch.

Pulumi Neo is built for exactly this loop: an infrastructure agent with organizational context, policy guardrails, and human-in-the-loop approvals, working inside the same preview/policy/apply cycle described above. We cover the fuller picture of provisioning and governing agent workloads on Kubernetes — GPU-aware scheduling, session state, and the security boundary around what an agent is allowed to touch — in How to Run AI Agents on Kubernetes with Pulumi.

When is Terraform still the right choice for Kubernetes?

Fair comparisons cut both ways, and there are good reasons a team keeps using Terraform for Kubernetes:

Provider and module catalog breadth. Terraform’s registry has the largest catalog of providers and community modules of any IaC tool, and that matters for teams integrating many third-party systems alongside Kubernetes.
A single tool across the whole estate. Teams that have already standardized on Terraform for networking, IAM, and managed services often prefer one state model and one pipeline rather than introducing a second tool solely for Kubernetes.
HCL’s simplicity for static configuration. For infrastructure that’s genuinely declarative and doesn’t need loops, abstraction, or conditional logic, HCL reads and reviews cleanly.
Existing governance investment. Teams with mature Sentinel or OPA policy libraries and deep in-house HCL expertise have real switching costs, and those costs are legitimate inputs to the decision.
The plan-time limitation is manageable in practice. Once cluster provisioning and workload deployment are split into separate applies — HashiCorp’s own documented pattern — the kubernetes_manifest plan-time requirement stops being a daily obstacle.

None of that is a reason to avoid Terraform outright; it’s a reason to be clear-eyed about which parts of your Kubernetes workflow benefit most from a general-purpose language and which don’t.

How do you move Kubernetes infrastructure from Terraform to Pulumi?

Teams don’t have to choose all-or-nothing. Pulumi’s pulumi convert command translates existing Terraform HCL into a Pulumi program in your target language as a starting point for further editing, and Pulumi’s guide to migrating Kubernetes YAML and Helm charts and its Terraform migration guide both cover the mechanics in more depth.

Pulumi also now meets Terraform-standardized teams partway: Pulumi IaC supports native HCL as a language option, Pulumi Cloud can serve as a state backend for existing Terraform configurations, and Pulumi supports consuming Terraform modules directly. That coexistence story — not a forced rewrite — is often the more realistic starting point for a team with a large existing Terraform estate, including Kubernetes-adjacent infrastructure. Wiz, for example, uses Pulumi’s Automation API to manage more than 1 million cloud resources, including tens of thousands of Kubernetes clusters across hundreds of data centers, with more than 100,000 daily infrastructure updates.

Frequently asked questions

Common questions that come up when teams evaluate Terraform and Pulumi for Kubernetes specifically.

Can Terraform manage a Kubernetes cluster and its workloads in one apply?

Not reliably, per HashiCorp’s own documentation. The kubernetes_manifest resource needs live API access at plan time, so the cluster must already exist and be reachable before Terraform can plan workload resources against it. The documented pattern is to split cluster provisioning and workload deployment into separate apply operations and pass values between them with data sources or remote state.

Does Pulumi replace kubectl and Helm?

No. Pulumi’s Kubernetes provider applies the Kubernetes API the same way kubectl and Helm do — it doesn’t replace the cluster API or the Helm packaging format. What it replaces is the imperative or templated workflow around applying manifests: instead of running kubectl apply or helm install by hand or from a shell script, you declare the desired state in a Pulumi program and let pulumi up reconcile it, with the same preview, diff, and rollback behavior Pulumi provides for any other cloud resource.

Is Terraform’s Kubernetes provider actively maintained?

Yes. The hashicorp/kubernetes provider is on major version 3 (v3.2.1 as of this writing, with v3.0.0 shipping in December 2025) and requires Terraform 1.0.0 or later. It’s a first-party HashiCorp provider with regular releases.

What’s the difference between kubernetes_manifest and the community kubectl provider?

kubernetes_manifest, from HashiCorp’s own provider, needs the cluster’s API reachable at plan time and is recommended mainly for custom resources not yet modeled as typed resources. The community alekc/kubectl provider (a maintained fork of gavinbunney/kubectl) applies free-form YAML through its kubectl_manifest resource and is a common workaround for the plan-time requirement; recent versions also support Terraform’s ephemeral resources so sensitive values don’t have to be written to state.

Can Pulumi and Terraform manage the same Kubernetes cluster at once?

Yes, in the sense that both talk to the same Kubernetes API and don’t inherently conflict — the risk is the same one you’d have with any two tools managing overlapping objects: whichever tool last wrote a resource’s desired state “owns” it until the other reconciles again. Most teams that run a mixed estate assign ownership by namespace, resource type, or workload boundary rather than letting both tools manage the same objects.

Where to go next

Related reading on Pulumi and Kubernetes:

YAML, Terraform, or Pulumi: what’s the smart choice for deployment automation with Kubernetes? — the manifest-authoring comparison this guide deliberately doesn’t repeat
How to Run AI Agents on Kubernetes with Pulumi — provisioning and governing infrastructure for agent workloads specifically
Kubernetes infrastructure as code: tools and best practices — a broader look at the IaC options for Kubernetes
Unit testing Pulumi programs — the full mock API reference across languages
crd2pulumi — generating typed SDKs from CustomResourceDefinitions
Migrating to Pulumi from Terraform and from Kubernetes YAML and Helm
Pulumi’s Kubernetes provider in the registry

Best Terraform Alternatives in 2026

Pulumi Content Team — Sat, 18 Jul 2026 00:00:00 +0000

The strongest Terraform alternatives in 2026 fall into three groups: general-purpose-language platforms like Pulumi and AWS CDK, HCL-compatible forks like OpenTofu, and cloud-specific tools like AWS CloudFormation, Azure Bicep, and Crossplane. Which one fits depends less on syntax preference than on how well it lets your team, and your AI coding agents, read, test, and change infrastructure safely.

What’s changed since this list was last useful: HashiCorp archived CDK for Terraform in December 2025, OpenTofu shipped its 1.12 release in May 2026, and Pulumi now runs the same HCL files Terraform does, so authoring format and deployment engine are separate decisions.

Why teams are re-evaluating Terraform in 2026

Terraform has been the default infrastructure-as-code tool for most of the last decade, and for good reason: a mature provider ecosystem, a large community, and a state model that most platform teams have learned to live with. But three forces are pushing teams to look again at what else is available.

The first is licensing. HashiCorp moved Terraform from the open-source Mozilla Public License to the Business Source License in August 2023, a shift that triggered the community fork now known as OpenTofu. HashiCorp itself became a wholly owned subsidiary of IBM when that acquisition closed in February 2025. Neither event breaks anything for existing Terraform users, but both changed how governance and long-term product direction get decided, and that’s enough for some platform teams to want a documented Plan B.

The second is the accumulated cost of working in a domain-specific language. HCL wasn’t designed for the abstraction, composition, and testing patterns that platform engineering now expects: sharing logic across teams, writing meaningful unit tests, and building internal libraries that read like software rather than templated configuration. Terraform has closed some of this gap over time, adding a native test framework in version 1.6, but the ceiling on what a declarative DSL can express is still lower than what a general-purpose language offers.

The third, and the one reshaping the conversation fastest, is agentic AI. Coding agents like GitHub Copilot, Claude, and Pulumi’s own Neo are now a standing part of how engineering teams write and review code, and infrastructure is not exempt. These agents were trained on enormous volumes of real Python, TypeScript, Go, and Java, plus their entire testing and tooling ecosystems, but on comparatively little well-formed HCL. When an agent can write and modify infrastructure in a language it already understands deeply, the feedback loop of propose, test, preview, and ship gets tighter. When it has to reason about a purpose-built DSL, that loop lengthens and the agent is more likely to produce configuration nobody would write by hand. That gap doesn’t disqualify Terraform, but it does mean “which IaC tool works best with AI agents” is now a first-class question when teams evaluate alternatives, alongside the perennial ones about multi-cloud reach and governance.

None of this is an argument that Terraform is going away. It remains a capable, widely adopted tool with a genuinely large provider catalog. It’s an argument that 2026 is a reasonable moment to look at what else exists, honestly, and pick the tool that fits where your infrastructure and your engineering workflow are actually headed. For a broader look at how AI agents are changing infrastructure work generally, see building for agentic infrastructure. For a head-to-head look at Pulumi and Terraform specifically, see our Pulumi vs. Terraform comparison.

Do you have to leave HCL behind?

No, and that’s a meaningful change since this guide was last written. Authoring format and deployment engine used to be a single choice: pick Terraform, and HCL and the Terraform CLI came as a bundle. Two things Pulumi shipped as generally available in August 2026 split that bundle apart. Staying on HCL without adopting Pulumi is also a real option, and the OpenTofu section below covers that path.

The first is Pulumi HCL, which runs the same .tf files you’d write for Terraform or OpenTofu, unmodified, on Pulumi’s engine. A project is a Pulumi.yaml with runtime: hcl and one or more .tf files, needs Pulumi CLI 3.256.0 or later, and resolves providers against the OpenTofu registry by default. It isn’t a perfect emulation: backend, provider_meta, required_version, and experiments blocks are accepted but ignored with a warning, a cloud block is an error, existing Terraform state files aren’t read directly (bring resources over with pulumi import --from hcl), and provisioner connection blocks support SSH only.

The second is Pulumi Cloud as a Terraform and OpenTofu state backend, which goes the other direction: keep the Terraform or OpenTofu CLI exactly as it is, and point its backend "remote" block at tf.pulumi.com for encrypted state storage, locking, update history, and Insights visibility. This also has real limits worth stating plainly: drift detection isn’t available for Terraform-managed stacks (it requires a Pulumi program), migrating from HCP Terraform state is a manual export and push rather than an automatic switch, and update diffs are derived from state rather than a live terraform plan, so they’re best-effort.

If you want to keep…	Change this…
Your `.tf` files and HCL syntax	Nothing — run them on Pulumi’s engine with `runtime: hcl`
Your Terraform or OpenTofu CLI and workflow	Only the backend, pointed at Pulumi Cloud
Neither, and want a general-purpose language	Everything — see the Pulumi vs. Terraform comparison

For the mechanics of each path, see terraform-to-pulumi-cloud-hands-on, how Pulumi’s engine models Terraform’s data model, and how Pulumi HCL is tested for OpenTofu compatibility.

Pulumi

Pulumi is an infrastructure-as-code platform that lets you define cloud infrastructure in general-purpose languages, including Python, TypeScript, JavaScript, Go, .NET, and Java, plus YAML and HCL for teams that prefer a declarative format. Rather than compiling down to another tool’s templates, Pulumi programs run directly against a deployment engine that supports hundreds of providers in total, covering AWS, Azure, Google Cloud, Kubernetes, and a long tail of SaaS and on-prem targets.

Pulumi also supports HCL as a first-class language, and Pulumi Cloud can serve as a drop-in state backend for existing Terraform code. That means teams with a large, working Terraform estate aren’t required to rewrite anything to get Pulumi Cloud’s state management, access controls, and policy enforcement — they can point existing HCL at Pulumi with minimal changes, then migrate configuration into a general-purpose language on their own timeline rather than all at once.

Writing infrastructure in a real language means you get the tooling that comes with it for free: IDE autocomplete and type checking, unit and integration test frameworks, package managers for sharing reusable components, and the same code review and CI/CD conventions your application teams already use. It also means Pulumi programs run directly through Pulumi’s own deployment engine against any cloud or SaaS platform, with no separate compile-to-template step in between, unlike CDK-style tools that transpile into another system’s format before anything deploys. For an AI agent iterating on infrastructure, fewer steps between “write code” and “see the result” means a tighter feedback loop. Pulumi Neo, the platform’s infrastructure agent, builds on this directly: it can propose Terraform-to-Pulumi migrations, run policy-checked previews, respond to failures, and open pull requests inside a team’s existing review workflow.

For platform teams, Pulumi adds built-in guardrails that Terraform typically requires bolting on through third-party tooling: policy as code for enforcing organizational rules before a deployment ships, a secrets and configuration management layer (ESC), human-in-the-loop approval gates, and reusable components that teams can publish and consume like any other internal library, in whatever language they use. The tradeoff is ecosystem maturity in the opposite direction from Terraform: Pulumi’s provider catalog, while broad, has a shorter history than Terraform’s for a handful of niche or long-tail providers, and some teams will need to weigh that against the language and workflow benefits.

At scale, Pulumi customers report concrete outcomes. BMW’s Software Factory manages more than 20,000 cloud resources with Python-based infrastructure code. Wiz manages more than a million cloud resources through Pulumi’s Automation API and Kubernetes operator, pushing hundreds of thousands of daily infrastructure updates across hundreds of data centers. Supabase scaled from a single region to 16 regions and roughly 80,000 resources. Atlassian’s Bitbucket team reported a 50% reduction in infrastructure maintenance time after adopting Pulumi.

OpenTofu

OpenTofu is an open-source fork of Terraform, governed by the Linux Foundation rather than a single vendor. It emerged directly from HashiCorp’s August 2023 license change: a group of Terraform users and vendors forked the last MPL-licensed Terraform release and committed to keeping the fork under a permissive open-source license going forward.

The practical pitch is continuity: OpenTofu aims to stay a close drop-in replacement for Terraform, using the same HCL syntax, the same provider ecosystem (most Terraform providers work unmodified), and largely the same workflow, so teams can migrate with minimal rewriting. OpenTofu’s own FAQ notes the compatibility boundary directly: it works with state files created by Terraform up through the 1.5.x line, the last release before HashiCorp’s license change.

Since forking, OpenTofu’s maintainers have also shipped features HashiCorp hasn’t, including state encryption, provider-defined functions, for_each on provider blocks, OCI registry support for providers and modules, and, in the 1.12 release from May 2026, dynamic prevent_destroy values. The project runs under the Linux Foundation and was accepted into the CNCF Sandbox in April 2025; its registry lists 4,000+ providers and 22,000+ modules. It remains MPL-2.0 licensed.

The tradeoff is that OpenTofu inherits HCL’s ceiling along with its familiarity. It solves the licensing and governance concern cleanly, but it doesn’t address the testing, composability, or general-purpose-language advantages that come with moving to a platform like Pulumi or AWS CDK, and AI coding agents face the same reasoning gap with OpenTofu’s HCL that they do with Terraform’s.

AWS CloudFormation

CloudFormation is AWS’s native infrastructure-as-code service, using YAML or JSON templates that AWS itself parses, validates, and rolls back on failure. Because it’s built and operated by AWS, it gets first access to new AWS service features, and its state is managed entirely by AWS rather than a separate backend your team has to configure and secure.

The obvious limit is scope: CloudFormation only provisions AWS resources, so any team running infrastructure across more than one cloud, or alongside Kubernetes and SaaS resources, will need a second tool for everything outside AWS. Authoring in raw YAML or JSON also means the same testing and abstraction limitations that HCL-based tools face, without even Terraform’s ecosystem of community modules to offset it. Many AWS-focused teams increasingly write CloudFormation stacks through AWS CDK rather than by hand.

AWS CDK

AWS CDK (Cloud Development Kit) lets you define AWS infrastructure using general-purpose languages including TypeScript, JavaScript, Python, Java, C#, and Go. Under the hood, CDK code compiles down to standard CloudFormation templates, which AWS then deploys the same way it deploys any other CloudFormation stack.

CDK gives AWS-only teams most of the general-purpose-language benefits that Pulumi offers: real loops, functions, tests, and packages, plus the IDE support that comes with a mainstream language. The compile step is the notable difference from a platform like Pulumi, which runs your program directly against cloud provider APIs: CDK synthesizes a CloudFormation template first, then hands that off, which adds a layer between what your code says and what gets deployed, and can slow the feedback loop an AI coding agent depends on when it’s proposing and testing changes iteratively. CDK is also AWS-only, so it doesn’t help teams who need one consistent authoring model across multiple clouds. AWS CDK is actively developed and unaffected by HashiCorp’s decision to sunset its own, differently named, CDK for Terraform — see the next section.

CDK for Terraform (CDKTF) is archived, not an alternative

CDK for Terraform used to appear on lists like this one as a way to write Terraform infrastructure in TypeScript, Python, Java, C#, or Go instead of HCL. That’s no longer a live option. HashiCorp archived the project on December 10, 2025, stating in its own sunset notice that CDKTF “did not find product-market fit at scale” and that it would “focus its investments on Terraform core and its broader ecosystem” instead. The GitHub repository is now read-only, and per HashiCorp’s FAQ, “no further updates, fixes, or improvements (including compatibility updates) will be made.”

CDKTF is MPL-licensed, so existing code keeps running and community forks are technically possible, but there’s no maintainer, no security patching, and no provider compatibility work going forward. Teams currently on CDKTF have two realistic paths: move to native HCL with OpenTofu or Terraform, or move to a maintained general-purpose-language platform. Pulumi supports both directions — HCL directly, or Python, TypeScript, Go, C#, and Java for a full migration — and Pulumi’s own teardown of the sunset and what to do next covers the migration paths in more depth than fits here.

One disambiguation worth stating plainly, since the two names are similar: AWS CDK and CDK for Terraform are separate projects with different maintainers and different targets. HashiCorp built CDKTF in collaboration with the AWS CDK team, on the same construct model, but it generated Terraform configuration rather than CloudFormation. AWS CDK targets CloudFormation, is maintained by AWS, and continues to ship regular releases. Only CDKTF, HashiCorp’s Terraform-targeting CDK, is the one that’s archived.

Crossplane

Crossplane is a Kubernetes-native framework for infrastructure as code, letting platform teams define and provision cloud resources as Kubernetes custom resources, managed by controllers running inside a cluster. Rather than running a separate CLI-driven apply cycle, Crossplane treats the cluster’s control plane as the single source of truth for both application and infrastructure state.

This model is a natural fit for teams already standardized on Kubernetes as their platform layer: infrastructure gets the same GitOps, RBAC, and reconciliation patterns as application workloads, and platform teams can build self-service abstractions (Crossplane calls these Compositions) that let application developers request infrastructure without learning Crossplane’s own resource model directly. The tradeoff is that Crossplane assumes a Kubernetes-centric operating model; teams without an existing cluster-based platform will be adopting Kubernetes as a prerequisite, not just an infrastructure tool, and Crossplane’s ecosystem of documented, named enterprise deployments is thinner than Terraform’s or Pulumi’s, making it harder to evaluate at-scale track record from public case studies alone.

Azure Bicep

Bicep is Microsoft’s domain-specific language for deploying Azure resources, designed as a cleaner authoring layer over Azure Resource Manager templates. Bicep code transpiles to ARM JSON, but with syntax that’s considerably easier to read and write than hand-authored ARM. It’s open source under the MIT license, and Microsoft’s own documentation recommends it over raw ARM JSON for new Azure-only infrastructure work.

Like CloudFormation, Bicep’s scope is a single cloud, in this case Azure exclusively, so it isn’t a candidate for teams managing infrastructure across providers. It’s also a DSL rather than a general-purpose language, which means the same testing and reuse ceiling as HCL, though for teams fully committed to Azure and nothing else, it remains a well-supported, low-friction choice.

Ansible

Ansible is an agentless configuration management and automation tool that uses YAML playbooks to describe the desired state of servers, software, and application deployments. Red Hat, which acquired Ansible in 2015 and was itself acquired by IBM in 2019, maintains it today as part of Red Hat Ansible Automation Platform.

Ansible is often grouped with Terraform in “IaC tool” comparisons, but the two solve different problems and are frequently used together rather than as substitutes: Terraform or Pulumi provisions the resource, and Ansible then configures the operating system, installs software, and manages ongoing configuration state on top of it. Ansible does ship cloud provisioning modules and can create resources directly, but its design center is procedural configuration management, not declarative resource provisioning at the scale Terraform-class tools target. Teams evaluating Terraform alternatives for cloud provisioning specifically will usually want a tool from this list’s other categories, with Ansible layered in afterward for day-two configuration.

Terragrunt

Terragrunt is a thin orchestration wrapper maintained by Gruntwork that sits on top of Terraform or OpenTofu, rather than replacing either one. Its job is keeping multi-environment, multi-module HCL configurations DRY, and coordinating the order in which modules apply across a larger infrastructure codebase.

Terragrunt reached 1.0 in March 2026, with the latest patch, 1.1.3, out in August 2026. The headline of 1.0 was a formal backwards-compatibility guarantee covering CLI flags, HCL config, and command output for the entire 1.x line, rather than any new functionality, aimed at teams who’d been burned by breaking changes in earlier releases. Terragrunt Stacks, which let a single configuration generate multiple units, reached general availability earlier, in version 0.78. One detail worth knowing if you’re choosing between forks: Terragrunt now shells out to tofu by default rather than terraform, reflecting where the community around it has settled; that’s overridable via the terraform_binary option. It’s still MIT licensed.

It’s worth being precise about what Terragrunt is not: it doesn’t introduce a new language, provider model, or state backend, and it doesn’t address HCL’s testing or abstraction limitations on its own. Terragrunt is a companion tool rather than a Terraform alternative, and teams adopt it to make Terraform or OpenTofu easier to operate at scale. If the underlying frustration is with HCL itself rather than with configuration sprawl, Terragrunt won’t resolve it, and it’s worth reading what Terragrunt is and isn’t before assuming it solves a language problem.

Comparison table

Tool	Language	Cloud coverage	AI-agent readiness	Governance & policy	Best for
Pulumi	Python, TypeScript, JavaScript, Go, .NET, Java, YAML, HCL	hundreds of providers, any cloud	High — real languages agents are trained on; Neo agent built in	Policy as code, ESC secrets, human-in-the-loop approvals	Teams standardizing on AI-native, multi-cloud engineering workflows
OpenTofu	HCL	Same provider ecosystem as Terraform	Same as Terraform — DSL limits agent reasoning	Linux Foundation / CNCF Sandbox; features like state encryption and dynamic `prevent_destroy`	Terraform users prioritizing open governance with minimal migration
AWS CloudFormation	YAML/JSON	AWS only	Low — templated config, no native testing	AWS-managed state and rollback	Teams fully committed to AWS wanting a fully managed native service
AWS CDK	TypeScript, Python, Java, C#, Go	AWS only (compiles to CloudFormation)	Medium — real languages, but a compile step slows feedback	Inherits CloudFormation governance	AWS-only teams wanting general-purpose languages
CDK for Terraform (CDKTF)	TypeScript, Python, Java, C#, Go	Archived Dec. 2025 — not a viable choice	N/A — no further updates of any kind	HashiCorp, unmaintained	Nothing new; existing users should plan a move
Crossplane	Kubernetes YAML/CRDs	Any cloud, via Kubernetes control plane	Medium — benefits from Kubernetes-native agent tooling	RBAC and GitOps via Kubernetes	Platform teams already standardized on Kubernetes
Azure Bicep	Bicep DSL (compiles to ARM)	Azure only	Low — DSL, no general-purpose tooling	Inherits Azure Resource Manager governance	Azure-only teams wanting a cleaner ARM authoring layer
Ansible	YAML playbooks	Any cloud, config-management focused	Low for provisioning; not its design center	Role-based playbooks, limited policy tooling	Day-two configuration management alongside an IaC tool
Terragrunt	HCL (wraps Terraform/OpenTofu)	Same as underlying Terraform/OpenTofu	Same as underlying Terraform/OpenTofu	Same as underlying Terraform/OpenTofu	Keeping large Terraform/OpenTofu codebases DRY, not a language alternative

Where each project stands in August 2026

Project	Latest release	License	Governed by	Status
Terraform	1.15.x	Business Source License	HashiCorp, an IBM Company	Actively developed
OpenTofu	1.12 (May 2026)	MPL-2.0	Linux Foundation; CNCF Sandbox	Actively developed
Terragrunt	1.1.3 (Aug. 2026)	MIT	Gruntwork	Actively developed
CDK for Terraform (CDKTF)	Archived at sunset	MPL-2.0	None — unmaintained	Archived Dec. 10, 2025
Pulumi	Rolling releases; CLI 3.259.x	Apache 2.0 (SDKs/CLI)	Pulumi Corporation	Actively developed

How to choose

If your team is standardizing on a single cloud and wants the deepest, most tightly integrated tooling for it, the native option, CloudFormation for AWS or Bicep for Azure, is a reasonable default, especially for smaller platform teams that don’t need cross-cloud abstraction. If you’re on AWS specifically and want general-purpose languages without leaving the CloudFormation ecosystem, AWS CDK is the more capable choice, with the caveat that its compile-then-deploy step adds a layer between code and infrastructure.

If your team is already running Kubernetes as its platform layer and wants infrastructure provisioning to follow the same GitOps and RBAC model as application workloads, Crossplane is worth a serious look, understanding that it comes with Kubernetes as a hard dependency.

If you’re deep in Terraform today, comfortable with HCL, and your primary concern is licensing and governance rather than language or workflow, OpenTofu is the lowest-friction path: same syntax, same providers, community governance instead of vendor governance.

If your team is investing in AI coding agents as part of its engineering workflow, wants multi-cloud reach without maintaining separate tools per provider, and values real testing, packaging, and code review practices for infrastructure the same way it does for application code, Pulumi is built specifically for that combination. It’s also the most direct path for teams on the now-archived CDKTF who need an actively maintained general-purpose-language platform, and, for teams on Terraform who aren’t ready to leave HCL, it’s the only option here that lets you keep writing .tf files while gaining that platform underneath them.

Frequently asked questions

Is Terraform still free to use?

Yes, for most teams. Terraform’s core CLI and the vast majority of its providers remain free under the Business Source License that HashiCorp adopted in August 2023. The license restricts a narrow set of commercial use cases, mainly building a competing managed offering on top of Terraform, which doesn’t affect ordinary infrastructure teams using it internally.

What is the best open-source Terraform alternative?

OpenTofu is the closest open-source alternative if you want to keep using HCL and the Terraform provider ecosystem, since it’s a direct fork governed by the Linux Foundation. If open-source licensing matters but you’re open to a different language, Pulumi’s SDKs and CLI are open source (Apache 2.0), and Crossplane is a CNCF project for teams standardized on Kubernetes.

Which IaC tool works best with AI coding agents?

Tools built on general-purpose languages give AI coding agents the strongest foundation, since those agents have far more training exposure to real Python, TypeScript, Go, C#, and Java than to any infrastructure-specific DSL. Pulumi and AWS CDK both fit this category; AWS CDK’s compile step to CloudFormation adds a layer of indirection that Pulumi, which runs directly against provider APIs, doesn’t have.

Can I migrate from Terraform without rewriting everything?

It depends on which alternative you choose. Moving to OpenTofu requires essentially no rewriting, since it’s HCL-compatible by design. Moving to Pulumi can be just as light-touch, since Pulumi Cloud works as a Terraform state backend and Pulumi IaC speaks HCL natively; teams that do want to move into a general-purpose language, or that are adopting AWS CDK or a similar platform, will need to translate configuration into program code, though tools like Pulumi’s import and conversion tooling, and increasingly AI coding agents themselves, can automate a meaningful share of that translation rather than requiring a manual line-by-line rewrite.

Is Pulumi a drop-in Terraform replacement?

It can be, if you want it to be. Pulumi Cloud now works as a Terraform state backend, so a team can point its existing Terraform or OpenTofu CLI at Pulumi Cloud and keep every .tf file exactly as written — no rewrite required. Pulumi also supports HCL as a first-class language alongside Python, TypeScript, JavaScript, Go, .NET, Java, and YAML, so HCL modules can be authored and consumed natively inside Pulumi IaC.

For teams that do want to move off HCL entirely, that’s also an option: Pulumi’s general-purpose languages let infrastructure code get loops, functions, tests, and packages that HCL doesn’t offer. Moving to that model means translating configuration into code rather than reusing files unchanged, though the underlying model carries over — state, providers, and resources map conceptually in similar ways — and Pulumi provides tooling to import existing Terraform-managed infrastructure and convert Terraform configuration into a starting Pulumi program, which teams typically use as a first draft rather than a finished migration.

Does OpenTofu support everything Terraform does?

OpenTofu tracks Terraform’s last open-source release closely and remains compatible with most existing Terraform configurations and providers. Since forking, its Linux Foundation-governed maintainers have also shipped features Terraform hadn’t offered, such as state encryption, while newer HashiCorp-only Terraform features naturally won’t appear in OpenTofu unless the community implements equivalents independently.

Is CDK for Terraform (CDKTF) still supported?

No. HashiCorp archived CDKTF on December 10, 2025 and says in its own FAQ that “no further updates, fixes, or improvements (including compatibility updates) will be made.” Existing CDKTF code keeps running since the license is MPL, but there’s no maintainer behind it. Teams still on CDKTF should move to native HCL on Terraform or OpenTofu, or to a maintained general-purpose-language platform like Pulumi. This is a different project from AWS CDK, which is unaffected and actively developed.

Is Terragrunt a Terraform alternative?

Not really. Terragrunt is an orchestration wrapper that sits on top of Terraform or OpenTofu to keep large, multi-environment HCL codebases DRY; it doesn’t run infrastructure on its own, introduce a new provider model, or change what language you write in. See the Terragrunt section above for its 1.0 release and current defaults. Teams pick Terragrunt to make Terraform or OpenTofu easier to operate at scale, not as a replacement for either.

For a broader roundup covering the full infrastructure-as-code category rather than Terraform alternatives specifically, see our guide to the best IaC tools.

Conclusion

Terraform remains a capable, widely used tool, and for teams with no appetite to change, OpenTofu offers a nearly friction-free path to the same workflow under different governance. The question worth asking for 2026 is whether your infrastructure tooling can keep pace with how your engineering organization actually builds software now, with AI coding agents as active participants rather than autocomplete. That question favors platforms built on real, general-purpose languages, tested and reviewed the same way application code is, over any tool, new or established, still built around a purpose-specific configuration syntax. Evaluate honestly against your own cloud footprint, existing platform investment, and how central AI-assisted development already is to your team, and the right alternative, or the right reason to stay put, becomes clear quickly.