Terraform vs Pulumi vs OpenTofu

By Khimananda Oli | Last reviewed: August 2026

Selecting the right infrastructure as code tool defines your team's velocity, compliance posture, and long-term maintenance burden for years to come. The decision between Terraform vs Pulumi vs OpenTofu is no longer just about syntax preferences; it involves navigating licensing changes, multi-cloud provider coverage, and the trade-off between declarative configuration and general-purpose programming languages. As teams in Nepal and globally scale their cloud operations in 2026, understanding these architectural differences prevents costly re-platforming efforts later. This guide breaks down the technical realities based on production deployments across AWS, Azure, and GCP.

How do licensing differences affect Terraform vs Pulumi vs OpenTofu adoption?

The single most significant shift in the IaC landscape occurred when HashiCorp moved Terraform from the Mozilla Public License (MPL) to the Business Source License (BSL). This change fundamentally altered the risk profile for organizations building platforms or offering managed services. Understanding this distinction is critical before you write a single line of HCL or TypeScript.

OpenTofu emerged directly from this licensing controversy as a true open-source fork under the MPL 2.0 license. In practice, OpenTofu maintains near-complete backward compatibility with Terraform 1.5.x state files and configuration syntax. For Nepali startups and global SMEs concerned about vendor lock-in or future licensing pivots, OpenTofu provides an insurance policy without requiring immediate code rewrites. You can migrate existing Terraform projects to OpenTofu with minimal friction, often just changing the binary name in your CI pipeline.

Pulumi has always operated under the Apache 2.0 license for its core engine and SDKs, making it permissive for commercial use. However, Pulumi’s business model relies heavily on its SaaS backend for state management, policy enforcement, and secrets handling. While you can self-host the Pulumi Service or use local/cloud storage backends, the full feature set assumes engagement with their commercial platform. This contrasts with both Terraform and OpenTofu, where the CLI is fully functional standalone and remote state backends (S3, GCS, Azurerm) are community-maintained standards.

When should you choose Pulumi over HCL-based tools?

HCL (HashiCorp Configuration Language) is intentionally limited. It lacks loops, conditionals, and abstraction mechanisms beyond what the Terraform/OpenTofu runtime explicitly supports. This constraint is a feature for simple infrastructure but becomes a liability when managing complex, dynamic environments. If you find yourself writing excessive dynamic blocks, struggling with for_each limitations, or needing to compute values that require external API calls before planning, Pulumi’s general-purpose language approach solves these problems natively.

Real-world complexity example

Consider provisioning an EKS cluster where node group sizes depend on real-time spot pricing data, and IAM policies must be generated from a parsed OpenAPI specification. In HCL, this requires awkward external data sources and fragile JSON manipulation. In Pulumi using TypeScript, it looks like standard application code:

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

// Fetch current spot prices dynamically
const spotPrices = await getSpotPrices("us-east-1");
const optimalInstanceType = selectCheapest(spotPrices, ["m5.large", "m5.xlarge"]);

// Parse API spec and generate IAM policies programmatically
const apiSpec = JSON.parse(fs.readFileSync("./openapi.json", "utf-8"));
const iamPolicyDocument = generateLeastPrivilegePolicy(apiSpec.paths);

const cluster = new aws.eks.Cluster("prod-cluster", {
    roleArn: eksRole.arn,
    vpcConfig: { subnetIds: privateSubnetIds },
});

// Use native language constructs for conditional resources
if (config.enableMonitoring) {
    new aws.cloudwatch.MetricAlarm("high-cpu", {
        comparisonOperator: "GreaterThanThreshold",
        evaluationPeriods: 2,
        metricName: "CPUUtilization",
        namespace: "AWS/EC2",
        period: 300,
        statistic: "Average",
        threshold: 80,
        alarmActions: [snsTopic.arn],
    });
}

This expressiveness comes with costs. Your infrastructure now has a build step, dependency management (npm/pip/go.mod), and requires developers to understand both cloud APIs and software engineering practices. For teams already strong in TypeScript, Python, or Go, this trade-off pays dividends. For ops-heavy teams accustomed to YAML and HCL, the cognitive overhead can slow initial adoption. Read more about Pulumi's approach to real programming languages to evaluate if your team fits this profile.

What are the practical differences in state management and workflows?

All three tools solve the same fundamental problem: mapping desired state to actual cloud resources via a persistent state file. However, their implementation details create meaningful operational differences in 2026.

• Terraform/OpenTofu State: Stored as a JSON blob in remote backends (S3+DynamoDB, GCS, Azure Blob). State locking is primitive but effective. The plan output is human-readable and auditable, making it ideal for SOC 2 compliance evidence collection. Module registries are mature, though OpenTofu’s public registry is still catching up to HashiCorp’s in provider breadth.
• Pulumi State: By default, stored in Pulumi Cloud with built-in encryption, history, and RBAC. Self-managed backends (S3, GCS, local filesystem) are supported but lose some SaaS features like drift detection and policy-as-code integration without additional setup. The pulumi preview command produces structured output that integrates better with programmatic validation but is less intuitive for manual review than Terraform’s plan.
• Import & Drift: Terraform 1.5+ and OpenTofu introduced config-driven import blocks, reducing the pain of adopting existing infrastructure. Pulumi has had pulumi import since early versions and generates code automatically, but the generated code sometimes requires manual cleanup for complex resource graphs.

How does ecosystem maturity compare across providers and modules?

Ecosystem depth often matters more than theoretical capabilities. A tool might support your cloud provider, but if the provider lags six months behind new service releases or lacks critical bug fixes, your team will spend time working around tooling gaps instead of delivering value.

In my experience helping Nepali companies adopt cloud infrastructure, Terraform’s ecosystem advantage translates directly to faster troubleshooting. When you hit an obscure EKS networking issue at 2 AM, someone has likely documented the fix on Stack Overflow or GitHub issues for the Terraform AWS provider. OpenTofu inherits most of this knowledge base due to compatibility, but Pulumi-specific edge cases have fewer searchable solutions. This doesn’t mean Pulumi is inferior—it means your team needs stronger internal documentation habits and comfort reading provider source code when needed.

Which tool minimizes long-term risk for compliance-heavy organizations?

For organizations pursuing ISO 27001, SOC 2, or operating in regulated sectors like fintech (increasingly relevant for Nepal’s growing digital payments ecosystem), the choice extends beyond developer preference. Auditability, change traceability, and supply chain trust become primary selection criteria.

Terraform and OpenTofu produce deterministic plans that serve as excellent audit artifacts. The separation between plan and apply creates a natural approval gate that maps cleanly to change management controls. OpenTofu’s MPL license ensures no future licensing surprises can disrupt your compliance posture—a consideration that gained urgency after 2023’s BSL transition. For teams implementing DevSecOps practices, both integrate seamlessly with policy engines like OPA/Conftest and static analysis tools.

Pulumi’s strength here lies in its ability to embed compliance checks directly into infrastructure code using familiar testing frameworks. Instead of maintaining separate Rego policies, you can write integration tests that validate security constraints before deployment. However, reliance on Pulumi Cloud for full audit trails introduces a third-party dependency that some auditors scrutinize. Self-hosted Pulumi mitigates this but adds operational overhead. If your organization already uses Pulumi Cloud and has completed vendor assessment, this concern diminishes significantly.

Making the final call for your 2026 infrastructure strategy

The Terraform vs Pulumi vs OpenTofu decision ultimately reflects your organization’s priorities, not absolute technical superiority. Choose OpenTofu if you want maximum freedom, compliance safety, and Terraform compatibility without licensing anxiety. Choose Pulumi if your team lives in TypeScript/Python/Go and infrastructure complexity demands real programming constructs. Choose HashiCorp Terraform if you’re already invested, don’t face BSL restrictions, and value the deepest ecosystem above all else.

Whichever path you select, invest in solid foundations: remote state with locking, CI-driven workflows with mandatory plan reviews, and automated policy checks. These practices matter far more than the specific tool. If you’re evaluating IaC adoption for your team or need help migrating between these platforms while maintaining compliance readiness, reach out to discuss your infrastructure strategy.