Terraform, Pulumi, Kubernetes, or none: picking infra in 2026

I have used Terraform to provision Kubernetes clusters and the ASP.NET Core microservices running on them. I ran EKS workloads at RIDE Capital, wrote terragrunt stacks at Kfzteile24, and shipped Dapper-based microservices onto them. My personal site, this site, runs on 47 lines of wrangler.toml and zero Kubernetes.

After seven years of building with and without those tools, here is the honest cutoff.

What each tool is actually for

Terraform is a declarative state machine for cloud resources. You describe the desired state in HCL, Terraform reconciles the real world to match, and the state file is the source of truth. It shines when you have multiple environments, multiple people, and resources that drift the moment someone touches a dashboard.

Pulumi is Terraform with TypeScript (or Python, or Go) instead of HCL. Same provider model, same state file, different surface language. It wins for teams that want loops, conditionals, and type safety the HCL grammar cannot easily express.

Kubernetes is not infrastructure-as-code. It is an operating system for your containers. You run K8s, you do not declare it with K8s. Terraform (or Pulumi, or eksctl) provisions the cluster; K8s runs the workloads on it.

Cloudflare Workers, Vercel, Fly — the escape hatch. No clusters, no state files. You push code, the platform runs it, your wrangler.toml IS the infrastructure definition.

When Terraform earns its keep

Honest answer: when three things are simultaneously true.

You have more than one environment. Dev, staging, and prod need the same shape with different parameters. Terraform modules plus variables plus workspaces make this clean. Doing it by hand guarantees drift within three weeks.
You have more than one owner. When five engineers can touch the same AWS account, terraform plan becomes a review surface. PRs to an infra repo show the diff with approvals required. This is irreplaceable at a company.
Your infrastructure is heterogeneous and long-lived. Forty microservices, a dozen RDS instances, three EKS clusters, IAM policies, Route 53 records, SQS queues, SNS topics. State files keep this honest. Click-ops does not scale past a handful of resources.

At Kfzteile24 we had all three. Terraform (with terragrunt on top for DRY) pulled its weight every day. Without it the platform team would have been doing the same manual setup across four environments every sprint.

When Pulumi earns its keep over Terraform

One situation: your team is TypeScript-native and your infra has logic HCL cannot express cleanly. Dynamic numbers of resources, nested conditionals, calls out to external APIs during plan, shared code with the application layer.

If your team is fine with HCL, Terraform is still the safer choice. The community is larger, the provider coverage is broader, and the battle-tested production stories are more numerous. Pulumi ESC (their secrets and config story) is genuinely useful on its own and you can use it alongside Terraform without committing to the full Pulumi runtime.

When Kubernetes earns its keep

K8s wins when you have real workloads that need orchestration:

Stateful services with specific storage guarantees — Postgres, Elasticsearch, Kafka.
Containers with CPU or memory profiles that need mixed node types.
Long-running jobs with SLAs — queue workers, data pipelines, batch jobs.
Existing investment — you already have a platform team, a CD pipeline, observability wired in, an operator ecosystem you trust.

K8s does not win when you have stateless HTTP services that fit in a Worker. The Cloudflare platform is genuinely fullstack in 2026: D1, R2, KV, Durable Objects, Queues, Cron Triggers, Static Assets. A lot of what used to require a K8s cluster in 2022 runs in a Worker in 2026 for a tenth of the cost and zero operational surface.

When none of the above earns its keep

For personal sites, side projects, and small SaaS under a million requests per month: no Terraform, no Pulumi, no Kubernetes, no state file. wrangler.toml declares your infrastructure. pnpm run deploy is your CD pipeline. A short scripts/setup-cloudflare.sh creates the D1 database, R2 bucket, and secrets once. That IS infrastructure-as-code.

The test I apply: can a teammate without my local setup reprovision the whole thing from a fresh clone in ten minutes? For this site the answer is yes, because wrangler.toml plus one shell script plus two secrets is the whole story. Adding Terraform would mean another tool, a state backend, and duplicated config for the same three resources.

The one-shot decision framework

Multiple envs + owners + heterogeneous infra?
  -> Terraform (or OpenTofu). Default.

Same situation + TypeScript team + dynamic infra logic?
  -> Pulumi.

Stateful workloads + storage + mixed compute profiles?
  -> Kubernetes (EKS / GKE / AKS). Provision the cluster with Terraform.

Stateless HTTP + cron + queues + simple storage?
  -> Cloudflare Workers + D1 + R2 + Queues. Skip state files.

One developer + one env + one cloud account?
  -> wrangler.toml + a setup shell script. That IS your IaC.

The current state in 2026

Terraform is still the industry default. HashiCorp re-licensed to BSL in late 2023, the OpenTofu fork exists and is Apache 2.0, and most large organisations have either moved or are mid-migration. For new projects, start with OpenTofu. The CLI and language are identical and the licence matters for serious work. Existing Terraform codebases migrate with a CLI swap in most cases.

Pulumi is healthier than it was, with Pulumi ESC bringing a real secrets and config story. Still smaller community, still more opinionated. If you are not already there, Terraform or OpenTofu is the safer default.

Kubernetes is less fashionable but still load-bearing everywhere workloads are complex. Karpenter finally delivered the dynamic node pool story that made cluster costs sane. The operator ecosystem is mature. K8s fatigue is real but the alternative (managing the same state in scripts) is worse.

Edge and serverless ate the middle. The stack this site runs on did not exist in 2020. Cloudflare Workers shipped D1 in 2023, Static Assets in 2024, and the platform matured enough in 2026 to replace most small-team K8s clusters.

The honest advice

Pick for the situation you are in, not the one you wish you were in.

If you are at a company with 40 services: Terraform (or OpenTofu) is not optional. Learn it properly, write modules, use workspaces, make terraform plan the review surface.

If you are one developer with one side project: do not add a state file. wrangler.toml is enough. Revisit the moment the account gets a second owner.

The pattern that fails most often is the middle: one developer, one project, but Terraform added "because best practices". Now you have a state backend to babysit, a drift-detection ritual, and 200 lines of HCL managing three resources. That is not infrastructure-as-code; that is infrastructure-as-ceremony.