OpenTofu for CDE Infrastructure
The open-source Terraform alternative for provisioning and managing Cloud Development Environment infrastructure with native state encryption and full community governance
Why OpenTofu Exists
Understanding the origins, governance, and trajectory of the open-source Infrastructure as Code tool that emerged from a pivotal industry moment.
The License Change That Shook IaC
In August 2023, HashiCorp announced it was changing Terraform's license from the permissive Mozilla Public License v2.0 (MPL 2.0) to the Business Source License v1.1 (BSL 1.1). This change meant that companies offering competitive products or services built on Terraform could no longer freely use the code. The shift sent shockwaves through the Infrastructure as Code community, as thousands of organizations had built their infrastructure automation strategies on Terraform's open-source foundation.
Within days, a coalition of companies and individuals launched the OpenTF manifesto, calling for HashiCorp to reverse the decision or for the community to fork the project. When it became clear the license change was permanent, the fork proceeded under the stewardship of the Linux Foundation, and OpenTofu was born.
Community Governance and the Linux Foundation
OpenTofu is not controlled by any single vendor. It operates under the Linux Foundation with an open governance model that ensures no one company can unilaterally change the project's direction or licensing. The Technical Steering Committee (TSC) includes representatives from multiple organizations, and all decisions are made transparently through public proposals and community review.
This governance model provides long-term assurance for enterprises building critical infrastructure on OpenTofu. Unlike vendor-controlled projects, the community can always fork and continue development if any contributor attempts to restrict the project. For CDE infrastructure that underpins daily developer workflows, this stability guarantee is essential.
The Current State of OpenTofu
Rapid Development
OpenTofu has shipped multiple major releases since its inception, introducing features like native state encryption and early variable evaluation that Terraform does not offer. The project has attracted hundreds of contributors and maintains a regular release cadence.
Broad Industry Support
Major cloud infrastructure companies including Spacelift, env0, Scalr, Harness, Gruntwork, and others actively contribute to OpenTofu. This broad backing ensures the project remains well-resourced and aligned with real-world enterprise needs, including CDE provisioning workflows.
MPL 2.0 Forever
OpenTofu is permanently licensed under MPL 2.0, ensuring it remains truly open-source. The Linux Foundation charter explicitly prevents license changes, giving organizations the confidence to invest in OpenTofu for their long-term CDE infrastructure strategy without risk of future licensing restrictions.
Key Features
OpenTofu delivers everything Terraform offers plus community-driven innovations that address real pain points in infrastructure provisioning.
Native State Encryption
OpenTofu supports encrypting state files natively without requiring external tools or wrapper scripts. State files often contain sensitive data such as database passwords, API keys, and infrastructure details. With native encryption, your CDE infrastructure state is protected at rest using industry-standard algorithms.
This is especially important for CDE deployments where state files may contain developer credentials, workspace configurations, and cloud provider secrets. You can use AWS KMS, GCP KMS, Azure Key Vault, or PBKDF2 passphrases as encryption providers.
Full Terraform Compatibility
OpenTofu is a drop-in replacement for Terraform in the vast majority of configurations. Existing .tf files, modules, provider configurations, and state files work without modification. Teams can migrate gradually and confidently, testing each module independently.
For CDE platform teams, this means your existing Coder templates, workspace provisioning scripts, and infrastructure modules continue to work as-is. The transition requires changing a single binary, not rewriting infrastructure code.
Community-Driven Development
Every feature, bug fix, and roadmap decision is made through an open process. RFCs are publicly discussed, and contributions are accepted from any individual or organization. There is no "enterprise edition" gating critical features behind a paywall.
Platform engineering teams benefit from a project where feature requests and bug reports receive equal priority regardless of corporate backing. Community governance ensures features that matter to the broad user base, including CDE operators, get prioritized.
Provider Ecosystem
OpenTofu supports all existing Terraform providers, including the AWS, Azure, GCP, Kubernetes, and Docker providers that CDE platforms depend on. The OpenTofu Registry mirrors provider availability, so you have immediate access to thousands of community and official providers.
Provider compatibility means your entire CDE stack - from VPC networking and Kubernetes clusters to Docker registries and DNS records - works identically under OpenTofu without any provider-level changes.
Early Variable/Locals Evaluation
OpenTofu introduced early evaluation of variables and locals, allowing them to be used in contexts where Terraform requires static values, such as backend configuration blocks and module sources. This eliminates cumbersome workarounds and partial configurations.
For CDE infrastructure, this feature enables dynamic backend selection per environment, parameterized module sources, and cleaner configuration patterns that reduce duplication across development, staging, and production workspaces.
Registry Support
The OpenTofu Registry provides a centralized catalog of providers, modules, and policy libraries. It is compatible with existing Terraform Registry modules and also hosts OpenTofu-specific community modules.
Organizations can use private registries for internal CDE modules, enabling platform teams to publish and version-control workspace templates, networking blueprints, and security baselines that development teams consume as standardized building blocks.
Migration from Terraform
Moving from Terraform to OpenTofu is straightforward for most organizations. Here is what changes, what stays the same, and how to plan a safe migration.
What Stays the Same
The vast majority of your Terraform investment carries over directly to OpenTofu. The HCL configuration language, provider plugin protocol, state file format, and module structure are all compatible. Your existing .tf files, .tfvars files, and module references will work without modification in nearly all cases.
- All .tf configuration files
- State files (local, S3, Azure Blob, GCS, Consul, etc.)
- Provider configurations and versions
- Module references (public and private)
- Variable definitions and outputs
What Changes
The changes required are minimal and mostly involve tooling references rather than infrastructure logic. The binary name changes from terraform to tofu, CI/CD pipelines need updated commands, and any Terraform Cloud or Terraform Enterprise integrations need alternative backends.
- CLI binary:
terraformbecomestofu - CI/CD scripts referencing
terraform plan/apply - Terraform Cloud/Enterprise backend configurations
- GitHub Actions or GitLab CI Terraform-specific steps
- Lock file provider registry URLs (auto-updated on first init)
Step-by-Step Migration Plan
Audit Your Terraform Configurations
Inventory all Terraform workspaces, modules, providers, and backend configurations. Identify any HashiCorp-specific features like Terraform Cloud workspaces, Sentinel policies, or private registry modules that need alternatives.
Install OpenTofu Alongside Terraform
Both tools can coexist on the same machine. Install OpenTofu and begin testing your configurations in a non-production environment. Run tofu init and tofu plan to verify compatibility.
Test with Non-Critical Infrastructure First
Start with development CDE workspaces or staging environments. Run tofu plan and compare the output to terraform plan for the same state. They should produce identical results for compatible configurations.
Update CI/CD Pipelines
Replace terraform commands with tofu in your CI/CD configurations. Update GitHub Actions, GitLab CI, Jenkins pipelines, or any automation that invokes Terraform. Use official OpenTofu GitHub Actions for seamless integration.
Migrate Production Workloads
After validating in staging, migrate production infrastructure management to OpenTofu. Since the state file format is compatible, you can switch the binary without modifying state. Always take a state backup before the first production apply.
Enable OpenTofu-Specific Features
Once fully migrated, take advantage of OpenTofu-exclusive features like native state encryption, early variable evaluation, and enhanced provider configuration. These can be adopted incrementally without disrupting existing workflows.
Rollback Plan
Because OpenTofu and Terraform share the same state file format and configuration language, rolling back is straightforward. If you encounter issues during migration, simply point your CI/CD pipelines back to the Terraform binary. State files remain compatible in both directions for the same version lineage. Always maintain state backups before your first OpenTofu apply to ensure a clean rollback path.
Note that if you adopt OpenTofu-specific features (such as native state encryption), those configurations will not be backward-compatible with Terraform. Plan your rollback boundary accordingly, and only enable OpenTofu-exclusive features after you are confident in the migration.
CDE Infrastructure Provisioning
OpenTofu is the engine behind how CDE platforms like Coder provision developer workspaces. Here is how it fits into the CDE infrastructure stack.
OpenTofu and Coder Templates
Coder uses Terraform (and now OpenTofu) templates as the core mechanism for defining developer workspaces. Each template is an OpenTofu configuration that specifies the compute resources, networking, storage, and development tools a workspace needs. When a developer creates a workspace, Coder runs tofu apply behind the scenes to provision the infrastructure.
This means platform teams can define workspace templates that provision Kubernetes pods, AWS EC2 instances, Azure VMs, GCP Compute Engine instances, or Docker containers - all using familiar HCL syntax. OpenTofu's native state encryption adds an extra security layer for workspace state data that may contain developer credentials and environment configurations.
Provisioning the Supporting Infrastructure
Beyond individual workspaces, OpenTofu provisions the foundational CDE infrastructure: Kubernetes clusters that host workspace pods, VPC networking with proper security groups and subnets, container registries for development images, shared storage volumes, load balancers, and DNS records. This base-layer infrastructure is typically managed separately from workspace templates.
OpenTofu modules let platform teams package and share reusable infrastructure patterns. A "CDE cluster" module might create an EKS cluster with autoscaling node groups, configure RBAC policies, set up monitoring, and install the Coder Helm chart - all in a single reusable, version-controlled module that can be deployed across multiple environments.
Common CDE Use Cases with OpenTofu
Kubernetes Workspaces
Provision Kubernetes pods with specific resource requests, persistent volume claims, service accounts, and network policies. Developers get isolated namespaces with pre-configured toolchains and direct cluster access for testing.
Cloud VM Workspaces
Spin up EC2 instances, Azure VMs, or GCP Compute Engine instances with GPU support, custom AMIs, pre-installed development tools, and secure networking. Ideal for workloads that need full OS access or specialized hardware.
Multi-Service Stacks
Provision complete development stacks including application containers, databases, message queues, and caches. OpenTofu orchestrates all components together, giving each developer an isolated full-stack environment that mirrors production.
OpenTofu vs Terraform vs Pulumi
A decision matrix to help platform engineering teams choose the right Infrastructure as Code tool for their CDE deployments.
| Criteria | OpenTofu | Terraform | Pulumi |
|---|---|---|---|
| License | MPL 2.0 (truly open-source) | BSL 1.1 (source-available) | Apache 2.0 (open-source) |
| Language | HCL (declarative) | HCL (declarative) | TypeScript, Python, Go, C#, Java, YAML |
| State Management | Local, S3, GCS, Azure Blob + native encryption | Local, S3, GCS, Azure Blob, Terraform Cloud | Pulumi Cloud (free tier), self-managed backends |
| Community | Linux Foundation, multi-vendor governance | HashiCorp (now IBM) controlled | Pulumi Inc. controlled, active community |
| Enterprise Features | All features in open-source; commercial backends available (Spacelift, env0) | Terraform Cloud/Enterprise for collaboration, policy, SSO | Pulumi Cloud for state, secrets, RBAC, audit logs |
| CDE Integration | Drop-in for Coder; supported by major CDE platforms | Native Coder integration; industry standard for CDEs | Requires custom integration; not natively supported by most CDEs |
OpenTofu
Terraform
Pulumi
Which Should You Choose for CDEs?
Choose OpenTofu if you want a truly open-source IaC tool with no licensing risk, native state encryption, and full compatibility with existing Terraform configurations and CDE platforms like Coder. It is the strongest choice for organizations that value open governance and long-term licensing stability.
Choose Terraform if you are already deeply invested in Terraform Cloud or Terraform Enterprise and the BSL license does not conflict with your business model. It remains a mature, well-documented tool with the largest ecosystem, though the license change has introduced uncertainty for some use cases.
Choose Pulumi if your team prefers general-purpose programming languages over HCL and you are willing to build custom CDE integrations. Pulumi excels when infrastructure logic requires complex conditionals, loops, and abstractions that benefit from a full programming language. However, it lacks native CDE platform support.
Continue Learning
Explore related topics to deepen your understanding of Infrastructure as Code and Cloud Development Environments.
The Core Concept
Learn the foundational principles of Infrastructure as Code for developer environments using OpenTofu, Terraform, and DevContainers.
CDE Architecture
Explore reference architectures for deploying CDE infrastructure on AWS, Azure, GCP, and Kubernetes.
CDE Tools Comparison
Compare CDE platforms like Coder, Ona (formerly Gitpod), GitHub Codespaces, and Daytona that use OpenTofu for infrastructure provisioning.