What you'll learn: Terraform transitioned from an open-source license to the Business Source License in 2023, prompting teams to evaluate alternatives for managing cloud resources. This guide covers the licensing change, compares truly open-source options like OpenTofu, and explains how to choose based on your current infrastructure-as-code setup and future requirements.

Whether you're part of the Terraform user community or evaluating infrastructure as code (IaC) tools for the first time, understanding the implications of HashiCorp's announcement is important for your infrastructure provisioning strategy across cloud providers. Terraform is not open source. HashiCorp switched to the Business Source License (BSL) in August 2023, restricting commercial use while allowing internal infrastructure provisioning. Teams using Terraform for their production infrastructure and cloud resources management need to understand what this means for their existing workflows and whether open-source alternatives make sense. The license change sparked immediate responses from the tech community. OpenTofu was launched as a fork, maintaining open-source licensing under the Linux Foundation, while tools like Pulumi and Crossplane gained attention as different approaches to Infrastructure as Code. Each handles state management and [state file](https://stategraph.dev/blog/terraform-state-file-storage) operations differently, with varying support for provider ecosystems and learning curves for teams managing infrastructure. This guide examines open-source alternatives for infrastructure provisioning, ranging from drop-in replacements that preserve your existing workflows and configuration files to tools that take entirely different approaches. We'll cover state file compatibility, module migration paths, provider ecosystem support, and practical considerations for teams running production infrastructure across cloud providers. ## When and why Terraform stopped being open source The Mozilla Public License (MPL) license that made Terraform truly open source for years gave way to restrictions affecting the entire Terraform ecosystem, from individual Terraform users to enterprises running Terraform Enterprise. HashiCorp announced the license change in August 2023, shifting Terraform from MPL to BSL. Teams found out their go-to tool, chosen specifically for its open-source nature and community contributions, now had restrictions on production use that affected how they could deploy and manage infrastructure. Contributors who'd spent years submitting bug fixes, fixing bugs in prior versions, and improving state management under the assumption their work would remain open source now had to find a new tool. HashiCorp built its reputation through open collaboration and community engagement, with Terraform becoming the standard for infrastructure as code because engineers trusted that they'd avoid vendor lock-in. The company benefited from thousands of community contributions and improvements to other projects, then pulled the ladder up.

Note: Terraform providers have stayed under open-source licenses (HashiCorp publicly committed to keeping their open-source licenses intact), creating an odd split where the core engine requires restrictive licensing but connectors to cloud providers remain free. Most providers aren't HashiCorp-maintained; breaking them would destroy the entire Terraform ecosystem and provider support overnight.

The OpenTofu initiative emerged quickly, originally named OpenTF before the Linux Foundation and Cloud Native Computing Foundation stepped in with governance structures. OpenTofu's manifesto clearly lays out their goals: to maintain truly open-source infrastructure tools, preserve existing workflows, and ensure that no single vendor controls the project's future, thereby preventing another vendor lock-in scenario. ## Terraform open source alternatives The landscape changed dramatically after HashiCorp's announcement, with a few open-source projects emerging to fill the gaps. While one (OpenTofu) offers a drop-in replacement (swap binaries, keep configuration files and modules untouched), others reimagine how teams manage resources entirely, moving from declarative configuration toward programmatic control. You'll want to consider the following: can you migrate your state file without breaking production, will existing modules work, do your cloud providers have first-class support, and can your team adopt without months of retraining? ### Terrateam [Terrateam](https://terrateam.io/) creates an open-source management layer that sits on top of Terraform, rather than replacing it entirely. You keep existing Terraform code, configuration files, and modules exactly as-is, while Terrateam handles automation, collaboration, and governance through open-source infrastructure tooling that you control. Integration happens at the [CI/CD level](https://terrateam.io/blog/terraform-ci-cd-tool-comparison-2025), where Terrateam manages infrastructure deployments through pull requests, handling state management, state encryption, and resource planning without requiring changes to Terraform configurations. Engineers continue to write the HCL code they know, using the same Terraform providers and modules from the same registry. However, the orchestration layer, which runs terraform plan and terraform apply, becomes open-source software that you can inspect, modify, and self-host if needed. When you run Terraform through Terrateam, you're using the same Terraform providers and can deploy to various cloud providers while benefiting from open collaboration. Key features include: * A GitOps [orchestration engine](https://terrateam.io/orchestration-engine), giving you full control over your infrastructure automation * State locking that prevents concurrent modifications from corrupting the infrastructure * Remote backends support, including Terraform Cloud migrations * The ability to configure [nested and layered stacks](https://terrateam.io/stacks) in Terraform to run operations quickly and safely * [Monorepo setups](https://terrateam.io/monorepo-at-scale) where multiple teams manage cloud resources at scale * Community engagement, enabling custom policies and existing workflows Terrateam suits organizations that can't afford migration disruption. If you're deep into Terraform with hundreds of modules, switching tools means rewriting everything. Terrateam lets you keep what works. ### OpenTofu Originally named OpenTF, the [OpenTofu](https://opentofu.org/) initiative gained momentum when the community rallied around preserving the open source nature of infrastructure tools. OpenTofu development continues under Linux Foundation governance, with the OpenTofu team ensuring this code tool remains accessible. OpenTofu emerged as the most direct response to HashiCorp's licensing change, providing a drop-in replacement maintaining compatibility with existing configuration files, state files, and the entire provider ecosystem. The first stable version reached general availability in January 2024, following intensive development that addressed critical bugs and security issues while maintaining strict compatibility with Terraform 1.5.x. OpenTofu maintains compatibility through careful attention to configuration language, making sure that HCL files, modules, and variable definitions work identically, despite the project's addition of new features, such as enhanced state encryption, which Terraform lacks. OpenTofu's workflow is exactly like Terraform's: ```bash # Install OpenTofu as simple binary change brew install opentofu # Migrate existing infrastructure tofu init # same as terraform init tofu plan # reviews changes tofu apply # deploys resources ``` Provider compatibility works because OpenTofu uses identical protocols, meaning every provider in the Terraform Registry functions with OpenTofu, from major cloud providers to specialized providers for DNS entries, monitoring services, and SaaS features. Basic commands map one-to-one, preserving muscle memory, though OpenTofu started introducing enhancements like improved state encryption and better remote backends handling that Terraform users had been requesting for years. The Linux Foundation's governance ensures no single company owns OpenTofu or controls its direction. The OpenTofu team comprises engineers from multiple organizations who learned from Terraform's license change that open-source tools require protection. Community contributions flow through standard workflows, with bug fixes and new features reviewed by maintainers from different companies, preventing unilateral decision-making. | | OpenTofu | Terraform | | :---- | :---- | :---- | | **License** | Mozilla Public License | Business Source License | | **State compatibility** | Full compatibility | N/A | | **Provider support** | Same registry | Original | | **Community** | Linux Foundation-backed | HashiCorp controlled | | **Future features** | Community-driven | Terraform Cloud focused | ### Pulumi Pulumi eliminates declarative configuration entirely, allowing you to define and deploy infrastructure using programming languages (TypeScript, Python, Go, and C#) instead of learning domain-specific languages. Rather than writing HCL to create cloud resources, you write regular code with loops, conditionals, and functions, bringing software engineering to infrastructure provisioning: ```python import pulumi from pulumi_aws import ec2 # Dynamic resource creation for i in range(3): instance = ec2.Instance(f"web-{i}", instance_type="t3.micro", ami="ami-XXXXXXXXXXXX", tags={"Environment": "production"}) pulumi.export(f"instance_{i}_ip", instance.public_ip) ``` This unlocks capabilities that declarative tools struggle with, including complex conditionals, API calls during provisioning, type safety, and IDE support with autocomplete. Migration requires restructuring from declarative HCL to imperative programming; however, `pulumi convert --from terraform` helps automate the conversion of existing workflows. Pulumi makes sense if you're tired of HCL's limitations. Your developers already know Python or TypeScript, so why learn another language just for infrastructure? The downside is that a smaller community means fewer examples, third-party modules, and Stack Overflow answers when hitting edge cases. Here's a full comparison of [Pulumi vs. Terraform](https://terrateam.io/blog/terraform-vs-pulumi) to help you decide. ### Crossplane Crossplane extends Kubernetes to manage cloud resources through custom resource definitions (CRDs), turning Kubernetes into a universal control plane for all infrastructure: ```yaml apiVersion: ec2.aws.crossplane.io/v1alpha1 kind: Instance metadata: name: production-web spec: forProvider: instanceType: t3.micro region: us-west-2 ``` Installation requires an existing Kubernetes cluster, followed by the addition of Crossplane via Helm. State management leverages Kubernetes' etcd rather than separate state files, providing automatic drift detection through continuous reconciliation loops. Crossplane works well for Kubernetes-centric organizations that want unified workflows for applications and infrastructure. Limited outside the Kubernetes ecosystem, managing simple resources like DNS entries through Kubernetes feels excessive for teams that are not already deeply invested in CNCF tools. ### Ansible Ansible approaches infrastructure provisioning through a configuration management lens, using playbooks defining desired states rather than dedicated infrastructure as code language: ```yaml - name: Provision infrastructure amazon.aws.ec2_instance: name: web-server instance_type: t3.micro state: present register: ec2_result ``` Unlike Terraform's detailed state files that track every resource attribute, Ansible operates statelessly, checking the current state each run, which eliminates state file corruption and backend configuration complexity, but loses [drift detection](https://docs.terrateam.io/governance/drift-detection/) and dependency tracking that Terraform provides. Go with Ansible if you are already using it for configuration management, where adding infrastructure provisioning to existing playbooks is more practical than introducing new tools. Limitations appear with complex cloud infrastructure, requiring careful dependency management. ## Why we made Terrateam open source We built Terrateam as an open-source project because infrastructure tooling belongs to the community using it. Open collaboration brings engineers from different companies together to fix bugs we'd never encounter, add integrations for tools we've never used, optimize for scales we haven't reached, and build better software than any single company could create alone. With this model, no organization gets trapped in vendor-specific workflows, which can create migration nightmares when licensing terms change or business strategies shift. Transparency in source code enables security teams to audit exactly how Terrateam handles state files and credentials, rather than relying on black-box claims. The platform's open nature enables custom compliance policies, specialized multi-cloud workflows, and internal tool integrations that no vendor would support. Supporting open source infrastructure means tools remain accessible to startups without enterprise budgets, consultancies needing flexibility, and enterprises requiring transparency for compliance. Building trust through open development turns users into partners who report issues, suggest features, and contribute code to solve real problems, creating software that serves its community rather than extracting value. ## Conclusion Terraform's move to BSL means teams must decide whether proprietary infrastructure tooling remains an acceptable risk. Each alternative offers different approaches: * OpenTofu provides a drop-in replacement that maintains existing workflows * Pulumi uses programming languages instead of HCL * Crossplane extends Kubernetes for infrastructure * Ansible adds infrastructure provisioning to configuration management Choose based on your specific needs and existing infrastructure. * OpenTofu minimizes disruption for teams wanting open source with minimal change. Pulumi suits teams that prefer code over configuration * Crossplane suits Kubernetes-heavy environments already using CNCF tools * Ansible makes sense if you are you are already managing configurations Terrateam, meanwhile, integrates open-source orchestration into Terraform, allowing for easy adoption without requiring migration, maintaining existing investments while avoiding vendor lock-in. Start exploring open source infrastructure management at [Terrateam](https://terrateam.io/signup), where you can enhance existing Terraform workflows with open source tooling while preserving your modules, state management, and team knowledge. ## Terraform open source FAQs * **Is Terraform still open source?** No, Terraform has used BSL since August 2023. You can use it internally, but you cannot build competing commercial services. * **Do Terraform providers need forking?** No, providers remain under open source licenses. HashiCorp has publicly committed to keeping them open, as most are third-party maintained. * **What's the easiest migration path from Terraform?** OpenTofu works as a drop-in replacement (swap Terraform with OpenTofu). Terrateam adds open source orchestration while keeping Terraform. Both preserve existing state files and modules. * **Can I still use Terraform for free?** Yes, but free isn't really open source. BSL allows internal use but restricts commercial offerings, with vague definitions creating legal uncertainty. * **Will OpenTofu stay compatible with Terraform?** Currently compatible with Terraform 1.5.x configurations. Future divergence is likely as each adds different new features, though OpenTofu promises backward compatibility for existing configurations. * **Who owns OpenTofu?** No single entity owns OpenTofu. The Linux Foundation provides governance, ensuring that it remains an actual open-source project with community engagement driving development.

Features

Learn More

Learn

Connect

Posts tagged "ansible"

Is Terraform open source? No, but there is an alternative