Best Terraform Alternatives: Self-Hosted and Cloud

For most teams, Terraform made sense because it was what everyone used. It had the provider ecosystem, the community, the Hashicorp configuration language, the Terraform modules, the same providers everyone else depended on, and enough operational familiarity that infrastructure teams could define infrastructure without turning every change into a design debate.

That changed in August 2023 when HashiCorp moved Terraform and other products from MPL 2.0 to the Business Source License. Internal use stayed largely intact because most teams are not reselling Terraform as part of a managed service, but the mood changed.

As soon as a tool that defines your entire cloud infrastructure moves from open source to source-available, your platform engineering roadmap starts to depend on a licensing model controlled by one vendor.

Even if you stay on Terraform, is the surrounding model still enough for the way teams actually manage cloud resources?

One state file, one global lock per root module, serial workflows that slow down as state grows, cross-state dependencies held together by wrapper logic, and orchestration wrappers that gradually become their own platform are the reasons people started considering alternatives to Terraform.

Why teams consider Terraform alternatives

The honest answer is that most teams are not looking for alternatives to Terraform because the IaC solution suddenly dropped in quality. Terraform still works. It still has the provider protocol, the cloud providers, the ecosystem, the registry, the accumulated examples, and the muscle memory. The problem is that its trade-offs are now more visible.

The first driver is governance

HashiCorp's Business Source License allows broad use, including internal production use, but it restricts certain competitive offerings and introduces a legal boundary that platform teams, procurement teams, and engineering leaders must now understand. The decision to standardize on Terraform, Terraform Cloud, or Terraform Enterprise now carries a different kind of risk than it did under MPL 2.0.

The second driver is scale

Terraform's state model works beautifully when a root module is small, ownership is clear, and one pipeline applies changes at a time. It gets more awkward when one state file tracks hundreds or thousands of cloud resources across multiple environments, when several teams need to change unrelated parts of the same infrastructure setup, or when the only way to avoid contention is to split state until cross-state dependency management becomes the actual system.

The BSL license change, explained

Before August 2023, Terraform was licensed under MPL 2.0, a permissive open-source license that made it straightforward to use, modify, redistribute, embed, and build on.

After the change, future Terraform releases moved to BSL 1.1, which is source-available rather than open source in the OSI sense. You can still see the code, use Terraform internally, and manage AWS infrastructure, Azure infrastructure, Google Cloud, Kubernetes, SaaS resources, networking, storage, and the rest of your cloud infrastructure with it.

The restriction becomes apparent when you embed Terraform into a commercial product, redistribute modified versions, or offer something HashiCorp may consider competitive.

It affects you, even if your team is not a vendor. Governance decisions age slowly. A platform standard chosen in 2026 may sit inside CI/CD, audit trails, role-based access control, drift detection, cloud consoles, and infrastructure management workflows for years. Once licensing becomes a concern, you should start considering alternatives to Terraform.

Where Terraform starts to struggle at scale

Terraform's traditional state model is file-shaped, even when the file is stored remotely in one of the following:

• S3
• Google Cloud Storage
• Azure Blob Storage
• Consul
• Terraform Cloud

That state file tracks resources, attributes, outputs, dependencies, and metadata. Because Terraform must protect that source of truth, supported backends can lock state for operations that may write to it, and Terraform will not continue if it cannot acquire the lock.

That lock prevents corruption and means that two unrelated changes can block each other if they touch the same root module state, even when one engineer is changing a lifecycle rule on an S3 bucket, while another is adding a security group rule to application code infrastructure somewhere else in the graph.

The usual workaround is to split state.

Networking gets its own state, compute gets another, data gets another, environments get separated, teams get separated, and suddenly the infrastructure is no longer one graph but a federation of files.

Splitting state can help with lock contention, but it creates a new problem. Cross-state outputs become fragile, dependency order moves into third-party tools, Terragrunt-like orchestration starts carrying more logic, and teams end up managing infrastructure through an unofficial single control plane made out of wrappers, conventions, and hope.

The best Terraform alternatives

The right Terraform alternative depends on what problem you need to solve.

• If the problem is the Business Source License, consider OpenTofu.
• If HCL is the problem, try Pulumi.
• If Kubernetes is already your infrastructure control plane, Crossplane changes the model entirely.
• If the work is configuration management rather than declarative cloud provisioning, you might select Ansible.
• If you are all-in on one cloud, AWS CloudFormation and Azure Bicep are first-party choices.
• If Terraform or OpenTofu still works but state management does not, Stategraph is the alternative that leaves the engine alone and changes the layer underneath it.

OpenTofu

OpenTofu is the closest thing to Terraform without being Terraform.

It began as the OpenTF fork after the license change, moved under the Linux Foundation in September 2023, and was later accepted into the Cloud Native Computing Foundation as a Sandbox project in April 2025.

It keeps the HCL workflow, existing Terraform configurations, provider compatibility, and the familiar plan-and-apply model, making it the default answer for teams that want open governance without rewriting infrastructure code.

Not just a static fork anymore, OpenTofu 1.7 added state encryption and provider-defined functions, with OpenTofu 1.7 adding state encryption using AES-GCM, with key management integrations for AWS KMS, GCP KMS, and OpenBao.

Best for

Teams that want to keep HCL, the Terraform workflow, the same providers, and most existing tools, while moving to an open-source-governed project that is not controlled by a single vendor.

Key features

• Full HCL and provider compatibility from the Terraform 1.5.x baseline
• CNCF governance, so no single vendor controls the roadmap
• Built-in state encryption using AES-GCM, available from v1.7
• Growing independent provider and module registry
• Active development with features beyond the original Terraform baseline

When not to use OpenTofu

OpenTofu is the wrong answer if your team is heavily invested in HCP Terraform Stacks, because Stacks are a configuration layer tied to HCP Terraform.

It's also not the solution if you want to move away from HCL into general-purpose programming languages, or if the core problem is multi-state dependency management and state lock contention.

After all, OpenTofu maintains the basic Terraform state model and can point state at a familiar backend like S3.

Pulumi

Pulumi is the main alternative for teams that want to write infrastructure in TypeScript, Python, Go, C#, Java, .NET, YAML, or other supported SDK paths rather than HCL.

Shifting away from HCL means infrastructure can use loops, conditionals, classes, functions, packages, unit tests, and application code patterns without pushing HCL beyond what it was designed to do. It's still infrastructure as code, but using familiar programming languages across AWS, Azure, Google Cloud, Kubernetes, and other providers.

Pulumi is different, not better.

Real programming languages are powerful, and they also create real codebases. For developer-heavy teams, that may be perfect, but for ops-heavy infrastructure teams that like the constraint of declarative HCL, Pulumi can feel like turning infrastructure into another application framework to maintain.

Best for

Pulumi is best for development-heavy teams that find HCL limiting and want reusable, testable infrastructure components written in languages they already use.

Key features

• Write infrastructure in TypeScript, Python, Go, C#, Java, and other supported languages
• Plan-and-apply workflow with Pulumi state management
• Strong support for AWS, Azure, Google Cloud, and Kubernetes
• Pulumi AI and Pulumi Copilot for code generation assistance
• Access to Terraform providers through provider bridging

When not to use Pulumi

Pulumi is a weaker fit when the team is primarily ops-focused and comfortable in HCL, when per-resource Pulumi Cloud pricing becomes a concern at scale, or when the hard problem is cross-state dependency management rather than language expressiveness.

Pulumi stacks still have their own state boundary, which means changing the language does not magically erase state architecture.

Crossplane

Crossplane is a Kubernetes-native approach where cloud resources are modeled as Kubernetes APIs, usually through custom resources and controllers, and then reconciled continuously.

It's a good choice for platform teams that have already made Kubernetes their control plane and want cloud resources, internal abstractions, and platform APIs to follow the same reconciliation model.

Selecting Crossplane is a bigger architectural shift than adopting OpenTofu or Pulumi. With Crossplane, the operating model becomes Kubernetes-shaped. Desired state lives in Kubernetes resources, GitOps becomes natural, and platform teams can build composites that hide cloud API complexity behind internal abstractions.

Best for

Crossplane is best for platform teams that already run Kubernetes deeply and want cloud infrastructure to be managed through Kubernetes APIs, controllers, and GitOps workflows.

Key features

• Kubernetes-native infrastructure as code using custom resource definitions
• Continuous reconciliation instead of one-time apply workflows
• GitOps-compatible by design
• Provider ecosystem for AWS, Azure, Google Cloud, Kubernetes, and more
• Compositions that let platform teams build internal abstractions over cloud APIs

When not to use Crossplane

Do not adopt Crossplane just to avoid Terraform. If your team is not already comfortable operating a Kubernetes cluster, Crossplane adds a learning curve and operational layer that may be heavier than the problem you started with.

Ansible

Ansible overlaps with infrastructure as code, but it does not behave like Terraform. It's procedural, agentless, YAML-driven, and commonly used for configuration management, application deployment, server automation, network automation, and operational tasks.

Because Ansible emphasizes automation over SSH without agents on remote systems, it is often combined with Terraform. Terraform provisions cloud resources. Ansible configures machines, deploys packages, manages services, and handles the messy server-level work that declarative provisioning tools are not always good at.

Best for

Ansible is best for teams focused on configuration management, post-provisioning automation, application deployment, and hybrid or on-premise infrastructure with SSH-based automation.

Key features

• Agentless automation, usually over SSH
• YAML playbooks that are readable without deep IaC experience
• Large module ecosystem across operating systems, cloud platforms, and networking tools
• Broad community support and enterprise support through Red Hat Ansible Automation Platform
• Works well alongside Terraform as a post-provisioning configuration layer

When not to use Ansible

Ansible is a poor replacement when the goal is declarative cloud infrastructure provisioning with strong drift detection, clean state management, policy-as-code around infrastructure changes, and predictable lifecycle management for multiple resources across multiple clouds.

AWS CloudFormation

AWS CloudFormation is the native AWS IaC tool. It is deeply integrated with AWS services, supports stack change sets, can roll back failed stack updates, and uses StackSets for multi-account and multi-region deployments.

For teams that focus on managing AWS infrastructure, the appeal is obvious. It is first-party, close to the AWS APIs, and does not require a separate third-party IaC framework to manage AWS resources.

The trade-off is just as obvious. CloudFormation is AWS-only. CloudFormation templates can become verbose in YAML or JSON. AWS CDK exists partly because many teams wanted a higher-level cloud development kit over the raw template model.

Best for

CloudFormation is best for teams that are all-in on AWS and want native service coverage, built-in rollback behavior, change set previewing, IAM integration, and no separate multi-cloud abstraction.

Key features

• Native AWS integration with broad support for AWS services
• Automatic rollback on stack failure
• No additional tool cost, with users only paying for the AWS resources created
• StackSets for multi-account and multi-region deployments
• IAM integration and change sets for previewing infrastructure changes before deployment

When not to use CloudFormation

CloudFormation is the wrong fit when the infrastructure spans multiple clouds, when the team needs a consistent IaC tool across AWS, Azure, and Google Cloud, or when the syntax overhead becomes its own productivity tax.

Azure Bicep

Azure Bicep is Microsoft's modern domain-specific language for Azure Resource Manager. It gives Azure teams a cleaner way to define infrastructure than ARM JSON while compiling down to ARM templates.

Bicep is a declarative language for deploying Azure resources, with concise syntax, type safety, modules, and integration across the Azure deployment lifecycle.

Like CloudFormation, Bicep's strength is its first-party nature, which also means it's limited. If your entire cloud lives in Azure, great. If your infrastructure requirements include AWS, GCP, Kubernetes, SaaS providers, or multi-IaC environments, Bicep isn't the right choice.

Best for

Azure Bicep is best for teams working exclusively on Azure that want a readable, first-party alternative to ARM templates.

Key features

• Concise, readable DSL that compiles to ARM JSON
• Full Azure resource coverage through first-party Microsoft support
• Native integration with Azure CLI, Azure DevOps, and GitHub Actions
• Modules for reusable resource definitions
• No Terraform-style state file, because Azure Resource Manager tracks resource state directly

When not to use Azure Bicep

Bicep is not the right fit if the infrastructure spans multiple clouds, if your team wants one IaC language across the entire cloud estate, or if the broader Terraform and OpenTofu ecosystem is central to how your team manages infrastructure today.

Stategraph

Stategraph does not ask you to replace Terraform or OpenTofu, instead highlighting that, even if the engine is fine, the state backend is a bottleneck.

Traditional Terraform state is a JSON document. Stategraph stores infrastructure state as a dependency graph in PostgreSQL instead, which means resources, dependencies, ownership, history, and relationships become structured data rather than buried attributes in a flat state file.

That changes what the backend can do. It can lock at the resource level instead of the full state level. It can run non-overlapping transactions in parallel. It can expose SQL-queryable inventory. It can manage cross-state operations through the graph instead of forcing every team to stitch outputs together through wrappers. Check out how Stategraph works for more details.

Stategraph doesn't require infrastructure teams to rewrite HCL, abandon Terraform modules, switch cloud providers, rebuild CI/CD, or retrain everyone on a new IaC framework. Teams keep Terraform or OpenTofu, the same providers, the same modules, and the same broad workflow. The backend layer changes, which is exactly where lock contention, slow applies, cross-state dependency pain, inventory gaps, and audit history tend to accumulate.

Best for

Stategraph is best for teams already running Terraform or OpenTofu at scale who are hitting state lock contention, slow serial applies, cross-state dependency pain, or a governance gap across multiple environments, and do not want to re-platform their entire IaC stack to fix state management.

Key features

• Replaces the Terraform state file with a normalized PostgreSQL schema
• Resource-level locking, so independent infrastructure changes can apply in parallel without contention
• SQL-queryable inventory across environments, workspaces, and states
• Full attribution and audit history for every resource change
• Cross-state dependency management without external orchestration wrappers
• State encrypted at rest with AES-256 and in transit with TLS 1.3
• Compatible with Terraform and OpenTofu through the HTTP backend protocol
• Deployable as SaaS, single-tenant SaaS, or self-hosted inside your own VPC

When not to use Stategraph

Stategraph is not for teams that have moved away from Terraform or OpenTofu entirely. It is for teams that want to keep their existing HCL, providers, and CLI workflow, while replacing the backend layer that stores and locks state.

How to choose the right Terraform alternative

Start with the actual problem, not the tool category. If the issue is open governance and you want the least disruption, OpenTofu is the obvious place to begin. It keeps HCL, the provider ecosystem, existing Terraform configurations, and the workflow most teams already know.

If the issue is developer experience, Pulumi is the more natural alternative, because it lets teams write infrastructure in programming languages they already use. Pulumi works best when infrastructure is maintained by application teams, rather than when infrastructure teams value declarative constraints over general-purpose abstraction.

If your infrastructure model is already Kubernetes-native, consider Crossplane, as it turns cloud resources into reconciled Kubernetes resources.

If your primary work is configuration management, server automation, application deployment, or hybrid infrastructure, Ansible remains one of the strongest tools. Just don't mistake it for a stateful declarative cloud provisioning engine.

If the environment is AWS-only and first-party control is the priority, go for CloudFormation. If the environment is Azure-only, use Azure Bicep. Both reduce third-party dependency, and both give up cloud agnostic portability.

If Terraform or OpenTofu is already embedded in the organization and the pain is state file contention, slow plans and applies, cross-state dependencies, audit trails, unmanaged resources, or the lack of SQL-queryable infrastructure inventory, Stategraph is the solution that changes the backend rather than the whole infrastructure stack.

Conclusion

Not every team needs to rip out Terraform. Most teams probably should not. Terraform still has an enormous ecosystem, and OpenTofu now gives HCL-oriented teams an open governance path that keeps the familiar workflow alive.

However, most teams running serious infrastructure have at least one problem the classic model does not solve well, whether that is the Business Source License, the cognitive load of HCL workarounds, the limitations of single-cloud tools, or the operational drag of state file locking across a growing estate.

If the friction point is state lock contention, slow serial applies, cross-state dependencies, or not being able to ask basic SQL questions of your infrastructure, the answer may not be a new IaC engine at all. It may be a better state layer underneath the tools you already use.

Start Stategraph free or read the Stategraph docs.

Terraform alternatives FAQs

What is the best open-source alternative to Terraform?

OpenTofu is the best direct open-source alternative to Terraform for teams that want HCL, familiar commands, provider compatibility, and open governance. It was launched under the Linux Foundation after the Terraform license change and later accepted into CNCF as a Sandbox project.

Is OpenTofu production-ready?

Yes, OpenTofu is production-ready for many teams, especially those whose infrastructure is already compatible with the Terraform 1.5.x baseline and does not depend on HCP Terraform-specific features. Teams should still test providers, modules, state migration, and CI/CD behavior before switching production workflows.

What are the best Terraform Cloud alternatives for teams at scale?

The best Terraform Cloud alternatives depend on the surface area you need. Teams whose primary pain points are state management, lock contention, slow execution, and cross-state visibility should evaluate Stategraph, which changes the backend layer while keeping Terraform or OpenTofu in place.

Does Stategraph work with OpenTofu as well as Terraform?

Yes. Stategraph works with both Terraform and OpenTofu.

What is the difference between Terraform and Ansible?

Terraform is a declarative infrastructure provisioning tool with state management. Ansible is an agentless automation and configuration management tool that commonly uses SSH and YAML playbooks.

Terraform is usually better for defining cloud resources and managing desired infrastructure state, while Ansible is usually better for configuring servers, deploying applications, and automating operational tasks after resources exist.

Do I need to replace Terraform to fix state lock contention?

No. Replacing Terraform is one option, but it is not the only one. If the main problem is state lock contention, slow applies, and cross-state dependency overhead, a state backend replacement like Stategraph can address the bottleneck while leaving Terraform or OpenTofu, HCL, providers, and modules in place.

Try Stategraph free

If Terraform or OpenTofu still fits your team but the state layer has become the bottleneck, Stategraph is worth seeing in practice. It keeps your existing HCL, providers, modules, and CLI workflow, and replaces only the backend that stores and locks state.