Terraform vs Pulumi vs OpenTofu in 2026: What Should a Team With No Infra Engineers Pick?

Key Points:

• If nobody owns infrastructure full-time, start with a managed platform or an internal developer platform, then add Terraform or Pulumi only for the resources the platform does not cover. Both IaC tools assume someone maintains state, modules, providers, and CI pipelines for years. That is a recurring headcount cost, not a one-week setup.
• Pick Terraform (or its MPL-2.0 OpenTofu fork) for the largest provider ecosystem and the biggest hiring pool. Terraform is the IaC tool the largest share of professional developers report using in the Stack Overflow 2025 Developer Survey, at the cost of HCL's limited expressiveness.
• Pick Pulumi when your team writes TypeScript, Python, Go, or C# every day. Same desired-state model, same state file to manage, but authored in a language your developers already test and debug. Pulumi can also consume Terraform providers, so the ecosystem-size argument mostly disappears.
• Pick a managed PaaS (Vercel, Render, Railway, Heroku) when your app is a standard web service plus a database and you have no compliance or data-residency constraints. The trade-off: workloads run in the vendor's account, so cloud discounts, VPC peering, and cost ownership are not yours.
• Pick a BYOC internal developer platform (Qovery, Porter, Northflank) when you want PaaS-grade self-service but the cloud account, the bill, and the compliance boundary must stay yours.

I get asked a version of this question almost every week: a team of eight to fifteen engineers, shipping fast, nobody whose actual job title is infrastructure. Should they learn Terraform? Try Pulumi because they already live in TypeScript? Or just put everything on a managed platform and forget the whole thing?

Here is my answer, up front, no "it depends" dodge: a team with no dedicated infra engineer should start on a managed platform or an internal developer platform and reach for Terraform or Pulumi only for the pieces the platform does not handle. The reason has nothing to do with tool quality. Terraform and Pulumi are both excellent. The reason is who runs terraform apply at 2am on a Tuesday six months from now.

Let me earn that verdict.

What should a team with no dedicated infra engineer actually choose?

For a team under roughly 20 engineers with nobody owning infrastructure full-time, start with a managed platform or a BYOC internal developer platform, and introduce Terraform or Pulumi only for the resources the platform does not cover. The deciding factor is not which tool is best. It is who maintains the tooling next quarter.

There are four real options, and it helps to name them precisely:

• IaC-first: Terraform, OpenTofu, or Pulumi. You write infrastructure as code and run it yourself.
• PaaS-first: Vercel, Render, Railway, Heroku. You push code, the vendor runs it in their account.
• Platform-on-your-own-cloud (BYOC): Qovery, Porter, Northflank. PaaS-style self-service, but the workloads run in your cloud account.
• Self-built: Backstage plus Crossplane plus Argo CD. You build the platform yourself.

The hidden cost of the IaC-first path is the one teams underestimate. The first module is cheap. What is not cheap: provider major-version upgrades, state drift, module versioning, and the review bottleneck that forms when every infra change has to go through the one person who understands the setup. Gartner predicts 80% of large software engineering organizations will have platform engineering teams by 2026, up from 45% in 2022. Most teams reach the point where someone owns this. The question is whether that is you, today, with the headcount you have.

Here is the quick verdict by profile:

Most mature teams end up running a mix: a platform for the repeatable application layer, IaC for the bespoke infrastructure. That is the correct end state, not a compromise.

How much time does Terraform or Pulumi actually cost a small team?

Adopting IaC from scratch costs a few weeks of learning before the first safe production apply, then a permanent maintenance tax. In a team with no infra owner, that tax lands on one or two engineers who did not sign up for it, and it never goes away.

The real work is not writing the first resource. It is everything around it:

• A remote state backend plus state locking (S3 and DynamoDB, GCS, Azure Blob, or a hosted backend)
• Secrets handling that does not leak into state
• Module structure and versioning so changes are reviewable
• Drift detection between what is declared and what actually exists
• Plan and apply in CI with least-privilege credentials
• Blast-radius control so one bad apply does not take down production

None of that ships features. And the opportunity cost is measurable: the 2024 DORA State of DevOps report found elite performers deploy far more frequently and recover from failures much faster than low performers, with change lead times roughly 127x shorter. Self-service platforms exist to close that gap. Hand-rolled IaC maintained by a part-timer tends to widen it.

Now price the alternative honestly. Per levels.fyi, the median DevOps engineer total compensation in the US sits around $150,000 (checked October 2026). That is the number a founder is implicitly choosing against when deciding whether to run infrastructure in-house. A platform that costs a few hundred dollars a month and removes most of that work is not an expense, it is a hire you did not have to make yet.

There is also the bus-factor problem. IaC knowledge concentrates in whoever set it up, and that person becomes the review gate for every infrastructure change. Terraform's registry reduces the blank-page cost because so much prior art exists, but it increases upgrade churn: a provider major-version bump can mean a day of reading changelogs, testing in a staging workspace, and fixing deprecations.

And in 2026, anyone evaluating Terraform asks about the licensing first. HashiCorp adopted the Business Source License (BUSL 1.1) for Terraform on August 10, 2023, moving away from the previous open-source MPL. The community responded with OpenTofu, which reached general availability on January 10, 2024 under MPL 2.0 and is hosted by the Linux Foundation. Then IBM completed its $6.4 billion acquisition of HashiCorp on February 27, 2025, a deal first announced in April 2024. For most teams the practical takeaway is simple: OpenTofu is the drop-in, MPL-licensed path if the BUSL terms make your legal team nervous.

Pulumi vs Terraform: what is the real difference for a non-specialist team?

Both tools describe desired-state infrastructure, both keep a state file you have to store and lock, and both cover essentially the same cloud surface. Pulumi can even consume Terraform providers directly. For a non-specialist team the practical difference is the authoring language and the testing story, not raw capability.

Terraform uses HCL, a purpose-built configuration language. Pulumi lets you write infrastructure in TypeScript, JavaScript, Python, Go, C#/.NET, Java, and YAML. If your team already writes TypeScript, loops, conditionals, type checking, and IDE autocomplete come for free, and you test infrastructure with the same frameworks you use for application code. Terraform tests through its built-in terraform test command, Terratest, and policy-as-code tools like OPA or Sentinel.

Here is the same S3 bucket in both tools. First Terraform or OpenTofu, in HCL:

resource "aws_s3_bucket" "assets" {
  bucket = "my-team-assets"

  tags = {
    Environment = "production"
  }
}

output "bucket_name" {
  value = aws_s3_bucket.assets.id
}

Then Pulumi, in TypeScript:

import * as aws from "@pulumi/aws";

const assets = new aws.s3.Bucket("assets", {
  bucket: "my-team-assets",
  tags: { Environment: "production" },
});

export const bucketName = assets.id;

Same resource, same desired-state model, same need for a state backend. The difference shows up once you need ten buckets with slightly different settings: in Pulumi it is a loop and a function your editor type-checks, in HCL it is for_each over a map. Neither is hard. What matters is which one your team will still read comfortably in a year.

The ecosystem gap is smaller than people think. HashiCorp's registry passed 3,000 providers back in March 2023 and the Terraform Registry lists more than 4,000 today (checked October 2026). But Pulumi's ability to use any Terraform provider through its bridge means that whole catalog is reachable from Pulumi too. The "Terraform has more providers" argument mostly dissolves on contact.

One hybrid path worth flagging and then setting aside: CDK for Terraform (CDKTF) let you write real languages on top of the Terraform provider ecosystem. HashiCorp deprecated CDKTF on December 10, 2025 and no longer maintains it, so I would not start anything new on it. If you want general-purpose languages for IaC in 2026, Pulumi is the maintained answer.

Where does OpenTofu fit in a Pulumi vs Terraform decision? It sits on the Terraform side. OpenTofu is the MPL-2.0 fork of Terraform under the Linux Foundation: same HCL, same state format, same providers, and features such as client-side state encryption that Terraform does not have. So the real choice is HCL (Terraform or OpenTofu) versus a general-purpose language (Pulumi), and then, if you chose HCL, which binary. We cover that second question, including a repo layout for a new project, in OpenTofu vs Terraform in 2026.

Prices and counts checked October 2026 against HCP Terraform pricing and Pulumi pricing.

My honest conclusion: a TypeScript-heavy team reaches a working stack faster with Pulumi. A team that wants the largest body of examples to copy from should take Terraform or OpenTofu. Neither choice is wrong, and neither removes the state-file-and-upgrades maintenance tax.

When is a managed platform the better answer than writing IaC?

A managed PaaS is the better answer when your app is a standard shape (web service, worker, database, cron) and you have no compliance, data-residency, or VPC-peering constraints. At that point infrastructure is a solved problem you should buy, and Vercel, Render, or Railway will get you to production in an afternoon with no state file to own.

What you get out of the box: git-push deploys, managed TLS, autoscaling, logs, managed Postgres and Redis, and zero provider upgrades. What you give up is where the workloads run. Vercel, Render, Railway, and Heroku all run your compute in the vendor's account. You rent both the platform and the machine underneath it.

That has concrete consequences. AWS and GCP startup credits do not apply. Committed-use discounts do not apply either, and those are large: AWS Compute Savings Plans cut compute costs by up to 66%, and GCP committed use discounts reach up to 57% for general compute. You also inherit the vendor's regions, their egress pricing, and a longer SOC 2, HIPAA, or GDPR scoping conversation because your data lives in someone else's account.

Pricing checked October 2026 against Vercel, Render, Railway, and Heroku.

I want to be fair here because the comparison deserves it. On raw compute, usage-based platforms like Railway sit surprisingly close to cloud list prices per vCPU and per GB. The premium is real but it varies a lot by provider, and fixed-price or bandwidth-heavy platforms (Vercel, Heroku) carry the larger markup. The structural cost you always forfeit is the committed-use discount and the credits, because those only apply to compute in your own account.

The classic breaking points are predictable: a compliance requirement, a VPC-peered database, a GPU workload, or a bill that stops making sense at your traffic. Until you hit one of those, a managed PaaS is often the right call. For a seed-stage team shipping a Next.js app, putting it on Vercel or Render is genuinely correct, and adopting Terraform instead would waste the quarter.

Is there an option between raw IaC and a locked-in PaaS?

Yes. A BYOC (bring-your-own-cloud) internal developer platform provisions into your own cloud account, so developers get PaaS-grade self-service while the infrastructure, the cloud bill, and the compliance boundary stay in your name. Qovery, Porter, and Northflank are the established options in this category. The pattern is a control plane run as a service and a data plane that lives inside your account.

This is where Qovery fits. It deploys into your own AWS, GCP, Azure, or Scaleway account, or onto an existing Kubernetes cluster (self-managed, on-prem, any distribution). Developers get git-push deployments, a preview or ephemeral environment per pull request, environment auto-stop for non-production so idle environments stop billing, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services. The control plane handles the application layer; the workloads run where you can see them.

The bill staying in your name is not a detail. It means AWS Savings Plans (up to 66%), GCP committed use discounts (up to 57%), startup credits, and your own FinOps visibility all remain yours. On a PaaS, that savings is the vendor's to keep. And the category sits on solid ground: the CNCF 2024 Annual Survey reported Kubernetes in production use at 80% of surveyed organizations, which is exactly the substrate these Kubernetes-native platforms build on.

The alternatives are real and each is good at something. Porter is strong for teams that want a Heroku-like experience on their own AWS, GCP, or Azure. Northflank is good when you want fine-grained control over builds and stateful workloads. Coherence targets full-environment replication for larger app estates. And Backstage plus Crossplane is the self-built route if you have the engineers to run it, which loops right back to the headcount question.

Here is the honest trade-off, because pretending it away would kill the point: a BYOC platform shrinks your IaC surface by a large margin, it does not remove it. You still own the existence of a Kubernetes cluster, and you still write Terraform or Pulumi for anything outside the application platform's scope.

Can you combine Terraform or Pulumi with a managed platform?

Yes, and most mature setups do exactly that. The platform owns the repeatable application layer while Terraform or Pulumi owns the bespoke infrastructure around it. A BYOC platform shrinks the IaC surface by a large margin; it does not erase it.

A clean split of responsibilities usually looks like this: VPCs, IAM, data stores, DNS zones, and shared networking live in IaC, while services, environments, and preview environments live in the platform. Qovery publishes a Terraform provider, qovery/qovery, on both the Terraform Registry and the OpenTofu Registry, so clusters, environments, applications and databases can be declared in HCL alongside the rest of your infrastructure. Pin it with version = "~> 1.0"; the provider docs list the resources. Qovery can also run Terraform or OpenTofu code as a service inside an environment, so a per-environment queue or bucket is created and destroyed with that environment.

The adoption order matters. Grow platform-first, then add IaC as your needs get specific. Doing it in reverse (building a bespoke internal platform on top of Terraform modules before anyone is hired to maintain it) is the most common way small teams burn a quarter on infrastructure nobody asked for.

And the choice is reversible in both directions. Moving from a PaaS to your own account costs more the longer you wait, but a BYOC platform keeps your workloads in standard Kubernetes, so changing your mind later is a migration, not a rewrite.

How do you decide in under 10 minutes?

Answer five questions and each path maps to exactly one approach:

1. Who maintains infrastructure next quarter? Nobody full-time, choose a platform. A dedicated hire, IaC becomes viable.
2. Does your workload fit a standard web/worker/database shape? Yes, a PaaS or BYOC platform covers it. Highly custom, you will need IaC regardless.
3. Do you have compliance or data-residency constraints? Yes, keep workloads in your own account (BYOC or IaC), not a vendor PaaS.
4. Is cloud portability a hard requirement? Yes, avoid vendor-account PaaS; pick BYOC or IaC.
5. What language does your team write every day? TypeScript/Python/Go pushes you toward Pulumi over Terraform when you do write IaC.

Rules of thumb by stage:

• Choose a managed PaaS if you are pre-seed or seed, shipping a standard app, with no compliance constraints and no infra owner.
• Choose a BYOC platform like Qovery if you are seed to Series A, want self-service and preview environments, and need the cloud account and bill to stay yours.
• Choose Pulumi if you have at least a part-time infra owner and your team already writes TypeScript, Python, Go, or C#.
• Choose Terraform or OpenTofu if you have infra ownership and want the largest hiring pool and the biggest library of existing examples (OpenTofu if the BUSL license is a concern).

Dedicated IaC ownership usually starts paying for itself somewhere around Series B, or earlier if you are in a regulated industry. Before that, a platform almost always wins on total cost once you price in the engineer you would otherwise have to hire.