Want to level up your OpenTofu knowledge? Explore our tutorials and step-by-step guides written by OpenTofu experts. Learn OpenTofu best practices and solutions to the most difficult problems.

OpenTofu Guides and Tutorials | Spacelift Blog

Author title

Going to AWS Summit London? 🇬🇧🇬🇧

Title category

Get all the latest content on Infrastructure as Code, DevOps, Spacelift features & news directly to your inbox!

Level up your IaC knowledge. Stay up to date with educational devops guides & news in infrastructure as code, cloud & more!

Managing Infrastructure at Scale | Spacelift Blog

Announcing Enhanced VCS Integration  🎉 🎉

applepodcasts

spotify

missionctrl

Welcome to missionCTRL, a show dedicated to exploring the frontiers of modern DevOps. Listen (or watch) as we sit down with the practitioners who are pushing the boundaries of development

OpenTofu

Flavius Dinu

Great news for the DevOps and Infrastructure as Code world – <a href="https://spacelift.io/blog/opentofu-stable-ga-release" target="_blank" rel="noopener">OpenTofu’s first stable release</a> is here! 
This OpenTofu tutorial includes:
<ol>
<li><a href="https://spacelift.io/blog/opentofu-tutorial#what-is-opentofu">What is OpenTofu?</a></li>
<li><a href="https://spacelift.io/blog/opentofu-tutorial#why-opentofu-matters-in-the-devops-ecosystem">Why OpenTofu matters in the DevOps ecosystem?</a></li>
<li><a href="https://spacelift.io/blog/opentofu-tutorial#how-to-install-opentofu">How to install OpenTofu</a></li>
<li><a href="https://spacelift.io/blog/opentofu-tutorial#how-to-migrate-from-terraform-to-opentofu">How to migrate from Terraform to OpenTofu</a></li>
<li><a href="https://spacelift.io/blog/opentofu-tutorial#basic-opentofu-components-with-examples">Basic OpenTofu components with examples</a></li>
<li><a href="https://spacelift.io/blog/opentofu-tutorial#key-features-of-opentofu">Key features of OpenTofu</a></li>
<li><a href="https://spacelift.io/blog/opentofu-tutorial#common-problems-and-solutions">Common problems and solutions</a></li>
<li><a href="https://spacelift.io/blog/opentofu-tutorial#opentofu-best-practices">OpenTofu best practices</a></li>
<li><a href="https://spacelift.io/blog/opentofu-tutorial#advanced-opentofu-features">Advanced OpenTofu features</a></li>
<li><a href="https://spacelift.io/blog/opentofu-tutorial#opentofu-registry">OpenTofu registry</a></li>
<li><a href="https://spacelift.io/blog/opentofu-tutorial#using-opentofu-with-spacelift">Using OpenTofu with Spacelift</a></li>
</ol>

<a href="https://opentofu.org/" target="_blank" rel="noopener">OpenTofu</a> is an open-source project that serves as a fork of the legacy MPL-licensed Terraform. It was developed as a response to a change in HashiCorp’s licensing of Terraform, from Mozilla Public License (MPL) to a Business Source License (BSL), which imposed limitations on the use of Terraform for commercial purposes. As an alternative, OpenTofu aims to offer a reliable, community-driven solution under the Linux Foundation.

OpenTofu ensures that one of the core and most popular IaC tool remains open-source. With this you not only get an open-source Terraform alternative, but this also ensures the fact that the later deployment of OpenTofu will take advantage of the community’s feedback. 
In the DevOps world, OpenTofu&#8217;s significance is amplified by its capabilities of infrastructure management. It continues the legacy of Terraform by supporting infrastructure as code (IaC). This enables teams to automate and efficiently manage infrastructure deployment, crucial for enhancing operational scalability and reliability. 
OpenTofu&#8217;s backward compatibility with Terraform&#8217;s infrastructure also means organizations deeply integrated with Terraform can transition without disrupting their existing workflows. This compatibility, coupled with the broad support from <a href="https://opentofu.org/supporters" target="_blank" rel="noopener">various organizations in the DevOps community</a>, positions OpenTofu not just as a tool but as a potential standard in the evolving landscape of DevOps, supporting its principles of automation, collaboration, and continuous improvement.

Let&#8217;s see different ways you can install OpenTofu.
<h3>Alpine Linux</h3>
For Alpine, you could either install OpenTofu from the Alpine Testing repository or install the apk directly.
To install OpenTofu from the repository you can run the following command:

To install the apk directly, you will first have to download one of the versions from <a href="https://github.com/opentofu/opentofu/releases/latest/" target="_blank" rel="nofollow noopener">here</a>, and run the following command:

You can reference the official OpenTofu docs for more details <a href="https://opentofu.org/docs/intro/install/alpine" target="_blank" rel="noopener">here</a>.
<h3>Ubuntu/Debian</h3>
To add the repositories, you will need to install some tooling, that should be mostly available on Debian systems:

After this, you will need to ensure you have a copy of the OpenTofu GPG key.

When you are done with this, create the OpenTofu source list:

In the end, install OpenTofu by running:

<h3>RHEL/Suse/Fedora</h3>
For rpm based systems, you will first need to create the repo:

If you are using yum, save this to /etc/yum.repos.d/opentofu.repo, and if you are using zipper, save this to /etc/zypp/repos.d/opentofu.repo.
After you have created the repo, run the following commands:

<h3>MacOS</h3>
The OpenTofu package is available in the Homebrew Core repository so you can install it by running the following command:

<h3>Portable Binary – Linux/MacOS</h3>

It is really easy to migrate from Terraform to OpenTofu. At the moment of writing, OpenTofu acts as a drop-in replace for Terraform.
What you need to do to perform the migration is simply install OpenTofu using one of the methods mentioned above that works for your operating system, and after that run:

This will ensure that you will use the OpenTofu registry for your OpenTofu providers.
After that, all of the Terraform commands that you love and use can be performed using the tofu binary.

As OpenTofu was created as a Terraform fork and has backward compatibility with <a href="https://spacelift.io/blog/terraform-version" target="_blank" rel="noopener">Terraform versions</a> up to 1.6, it has the same basic components.
<h3>Provider</h3>
OpenTofu providers are essentially plugins enabling OpenTofu to interact with various infrastructure resources. They serve as a bridge, translating OpenTofu configurations into corresponding API calls, thereby allowing OpenTofu to effectively manage a diverse range of resources in different environments. These providers come equipped with their own unique resources and data sources, which can be managed and set up through OpenTofu.
A common misconception about OpenTofu providers is that they are exclusive to cloud service providers like Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), or Oracle Cloud Infrastructure (OCI). However, this is not the case. OpenTofu providers extend beyond these cloud vendors to include others such as Template, Kubernetes, Helm, Spacelift, Artifactory, VSphere, and Aviatrix, among others.
Each provider is tailored with its specific resources and data sources. For instance, the AWS provider includes resources to handle EC2 instances, EBS volumes, and ELB load balancers, all manageable via OpenTofu.
Example Oracle Cloud Provider

<h3>Resource</h3>
Resources in OpenTofu refer to the infrastructure elements that OpenTofu can manage. This includes, but is not limited to, virtual machines, virtual networks, DNS entries, and pods. Each of these resources is defined by a specific type, such as &#8220;aws_instance,&#8221; &#8220;google_dns_record,&#8221; &#8220;kubernetes_pod,&#8221; or &#8220;oci_core_vcn.&#8221; Additionally, these resources come with a range of configurable properties like instance size or VCN CIDR.
OpenTofu facilitates creating, updating, and deleting these resources. It automatically manages the dependencies among them to ensure they are established in the appropriate sequence. Furthermore, if desired, you can introduce explicit dependencies between certain resources using the &#8220;depends_on&#8221; feature. This capability underscores OpenTofu&#8217;s flexibility and control in handling complex infrastructure setups.
Example resource

<h3>Datasource</h3>
A data source in OpenTofu is a configuration element designed to fetch data from an external source. This data can then be utilized as a parameter within resources during their provisioning. When we mention external sources, we are encompassing a variety of origins such as infrastructure set up manually, and resources established through other OpenTofu configurations, among others.
These data sources are specified within the providers relevant to OpenTofu and are referenced using a distinct block called data. The structure and documentation for a data source closely resemble those of a resource. Therefore, if you&#8217;re already proficient with resource configuration in OpenTofu, adapting to using data sources should be straightforward.
For example, consider a data source that retrieves information about an existing AWS VPC (Virtual Private Cloud). You can define this data source in OpenTofu to gather details such as the VPC&#8217;s ID or CIDR block, which can then be used to configure related AWS resources like subnets or security groups within your OpenTofu configuration. This allows for seamless integration and management of both existing and new infrastructure components.
Example Datasource

<h3>Output</h3>
An output in OpenTofu is a feature that enables you to conveniently view the value of a specific data source, resource, local, or variable after OpenTofu has executed changes to the infrastructure. This output is defined in the OpenTofu configuration file and can be accessed using the opentofu output command, but only after an opentofu apply has been executed. Additionally, outputs can be employed to share various resources within a module.
Outputs don’t rely on any specific provider – they are a unique type of block that operates independently. The key parameters that an output supports include value, where you define what you want to display, and description (which is optional), where you explain the output&#8217;s purpose.
Example Output

<h3>Variable</h3>
OpenTofu variables provide a way to parameterize configuration files, thereby enhancing their flexibility and reusability. These variables are declared in OpenTofu configurations and can be used to input diverse values without modifying the core configuration. For instance, a variable might be used to define the size of a virtual machine, the name of a resource, or the region in which a resource is deployed.
As in all programming languages, when we are defining a variable, we have to assign it a type, or in some cases, it automatically infers a type.
Supported variable types in OpenTofu:
<ul>
<li style="font-weight: 400;" aria-level="1">Primitive</li>
</ul>
&#8211; String
&#8211; Number
&#8211; Bool
<ul>
<li style="font-weight: 400;" aria-level="1">Complex</li>
</ul>
&#8211; List 
&#8211; Set
&#8211; Map
&#8211; Object
<ul>
<li style="font-weight: 400;" aria-level="1">Null – Represents absence</li>
</ul>
There is also the any type, which represents any type of resource, but its usage is not recommended as it will make your code harder to maintain.
Example variables

<h3>Local</h3>
Local variables in OpenTofu are a convenient way of assigning a value to an expression. They are defined into a locals block, and are referenced by prefixing them with a “local”. 
Expanding on this, locals in OpenTofu act as an intermediary layer in your configurations, helping to simplify and clarify expressions. They can be particularly useful for reducing repetition and making your code more readable and maintainable. This capability to define and manipulate a wide range of attributes and operations through locals is essential for crafting efficient and streamlined infrastructure code. It ensures that OpenTofu configurations remain not just functional but also organized and easy to understand, an important consideration in the evolving landscape of infrastructure management.
Example Local

<h3>Provisioners</h3>
OpenTofu provisioners are distinct from providers and serve a different purpose. They allow you to execute various commands or scripts either on your local machine or on a remote machine. Additionally, they enable the transfer of files from your local machine to a remote one. These provisioners are contained within a resource, meaning that to utilize one, you simply need to insert a provisioner block into the specific resource in your OpenTofu configuration.
Provisioners are generally viewed as a measure of last resort within OpenTofu, as they step outside the tool&#8217;s declarative model. This model typically focuses on defining the desired end-state of infrastructure, whereas provisioners perform imperative actions.
OpenTofu includes three main types of provisioners:
<ul>
<li style="font-weight: 400;" aria-level="1">local-exec: Executes commands on the local machine.</li>
<li style="font-weight: 400;" aria-level="1">file: Used for file transfers, typically in conjunction with a connection block for specifying details of the remote machine.</li>
<li style="font-weight: 400;" aria-level="1">remote-exec: Executes commands on a remote machine, also usually used with a connection block for remote access details.</li>
</ul>
Example provisioner

OpenTofu is a valuable tool in the IaC world. It brings several features designed to offer flexibility, efficiency, and a community-driven approach to infrastructure management.
<h3>Open source and community-driven</h3>
One of the foundational aspects of OpenTofu is its open-source nature, ensuring it is freely available and easy to change. This fosters a community-driven development process, where contributions and improvements are sourced from a diverse group of users and organizations. Having OpenTofu under the Linux Foundation umbrella brings several benefits to the product’s well-being and ensures steady development.
<h3>Provider ecosystem</h3>
Similar to Terraform, OpenTofu works with a range of providers that extend its functionality to different technologies and services, including major cloud platforms, databases, and more.
<h3>Execution plans</h3>
Once the infrastructure is defined by the user, OpenTofu generates an execution plan. This plan outlines the actions that OpenTofu will undertake and seeks the user&#8217;s confirmation before proceeding with any modifications to the infrastructure. This critical step allows for a thorough review of the proposed changes, providing an opportunity to confirm or adjust them before OpenTofu executes any operations, such as creation, modification, or deletion of infrastructure components.
<h3>State management</h3>
OpenTofu keeps track of the state of managed infrastructure, ensuring that changes are applied incrementally and consistently. This state management is key to understanding current and past configurations and to planning future changes.
<h3>Modular design</h3>
Giving the ability to organize code as modules promotes reusability, and maintainability, making OpenTofu manage large scale and complex infrastructure easier.

<ul>
<li><a href="https://spacelift.io/blog/why-devops-engineers-recommend-spacelift" target="_blank" rel="noopener">Why DevOps Engineers Recommend Spacelift</a></li>
<li><a href="https://spacelift.io/blog/introducing-spacelift-self-hosted" target="_blank" rel="noopener">SaaS not an Option? Install Spacelift Self-Hosted on AWS</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
</ul>

As with Terraform, you will face some common challenges with OpenTofu, too.

<table>
<tbody>
<tr>
<td>Problem Name</td>
<td>Problem Description</td>
<td>Solution</td>
</tr>
<tr>
<td>State file issues</td>
<td>OpenTofu state file, which tracks infrastructure state, can become out of sync or corrupted</td>
<td>Regularly back up your state file. Utilize OpenTofu’s state management commands for troubleshooting. Consider a remote state backend with state locking for team use</td>
</tr>
<tr>
<td>Complex dependency management</td>
<td>Managing complex dependencies in OpenTofu, especially implicit ones, can be challenging</td>
<td>Explicitly define dependencies with depends_on. Break down large configurations into smaller modules to manage dependencies more effectively</td>
</tr>
<tr>
<td>Version incompatibility</td>
<td>Incompatibilities can occur when using different versions of OpenTofu or provider versions</td>
<td>Standardize a specific version of OpenTofu across your team. Pin specific versions of providers to ensure consistency.</td>
</tr>
<tr>
<td>Configuration drift</td>
<td>The actual infrastructure state may drift from what&#8217;s defined in OpenTofu configurations</td>
<td>Frequently run tofu plan to detect drifts. Apply changes as needed and implement policies to restrict manual changes to infrastructure. Use OpenTofu with Spacelift and do advanced drift detection.</td>
</tr>
<tr>
<td>Multi-env management</td>
<td>Managing OpenTofu configurations across multiple environments (development, staging, production) can be complex</td>
<td>Use separate state files or OpenTofu workspaces for each environment. Parameterize configurations with variables for different environments. Use OpenTofu with Spacelift to facilitate your multi-env management by using different stacks and implementing stack dependencies.</td>
</tr>
</tbody>
</table>

Being the successor of Terraform, OpenTofu inherits many best practices from it, such as:
<ul>
<li>Limit manual changes – Once you use IaC, you should ensure that you limit manual changes, as these changes may incur costly drifts in the future</li>
<li>Modularize your code – Make your code DRY, ensure you can reuse it and maintain a clean an organized structure for your OpenTofu projects</li>
<li>Use remote state – Take advantage of remote state to enhance collaboration between your team members and ensure that there are no parallel operation happening on the same configuration</li>
<li>Use version control – This helps with ensuring that you use a vcs for the source of truth of your code and simplifies tracking changes, collaboration, and reverting to an older version if required</li>
<li>Use variables and outputs – Parametrize your configuration to promote reusability and flexibility. By also leveraging outputs, you can share information about your resources, and even export configurations from modules</li>
<li>Take advantage of loops and conditional – Loops and conditional ensure your code can encompass multiple use cases, and enhance reusability</li>
</ul>

<h3>Import block</h3>
With OpenTofu, importing existing resources is easier than ever. Starting from Terraform 1.5.0, the option of importing resources through an import block has become possible.
The import block requires two parameters: the ID of the resource to be imported and the HCL address for the new resource block. Here&#8217;s a simplified example for an Amazon VPC:

After adding the import block, you can execute a plan for generating the code for the resource. This is done by using:

This generated code can be reviewed and adjusted if necessary, followed by a standard apply operation to complete the import into the state.
<h3>Loops/Conditionals</h3>
Loops and conditional statements are a crucial feature of OpenTofu. Without this capability, OpenTofu, wouldn’t be one of the best solutions on the market for IaC management. 
There are essentially two types of loops you can use directly on a resource:
<ul>
<li style="font-weight: 400;" aria-level="1">for_each</li>
<li style="font-weight: 400;" aria-level="1">count</li>
</ul>
Both achieve the same behavior, but essentially, for_each is looping on a set or a map, and count creates the same resource multiple times, but using a number. 
If you are using count on a variable list, you will face a potential problem: if the list has many elements and you decide, for whatever reason, do delete an element from the middle of the list, every other resource from the middle to the end will get recreated because it changes its index. This is something that can be easily avoided with for_each, as you won’t face any issues with indexes
Example for_each

You can also use for loops when you are building different expressions and you also have the possibility of using if blocks inside of them:

In the above expression, we are cycling through a list of numbers using a for loop, and we are building a list with all of the even numbers by checking if the remainder of the division by two is equal to 0.
Ternary operators are also available in Terraform.

In the above example, we are using a local boolean variable “enable_vpc” and based on it, we will conditionally create vpcs. We are checking if “enable_vpc” is equal to true, and if it is we will create 1 vpc, otherwise we won’t create any vpcs.
<h3>Sensitive/Nonsensitive</h3>
In OpenTofu, the concepts of sensitive and nonsensitive data are used to handle the exposure of potentially confidential or sensitive information in outputs or logs.
You have the option to either use the sensitive parameter on a variable or an output, and you even have two functions available that will mark your data as sensitive or nonsensitive.

The sensitive function takes any value and marks it as sensitive. OpenTofu then treats this value with confidentiality, ensuring it does not appear in logs or output. It is particularly useful when a sensitive value arises from within your module, such as data loaded from a file:

The nonsensitive function takes a sensitive value and returns a copy of it with the sensitive marking removed. This is useful when you&#8217;ve derived a non-sensitive result from a sensitive value and wish to expose it in your output. However, caution is advised since using this function can expose sensitive values if not used appropriately:

<h3>Testing capabilities</h3>
The <code>tofu test</code> command in OpenTofu is designed to facilitate integration testing for your OpenTofu configurations.
How it works in a nutshell:
<ul>
<li style="font-weight: 400;" aria-level="1">Create a testing suite –  Defining a test suite through reading *.tftest.hcl files. These files contain the test definitions</li>
<li style="font-weight: 400;" aria-level="1">Reading Global Input Variables – It reads all global input variables applicable to the entire test suite</li>
<li style="font-weight: 400;" aria-level="1">Execution Order – The test files are sorted alphabetically to establish an execution order</li>
<li style="font-weight: 400;" aria-level="1">Executing Test File –  Each test file in the suite is executed sequentially. Within each test file:</li>
</ul>
&#8211; The run configurations are prepared and validated
&#8211; The tofu plan+apply or tofu apply operations are performed
&#8211; It checks for expected failures
&#8211; Assertion conditions are verified
&#8211; The suite status is updated after each run
<ul>
<li style="font-weight: 400;" aria-level="1">Summary and Cleanup – After executing the tests, OpenTofu prints out summaries for each test file and for each run. It then attempts to destroy the resources provisioned by each run in reverse order, ensuring clean-up of the testing infrastructure.</li>
<li style="font-weight: 400;" aria-level="1">Termination Status – The command exits with a status code 0 if all tests passed or 1 if any tests failed​</li>
</ul>
Read more on how to define tests <a href="https://opentofu.org/docs/cli/commands/test/" target="_blank" rel="noopener">here</a>.

OpenTofu has its own registry for providers and modules. The <a href="https://opentofu.org/docs/internals/provider-registry-protocol">provider registry protocol</a> and the <a href="https://opentofu.org/docs/internals/module-registry-protocol">module registry protocol</a> are systems used by OpenTofu to discover details and install providers and modules.
Providers are uniquely identified by addresses formatted as hostname/namespace/type. This protocol supports versioning, where each provider address is associated with multiple versions following Semantic Versioning conventions. Service discovery begins with the OpenTofu CLI querying a hostname to locate providers, which is essential for ensuring compatibility with specific OpenTofu versions and platforms. The protocol also outlines the necessary steps for listing available versions of a provider and retrieving provider packages, including download URLs and necessary metadata like checksums and signing keys, so make sure to check it out to view some usage examples.
Modules, on the other hand,  are identified by a specific address format (hostname/namespace/name/system), with each address containing multiple versions following Semantic Versioning. The protocol includes steps for listing available module versions and retrieving specific module versions for download as in the provider case. You will also need to check the documentation to view some usage examples. It also provides a service discovery mechanism, where the CLI uses a hostname to locate modules. This approach facilitates the management and distribution of modules in a structured and efficient manner.

OpenTofu is supported natively within Spacelift. 
To see how easy it is to use it, check out this <a href="https://spacelift.io/blog/introducing-custom-workflows" target="_blank" rel="noopener">article</a>.

OpenTofu’s first stable release is here. You can easily install it and the migration from Terraform is pretty straightforward. With OpenTofu you get all the advantages that Terraform offers, and judging by the fact that it is open source and under the Linux Foundation umbrella, you get what Terraform never had – a community-first development approach.
Terraform and OpenTofu are on feature parity right now, but they will most likely drift in the future, and you will have to choose the IaC tool to use.
If you want to take your OpenTofu workflow to the next level, you can use Spacelift. <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">Create a free account today</a> or <a href="https://spacelift.io/schedule-demo" target="_blank" rel="noopener">book a demo with one of our engineers</a>.

Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.

Why OpenTofu is a Good Choice for IaC Adopters

Why Should You Switch to OpenTofu?

10 Popular Terraform Alternatives You Should Know in 2024

In this step by step tutorial, you will learn how to use OpenTofu. Follow the installation guide and see the key features and components. 

321-opentofu-tutorial

OpenTofu Tutorial

OpenTofu Tutorial: Getting Started, How to Install & Examples

OpenTofu is growing up fast! Born when Terraform shifted to a Business Source License (BSL) in August 2023, this community-driven open-source fork of Terraform has matured into a powerful, production-ready, infrastructure-as-code tool in under five months. 
A lot has happened in that time, so let’s recap the milestones and remind you of the benefits of switching to OpenTofu. We will also explain how to install OpenTofu and provide some valuable resources for making the most of this drop-in replacement for Terraform.

OpenTofu (formerly OpenTF) began life as a fork of Terraform after Hashicorp announced in August 2023 that it was adopting a BSL for Terraform, which had always been open source. Support for the initiative was massive and immediate, with the <a href="https://opentofu.org/manifesto/" target="_blank" rel="noopener">OpenTofu manifesto</a> garnering 30,000 GitHub stars by the end of August. In September, <a href="https://spacelift.io/blog/opentofu-joins-the-linux-foundation" target="_blank" rel="noopener">OpenTofu joined the Linux Foundation</a>, ensuring the tool would remain neutrally housed with impartial governance and community oversight. Alpha and beta versions soon followed, with the first stable release candidate coming out in December 2023. 
<a href="https://opentofu.org/supporters" target="_blank" rel="noopener">OpenTofu is supported by more than 150 companies</a>, four of whom have committed to covering the cost of FTEs to work on the project, Spacelift is one of those companies, and we are members of the project’s steering committee, together with representatives from Scalr, Gruntwork, Harness, and env0. Hundreds of individuals also support OpenTofu, inspired by its simple mission of keeping Terraform open-source always.

opentofu-stable-release-video

OpenTofu is a logical choice for anyone <a href="https://spacelift.io/blog/why-should-you-switch-to-opentofu" target="_blank" rel="noopener">switching from Terraform</a> or <a href="https://spacelift.io/blog/opentofu-for-infrastructure-as-code" target="_blank" rel="noopener">adopting the infrastructure-as-code (IaC) approach</a> for the first time. Its benefits include:
<ul>
<li style="font-weight: 400;" aria-level="1">Stability: OpenTofu is a member of the Linux Foundation, which not only ensures input from a large community of open-source experts, practitioners, and users, but also provides peace of mind that OpenTofu will remain stable and continue to grow and improve. </li>
<li style="font-weight: 400;" aria-level="1">Community support: The endorsement of so many companies and individuals provides strong community-driven backing. This community will drive OpenTofu in the right direction, guided by impartial governance and oversight. </li>
<li style="font-weight: 400;" aria-level="1">Dynamic project: As an open-source, community-driven initiative, OpenTofu offers exciting potential for contributors to make a real difference. This will help the project grow and adapt in line with users’ needs.   </li>
</ul>

Starting with OpenTofu involves a few key steps:
<ul>
<li>Installation: Install OpenTofu using the method appropriate to your operating system.</li>
<li aria-level="1">Configuration: After installing OpenTofu, you can use it as it is, but you can also configure it to suit your specific needs. This might include setting up user preferences or installing and configuring other tools that may integrate with your OpenTofu repositories.</li>
<li aria-level="1">Exploring OpenTofu features: Familiarize yourself with the features and capabilities of OpenTofu, such as its CLI and any unique functionalities it offers.</li>
<li aria-level="1">Dive into the documentation: Consult the OpenTofu documentation for detailed guidance on its usage, troubleshooting, and advanced configurations.</li>
</ul>
Supporting resources: 

<ul>
<li style="font-weight: 400;" aria-level="1"><a href="https://opentofu.org/" target="_blank" rel="noopener">Webpage</a></li>
<li style="font-weight: 400;" aria-level="1">Blog posts:</li>
</ul>
&#8211; <a href="https://spacelift.io/blog/what-is-opentofu" target="_blank" rel="noopener">What Is OpenTofu</a>
&#8211; <a href="https://spacelift.io/blog/opentofu-for-infrastructure-as-code" target="_blank" rel="noopener">Why OpenTofu is a Good Choice for IaC Adopters</a>
&#8211; <a href="https://spacelift.io/blog/why-should-you-switch-to-opentofu" target="_blank" rel="noopener">Why should you switch to OpenTofu</a>
<ul>
<li style="font-weight: 400;" aria-level="1">Videos:</li>
</ul>
&#8211; <a href="https://www.youtube.com/watch?v=FbPmicb3Wpg" target="_blank" rel="nofollow noopener">Migrating from Terraform to OpenTofu</a>
<ul>
<li aria-level="1"><a href="https://opentofu.org/docs/intro/install" target="_blank" rel="noopener">Download OpenTofu</a></li>
<li aria-level="1"><a href="https://github.com/opentofu/opentofu/releases" target="_blank" rel="nofollow noopener">OpenTofu stable release</a></li>
</ul>

You can install OpenTofu using various methods, depending on the operating system: 
<h3>Alpine Linux</h3>
For Alpine, you can either install OpenTofu from the Alpine Testing repository or install the apk directly.
To install OpenTofu from the repository, run the following command:

Refer to the <a href="https://opentofu.org/docs/intro/install/alpine" target="_blank" rel="noopener">official OpenTofu docs</a> for more details.
<h3>Ubuntu/Debian</h3>
To add the repositories, you will need to install some tooling that should be mostly available on debian systems, ensure you have a copy of the OpenTofu GPG key, and create the OpenTofu source list as described <a href="https://opentofu.org/docs/intro/install/deb" target="_blank" rel="noopener">here</a>.
After that, install OpenTofu by running:

<h3>RHEL/Suse/Fedora</h3>
For rpm-based systems, you will first need to create the repo, as shown <a href="https://opentofu.org/docs/intro/install/rpm" target="_blank" rel="noopener">here</a>.
If you are using yum, save this to /etc/yum.repos.d/opentofu.repo, and if you are using zipper, save this to /etc/zypp/repos.d/opentofu.repo.
After you have created the repo, run the following commands:

To check out other ways to install OpenTofu, check out the installation guides from the <a href="https://opentofu.org/docs/intro/install/" target="_blank" rel="noopener">official OpenTofu installation guide</a>.

Join us on February 1 for <a href="https://www.linkedin.com/events/7150905525172420609/" target="_blank" rel="nofollow noopener">OpenTofu Unpacked</a>, a free webinar featuring contributions from some of OpenTofu&#8217;s founder members. This event will be invaluable for anybody seeking to get the most from OpenTofu, offering expert insights for those who believe in an open-source future for infrastructure as code.
And if you are looking for a reliable partner who can help you train your team, accelerate your migrating, and help with all of your OpenTofu workloads, Spacelift has some helpful resources. Spacelift is one of the founding members of the OpenTofu initiative, and, apart from supporting OpenTofu natively as part of the platform, it offers native and commercial support to ensure your OpenTofu workflows run smoothly.

opentofu-stable-release

opentofu stable release

Read more about Spacelift’s professional services <a href="https://spacelift.io/opentofu" target="_blank" rel="noopener">here</a>.

OpenTofu’s first stable release is here, and it is production-ready. The logical choice for anybody looking for a stable, community-driven, open-source alternative to Terraform, OpenTofu is available to install on a variety of operating systems:
<ul>
<li style="font-weight: 400;" aria-level="1">Alpine Linux</li>
<li style="font-weight: 400;" aria-level="1">Ubuntu/Debian</li>
<li style="font-weight: 400;" aria-level="1">RHEl/Suse/Fedora</li>
<li style="font-weight: 400;" aria-level="1">Linux</li>
<li style="font-weight: 400;" aria-level="1">MacOS </li>
</ul>
Founding partner Spacelift offers native and commercial support for all your OpenTofu needs.

Why DevOps Engineers Recommend Spacelift

OpenTofu Tutorial - Getting Started, How to Install & Examples

OpenTofu: Open-Source Alternative to Terraform

OpenTofu’s first stable release is here, and it is production-ready. See the recap the milestones and the benefits of switching to OpenTofu.

319-opentofu-release

OpenTofu Stable GA Release

OpenTofu Stable GA Release: Get Ready to Install!

Things move fast in the world of OpenTofu. Just two weeks ago we announced that <a href="https://spacelift.io/blog/opentofu-joins-the-linux-foundation" target="_blank" rel="noopener">the initiative had joined the Linux Foundation</a>. Now, we’re excited to be launching <a href="https://github.com/opentofu/opentofu/releases/tag/v1.6.0-alpha1" target="_blank" rel="nofollow noopener">OpenTofu’s first alpha release</a>! Even better, this OpenTofu release is a drop-in replacement, so developers and engineers can integrate it into their workflow quickly and easily. You can immediately start testing it out on all your current projects — and the best part? There&#8217;s absolutely no need to alter or adjust any part of your existing codebase! It&#8217;s designed to effortlessly fit right in.

Whether you are <a href="https://spacelift.io/blog/why-should-you-switch-to-opentofu" target="_blank" rel="noopener">switching from Terraform</a> or you’re <a href="https://spacelift.io/blog/opentofu-for-infrastructure-as-code" target="_blank" rel="noopener">adopting the infrastructure-as-code (IaC) approach</a> for the first time, Open Tofu offers some compelling benefits:
<ul>
<li style="font-weight: 400;" aria-level="1">Stability: Membership of the Linux Foundation ensures stability and growth for OpenTofu. Furthermore, the support of a large community of experts, practitioners, and users behind this open-source initiative guarantees the expertise and resources required to maintain a solid pace for improvements and new feature implementation.</li>
<li style="font-weight: 400;" aria-level="1">Community-driven initiative: The backing of a large community will ensure OpenTofu proceeds in the right direction, influenced by a variety of different backgrounds, views, and expectations. </li>
<li style="font-weight: 400;" aria-level="1">Dynamic roadmap and development: Open-source, community-driven projects like OpenTofu offer the unique potential for users to make a real difference, helping it grow and influencing its direction.  </li>
</ul>

Now that OpenTofu 1.6 has been released, you can easily migrate to OpenTofu with Spacelift. There is full compatibility in the code, how state files are managed, and the runtime, so migration could not be easier; The process is as simple as switching the binaries to execute the IaC template. It might take more work if you use an older version of Terraform, but it will still involve the same process as switching between old and new versions of Terraform.
Release notes are also available in the release link.
This short video shows how seamless the migration process is:

migrate-to-opentofu-player

OpenTofu uses a registry hosted by the OpenTofu team that properly resolves all public providers and modules. However, it&#8217;s worth noting that this registry is in its early days and hasn&#8217;t reached full stability. In these initial phases, there might be occasional hiccups or issues with availability. The OpenTofu team doesn’t recommend it for production use cases just yet. The design process will start soon, and participation from the community is highly encouraged.

Diving into the features of the alpha version, it also introduces the 1.6 testing feature. This isn&#8217;t just any regular testing tool; it&#8217;s meticulously crafted to mirror legacy Terraform’s testing capabilities. The primary aim is to ensure that users experience a smooth, hitch-free transition. It doesn&#8217;t stop at merely matching the legacy capabilities; it takes it a step further by integrating bug fixes and enhancements that refine the process.

As a Spacelift customer, you don’t need to change anything in your code to move to OpenTofu. It works as a drop-in replacement. Spacelift supports OpenTofu natively through the Workflow tool – simply select OpenTofu and you are good to go.

opentofu-alpha-spacelift

opentofu alpha spacelift

You also have the option to change your existing Terraform Stack to use the OpenTofu backend, just by going to Settings → Backend, and changing the Workflow tool to OpenTofu:

opentofu-alpha-spacelift-workflow-tool

opentofu alpha spacelift workflow tool

This release isn&#8217;t just about direct functionality. It is also a call to developers and open-source enthusiasts contributing to third-party tools that work with legacy Terraform. The release provides a golden opportunity to adapt and upgrade third-party tooling, ensuring they&#8217;re fully compatible and supportive of the OpenTofu ecosystem. This proactive approach ensures a more cohesive and integrated experience for users down the line.

The <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu initiative</a> is part of the Linux Foundation and is also applying to join the Cloud Native Computing Foundation. It has huge support, with more than 18 full-time equivalents (FTEs) from four companies committed to the project and the broad backing of over 140 companies. The project’s steering committee includes representatives from Spacelift, Scalr, Gruntwork, Harness, and env0.

Visit the  <a href="https://github.com/opentofu/opentofu" target="_blank" rel="nofollow noopener">OpenTofu repo and check out the issues</a> to see what kind of conversations and feature suggestions are coming up. You can also join the <a href="https://communityinviter.com/apps/opentfcommunity/opentofu" target="_blank" rel="nofollow noopener">Slack community</a>. 
Remember OpenTofu is, and will always remain truly open source, community-driven, and impartial, and the OpenTofu team greatly values feedback from the community,  believing that constructive feedback plays an instrumental role in refining and enhancing OpenTofu’s capabilities. Taking it for a test drive not only gives you a firsthand experience of its features but also provides an opportunity to contribute to its evolution. 
Be part of the OpenTofu journey.

<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.&quot;}" data-sheets-userformat="{&quot;2&quot;:769,&quot;3&quot;:{&quot;1&quot;:0},&quot;11&quot;:4,&quot;12&quot;:0}">Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.

Self-Service Infrastructure with Spacelift

The first alpha release of OpenTofu is out! See what's new and how you can start testing it out on your projects.

281-opentofu-alfa

OpenTofu Alpha Release

OpenTofu Alpha Release: No Code Changes Required!

Paweł Piwosz

August 10, 2023, was a day to remember for anybody who works with infrastructure as code (IaC). On that day HashiCorp changed from an MPL license to a BUSL one for their products, including Terraform. I discussed some of the implications of these changes in the article <a href="https://spacelift.io/blog/opentofu-for-infrastructure-as-code" target="_blank" rel="noopener">Why OpenTofu is a Good Choice for IaC Adopters</a>.
This move and the emergence of the OpenTofu initiative raise a couple of very important questions:
1. Should I move to OpenTofu? 
2. If yes, why?
You’ll find the answers in this post.

Before we go into the reasons why you should move to OpenTofu, let’s discuss the potential impact of the license change on your work. The common perception is “I am a simple user, the license change doesn’t affect me.” In the short term, you might be right, but let’s decouple potential scenarios here:
<ul>
<li>The license itself doesn’t indicate with 100% clarity if you are a competitor or not. This is the licensor’s decision. Imagine you are a consultant who works on a project for a third party. You help them to build infrastructure, and you manage all supporting elements of it — including state file. Because you are paid for this service, you could be viewed as competition. But from another perspective, you are also a user of the tool. You don’t know which is the case. And this is the biggest gray area behind BUSL licenses.</li>
<li>Permission to use the software might be withdrawn without warning. Again, this is the licensor’s decision.</li>
<li>The license may be changed. Developing the previous topic further, the licensor may confirm you are eligible to use the software under BUSL, but how the BUSL is built allows the licensor to change the conditions at any time.</li>
</ul>
These examples illustrate just how risky it is to use the tool under a BUSL license, which jeopardizes the long-term safety of your SDLC. Many use cases do not violate a BUSL license, but other factors come into play, which we will discuss later.

The short answer to this question is: Yes, Spacelift supports previous and current versions of Terraform (v.1.5.5) without any change. The license change cannot be applied backward, so what was published under the MPL license stays open-source. The new BUSL license applies to any change made after HashiCorp’s announcement.

Here are three potential ways to work with Terraform now and into the future:
<ul>
<li>If you are using Terraform 1.5.5 or lower, you can use Spacelift, and your process doesn’t change. If you plan to upgrade to a newer version, your options are outlined later in this post. Your workloads with Terraform versions up to and including 1.5.5 will work as before, and there is no change from a legal perspective. Spacelift continues to work on features, improvements, and all the elements that make Spacelift the best tool in the field.</li>
<li>If you are considering migrating to newer versions of Terraform (1.6 and more recent versions yet to be published), Spacelift is working on options to ensure support. The Spacelift team will publish information about this in a transparent way and communicate it to our customers.</li>
<li>Migration to OpenTofu is an option for you. Switching from Terraform to OpenTofu is currently as easy as changing the binary. As time progresses, migration may require more actions on your side, but you can rest assured that OpenTofu will supply you with all the support you’ll need.</li>
</ul>

Migration to OpenTofu delivers multiple advantages. Let’s list them in three categories — continuity, stability, and progress.
<ul>
<li>Continuity
<ul>
<li>OpenTofu is currently 100% backward compatible with Terraform. It will remain backward-compatible with version 1.6 of OpenTofu.</li>
<li>Migration itself is simple and straightforward. It is largely just a binary change.</li>
<li>Support of the community is big and growing. At this point, the manifesto has been signed by almost 150 companies and more than 700 individuals.</li>
<li>Growth is stable. More than 20 engineers have pledged to work on the OpenTofu ecosystem.</li>
</ul>
</li>
</ul>
<ul>
<li>Stability
<ul>
<li>OpenTofu has been donated to <a href="https://www.linuxfoundation.org/" target="_blank" rel="nofollow noopener">Linux Foundation</a>, which ensures open-source stability.</li>
<li>Being under the control of the Linux Foundation ensures that OpenTofu remains open-source.</li>
<li>As a truly open-source project, OpenTofu intends to build the best IaC tool and ecosystem in the industry.</li>
</ul>
</li>
</ul>
<ul>
<li>Progress
<ul>
<li>Having 20+ engineers working on the project ensures stable progress and the implementation of new functionalities.</li>
<li>As the heart of this open-source project, the community will have an important voice in the direction of improvements. You can share this voice and have a real impact on OpenTofu’s roadmap and feature implementation.</li>
<li>With community support, engagement, and vision, OpenTofu will respond to requests to ensure the best alignment with the market’s needs.</li>
</ul>
</li>
</ul>

Now that OpenTofu 1.6 has been released, the migration from Terraform to OpenTofu is easy and seamless. There is no incompatibility in the code, how state files are managed, or the runtime. Therefore, switching between these two tools is very easy from the project&#8217;s outset.
If you decide to switch between your organization’s current Terraform run and OpenTofu v.1.6, the migration is as simple as switching the binaries to execute the IaC template. 
Of course, it might involve more work if you use a relatively old version of Terraform, but it will follow the same process as switching between old and new versions of Terraform.
However, this might change in the future. Terraform and OpenTofu will implement fixes, new features, etc., which might require more work to migrate state and code.
OpenTofu’s first stable release is here, and it is production-ready. Check out <a href="https://spacelift.io/blog/opentofu-stable-ga-release" target="_blank" rel="noopener">our overview of what’s new</a>.

Yes, of course! Spacelift was one of the first companies to join the initiative and is one of the founding members. The OpenTofu platform has our full support, and we are engaged in the project’s development. This ensures almost native binding between Spacelift and OpenTofu.
The OpenTofu is a brand-new initiative, so you are bound to have questions. For more information, <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">contact the OpenTofu Initiative</a> through its webpage. To add your support, give a GitHub star to the <a href="https://github.com/opentofu" target="_blank" rel="nofollow noopener">OpenTofu repositories</a>, or add your pledge to the list of supporters!
OpenTofu will only be as strong as the community behind it. You can join that community and show your support by contributing to the public repository on GitHub. This <a href="https://github.com/opentofu/opentofu/blob/main/CONTRIBUTING.md" target="_blank" rel="nofollow noopener">contribution document</a> explains how.

Why You Need Self-Service Infrastructure

How to Migrate From Terraform Cloud to Spacelift

The emergence of the OpenTofu initiative raises a couple of very important questions: should I move to OpenTofu and why. You’ll find the answers in this post.

277-terraform-to-opentofu

Why should you switch to OpenTofu?

In this article, we examine the reasons why the OpenTofu initiative is worth exploring for organizations about to adopt infrastructure as code (IaC). 
Deciding which tool to select depends on the company’s expertise, skills available on the market, the technology stack in use, limitations in existing processes, and many other factors. Furthermore, people in different positions will have different perspectives. We discuss the viewpoints of CTOs, architects, and decision-makers.

IaC has been available for many years, but the approach has not been adopted as widely as you might expect. According to a <a href="https://cd.foundation/state-of-cd-2023/" target="_blank" rel="noopener">State of CD report</a>, only 27% of respondents used IaC last year. With <a href="https://www.gminsights.com/industry-analysis/infrastructure-as-code-market" target="_blank" rel="noopener">Global Market Insights Inc</a>’s report predicting more than 20% yearly growth, however, it is clear that many companies are considering it.
IaC is a vital element of DevOps adoption. With Lean and Automation (elements of the CALMS framework), DevOps aims to automate processes and increase productivity and stability.

MPL (<a href="https://spdx.org/licenses/MPL-2.0.html" target="_blank" rel="noopener">Mozilla Public Licence</a>) is a type of open-source license. Software under this license can be used for private and commercial projects without any limitations (at least, for the case we discuss here). 
BUSL (<a href="https://spdx.org/licenses/BUSL-1.1.html" target="_blank" rel="noopener">Business Source License</a>), on the other hand, limits the use of the software. The software under this license will be open-source eventually.
The BUSL license is a parametrized one. There are some specific elements which can be parametrized: 

<ul>
<li>Restriction on usage 
</li>
<li style="font-weight: 400;" aria-level="1">Change date</li>
<li style="font-weight: 400;" aria-level="1">Open-source license after change date</li>
</ul>
The fact that these parameters can be changed and “adapted” as the licensor wishes is exactly the issue the community raises every time companies change a license to BUSL. 
The main charge against BUSL is that its terms are unspecific and can be used in an opaque way as the licensor chooses. This prompts uncertainty about how and when software can be used.

<h3>Can I use the tool?</h3>
There are two aspects to this question: First, as I already mentioned, the BUSL license is rather vague in its construct, and the parameters can be changed without warning. Second, but equally important, is the potential to use the tool inside a wider platform. 
 
For example, if I use vendor X to host my applications, can I use product Y there? This means that if you are using more than one vendor, you need to ensure you can use specific tools with others before you can be confident you control the whole toolset. 
Let me give two examples here: 

<ol>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.fedoraproject.org/en-US/legal/not-allowed-licenses/" target="_blank" rel="noopener">Fedora</a> disallows software under BUSL license</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://blogs.vmware.com/management/2023/08/aa-august-release.html" target="_blank" rel="noopener">VMware Aria</a> disallows use of Terraform in higher versions than 1.5.5 (the last one with MPL license)</li>
</ol>
It is important to understand that a BUSL license might impact many more entities in the industry, even common users.

<h3>What does the change mean for different IT roles?</h3>
Let’s look at the impact of this change and why OpenTofu might be a good choice for you, depending on the specific role you play in the organization:
<h4>Architect</h4>
Contemporary architecture roles cover multiple areas, but solution, cloud, system, application, and enterprise architects must consider several factors that are not directly technical — including the licenses of any software they propose and incorporate into architecture. We have already discussed two examples where licensing might have a significant impact on the selected toolset.
If we’re looking at usability from the perspective of support and community, we only have to look at the community response to the OpenTofu initiative. Its manifesto already has more than 35,000 stars (rating on GitHub), and the OpenTofu fork of Terraform earned more than 15,000 stars. This shows the industry’s huge support and interest. 
Engagement with the new initiative also encourages architects to be confident of the project’s future. 
<h4>Security Officer</h4>
As a person responsible for security in the organization, you have to examine a solution’s security, but you should also assess the software’s license modeling and maintenance. OpenTofu can support you in this respect. The MPL license is less restrictive than the BUSL, and it secures a company’s usage without extensive legal checks. The fact that the initiative is community-driven allows security specialists in the community to propose their changes (through the <a href="https://github.com/opentofu/opentofu/blob/main/CONTRIBUTING.md" target="_blank" rel="nofollow noopener">RFC process</a>) and ensure that best practices regarding security are being followed.
<h4>Chief Technical Officer (CTO)</h4>
As CTO of the organization, your role is not only to manage the current situation but also to consider the future. This is where the OpenTofu initiative gives you the edge for projects. 
The reasons are as follows: 

<ul>
<li style="font-weight: 400;" aria-level="1">It is a truly open-source project, under the Linux Foundation umbrella. This ensures stability for the effort. The Linux Foundation (directly or through their foundations) drives many projects used on a daily basis. Here are just a few of them: foundations like the CNCF and CD Foundation; software like ArgoCD, ETCD, Xen Project, Jenkins, Spinnaker, Istio, Prometheus, and Kubernetes; plus standards like SPDX and many more. This list should answer the question, “Is open-source really for me?”</li>
<li style="font-weight: 400;" aria-level="1">It has overwhelming support from the community. This means OpenTofu can set standards for future approaches to IaC.</li>
<li style="font-weight: 400;" aria-level="1">Its open-source status means the project can be used to build competing platforms. Nothing is better for growth than healthy competition, which introduces new features and solutions to the ecosystem.</li>
</ul>
As CTO, you must answer two questions for yourself: 

<ol>
<li style="font-weight: 400;" aria-level="1">Is this something that is good to use today?</li>
<li style="font-weight: 400;" aria-level="1">Is it something that will be a good choice for the next one, two, or five years? </li>
</ol>
I believe the answer to both questions is “Yes, indeed, it is.”

<h3>Open-source support</h3>
The large community of experts, practitioners, and users behind this open-source initiative will have a huge impact on the solution. The stewardship of organizations like the Linux Foundation guarantees stability and growth, and community backing ensures the knowledge and resources needed to establish a good pace for improvements and new feature implementation.
<h3>Community-driven initiative</h3>
Not only does a community provide the potential to build the ecosystem, but it also drives it in the right direction. Involving different backgrounds, views, and expectations creates a healthy space to exchange experiences and build a project ready for adoption.
<h3>Impact on roadmap and development</h3>
The power of open-source, community-driven projects like OpenTofu lies in the fact that you can join the initiative, help it grow, and impact its direction.

If you are about to enter the IaC world, compatibility with the existing Terraform ecosystem shouldn&#8217;t be a major concern. You are joining a new community eager to grow fast, which should be reassuring for the future. 
The ecosystem for OpenTofu is built by the community, which means every single person or company involved can have a role. 
OpenTofu has only one agenda: to build a thriving ecosystem around the IaC toolset that embraces progress in how infrastructure is developed, deployed, and maintained.
OpenTofu stays backward compatible with Terraform. How this will be maintained in the future depends on the supporting community and steering committee under the umbrella of the Linux Foundation.
OpenTofu will only be as strong as the community behind it. You can join that community and show your support by contributing to the public repository on GitHub. This <a href="https://github.com/opentofu/opentofu/blob/main/CONTRIBUTING.md" target="_blank" rel="nofollow noopener">contribution document</a> explains how.
OpenTofu’s first stable release is here, and it is production-ready. Check out <a href="https://spacelift.io/blog/opentofu-stable-ga-release" target="_blank" rel="noopener">our overview of what’s new</a>. See the most important questions about <a href="https://spacelift.io/blog/what-is-opentofu" target="_blank" rel="noopener">OpenTofu</a>.

Crossplane vs Terraform - IaC Tools Comparison

Pulumi vs. Terraform : Key Differences and Comparison

Why Generic CI/CD Tools Will Not Deliver Successful IaC

In this article we'll go over the reasons why the OpenTofu initiative is worth exploring for organizations about to adopt infrastructure as code (IaC)

276-opentofu-infrastructure-as-code

The announcement of OpenTofu has prompted many questions, as people want to understand more about what is going to happen in the world of infrastructure as code (IaC). Terraform has been essential in the last couple of years, and many companies have adopted it due to its open-source nature.
In this post, we will answer some of the most important questions about OpenTofu that we have seen in different channels.

<a href="https://opentofu.org/" target="_blank" rel="noopener">OpenTofu</a> is a Terraform fork, created by the initiative of OpenTF supported by Gruntwork, Spacelift, Harness, Env0, Scalr, and others, as a response to HashiCorp’s switch from an open-source license to the BSL. OpenTofu is an open-source version of Terraform and a viable alternative to HashiCorp’s Terraform that will expand on Terraform’s existing concepts and offerings. 
OpenTofu was forked from Terraform version 1.5.6. and retained all the features and functionalities that had made Terraform popular among developers, while also introducing improvements and enhancements. The project is now a part of the Linux Foundation, with the ultimate goal of joining the Cloud Native Computing Foundation (CNCF).
OpenTofu’s first stable release is here, and it is production-ready. Check out <a href="https://spacelift.io/blog/opentofu-stable-ga-release" target="_blank" rel="noopener">our overview of what&#8217;s new</a>.

BUSL is an alternative type of license to open-source and closed-source, giving public access to the source code of a tool and ensuring the non-production use case of that code is always free of charge. Owners of the tools may decide to grant a so-called Additional Use Grant and allow specific cases of production use as well. 

In this regard, HashiCorp decided to allow production use of its tools as long as “such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp&#8217;s products.” If this exception applies to your use of the tools, a specific license grant from HashiCorp is needed and might be subject to additional restrictions at HashiCorp’s discretion.

OpenTofu was created to ensure the Terraform ecosystem continues to flourish into the future. It was created by the OpenTF initiative in response to HashiCorp’s change to the BSL.
The ambiguity of the BUSL and the additional use grant outlined by the HashiCorp team makes it difficult for companies, vendors, and developers using Terraform to determine whether their actions could be viewed as falling outside of the permitted scope of use. 
Hashicorp’s FAQs offer some reassurance to end users and system integrators for now, but questions arise over the licensing terms’ implications for future usage. The potential for changes to the company’s definition of “competitive” or “embedding” or further modifications to the license to make it closed source creates uncertainty for Terraform users. 
We strongly believe that Terraform should stay open-source, as it is a project used by many companies, and many people have contributed to getting Terraform where it is today. Terraform wouldn’t be as successful as it is without the community’s effort in building many supporting projects around it.

No, Terraform will cease to be open source. Everything created before version 1.5.x stays open-source, but new versions of Terraform are placed under the BUSL license. 
You will still have access to the public source code, but if your use falls outside of the additional use grant, you won’t be able to use it for commercial purposes without receiving a special license grant based on an individual agreement with HashiCorp. Security patches for the MPL version will be provided until the end of December 2023.

Yes, OpenTofu is an open-source version of Terraform. It was forked from Terraform version 1.5.6.
<a href="https://opentofu.org/manifesto" target="_blank" rel="noopener">OpenTofu’s manifesto</a> presented HashiCorp with two options:
<ol>
<li style="font-weight: 400;" aria-level="1">Switch Terraform back to an open-source license</li>
<li style="font-weight: 400;" aria-level="1">Create a fork of Terraform that will be placed in a Foundation</li>
</ol>
As the first option wasn’t taken into consideration, OpenTofu was created to make sure the fork of Terraform will be developed and maintained and remain an open-source tool, forever.

OpenTofu is backed and supported by an enormous community of large companies, projects, and individuals. The founding companies and initial maintainers of OpenTofu are: Spacelift, Harness, Gruntwork, Env0, and Scalr. 
The current community size behind OpenTofu initiative:
<ul>
<li style="font-weight: 400;" aria-level="1">Almost 144 Companies</li>
<li style="font-weight: 400;" aria-level="1">Over 10 Projects</li>
<li style="font-weight: 400;" aria-level="1">Over 718 Individuals</li>
</ul>
The <a href="https://github.com/opentofu/manifesto" target="_blank" rel="nofollow noopener">manifesto repository</a> has over 30k stars.
<a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu’s repository</a> has over 6k stars.
Numerous engineers from various companies, including some that compete with each other, have collaborated over the past week to bring OpenTofu to life.
Some of these companies, such as Spacelift, have even pledged to cover the costs of multiple full-time engineers to ensure the tool stays open-source. Spacelift will cover the costs for five full-time engineers for a period of at least five years.
Gruntwork, the creators of Terragrunt and Terratest, two of the most popular tools inside the ecosystem, have pledged resources to ensure the healthy development of OpenTofu.
OpenTofu is a part of the Linux Foundation. Having a foundation responsible for the project ensures the tool stays vendor-neutral.

OpenTofu is published under the Mozilla Public License (MPL). 
Publishing software under MPL means that it is open source, can be freely used, modified, and distributed. MPL requires any modifications made to the code to be available under the same license.

There are not any differences between Terraform (versions prior to 1.5.x) and OpenTofu, but this will change as new versions emerge. Initially, it works exactly the same as Terraform, with OpenTofu being a drop-in replacement for it. OpenTofu does not have its own providers and modules, but it uses its own registry for them.
Learn more in our <a href="https://spacelift.io/blog/opentofu-tutorial" target="_blank" rel="noopener">OpenTofu tutorial</a>.

OpenTofu works with an existing state file, up to state files created with a version prior to Terraform’s 1.5.x.

Key advantages of using OpenTofu instead of Terraform:
<ul>
<li style="font-weight: 400;" aria-level="1">Open-source nature: There are no restrictions on how you can use OpenTofu, either for commercial or personal use. The open-source nature of OpenTofu embodies the principles of openness and collaboration that characterize the tech community.</li>
<li style="font-weight: 400;" aria-level="1">Dynamic community: Developer contributions will make the project more robust and adaptable to different use cases. Bugs and issues will be identified and resolved quickly to ensure reliability and stability.</li>
<li style="font-weight: 400;" aria-level="1">Fast, reliable support: The growing community behind OpenTofu not only gives everyone the opportunity to influence the development of new features, but it also supplies the resources to ensure these features and bug fixes will be introduced rapidly.</li>
<li style="font-weight: 400;" aria-level="1">Minimal risk: OpenTofu is published under MPL and is a part of the Linux Foundation (with the goal of joining CNCF), which provides the guarantee the tool remains truly open-source, forever.</li>
</ul>
Let’s understand the reasons that different personas may have in using OpenTofu instead of Terraform:
<ul>
<li style="font-weight: 400;" aria-level="1">Personal Use – At first glance, for personal use, you could use either OpenTofu or Terraform, as there are no restrictions in the BUSL license for non-commercial use cases. That is subject to change as the Terraform ecosystem becomes more and more fragile, and a switch to another license is possible. Adopting OpenTofu for personal use is easy if you already know Terraform, so there aren’t any knowledge gaps, at least in the beginning.</li>
<li style="font-weight: 400;" aria-level="1">Consultants – As a consultant, one of your responsibilities is to offer your clients the best possible solution based on their budget. As OpenTofu is on par with Terraform’s versions up to 1.5.x and one of the project’s key missions is to listen to the community’s issues, it is advisable to recommend a project that will always stay open-source. If you have used Terraform in the last eight years, you have probably encountered issues that took considerable time to be resolved. Given the sheer number of people involved in developing OpenTofu, this will no longer be the case.</li>
<li>Companies – Companies may find the situation more problematic. Switching to a new project is a risk, but staying with a project that suddenly changes its license is far riskier. Giving OpenTofu to the Linux Foundation minimizes the risk associated with license changes, and having feature parity with Terraform up until 1.5.x, reduces technical risks.</li>
</ul>

Yes. OpenTofu is suitable for production use without any exceptions. There is no need to enter any separate, individually negotiated agreements regarding the production use of the tool.

No, the short answer is that OpenTofu will most likely not keep pace with upstream Terraform releases. The community will dictate what they need and want to see in OpenTofu.
Some of the Terraform features you’ve been waiting for ages will be publicly available soon.
Few companies have pledged to cover the costs of full-time engineers who will work on OpenTofu. There are 19 such engineers involved right now — and that doesn’t consider the willingness of many other individuals, companies, projects, and foundations to contribute.

The development decisions around OpenTofu are made by the steering committee. The steering committee and the community dictate the most important features and bug fixes. The sheer size of the community of developers pledging their resources to help develop OpenTofu will accelerate the development of features and enable faster releases than Terraform achieved in the past.

OpenTofu does not have its own providers. Terraform providers have not changed their licenses, and the possibility of such a change is almost zero. OpenTofu will work with the existing Terraform providers, but it is operating its own registry.

Switching from Terraform to OpenTofu involves a simple binary change in your pipeline, replacing Terraform with OpenTofu. 
If you are running Terraform locally, which is something we don’t recommend, you can simply add the OpenTofu binary in your PATH, and both OpenTofu and Terraform can co-exist if that is something you want.

The future of OpenTofu is in the hands of the community.
<a href="https://github.com/opentofu/opentofu" target="_blank" rel="nofollow noopener">The GitHub repository</a> is now published, having community guardrails and processes in place. The initial steering committee members have been selected, and on September 20, 2023, OpenTofu officially became a member of the Linux Foundation.
The community will guide the future of OpenTofu feature-wise.

You can support OpenTofu by:
<ul>
<li style="font-weight: 400;" aria-level="1">Opening issues</li>
<li style="font-weight: 400;" aria-level="1">Solve existing issues</li>
<li style="font-weight: 400;" aria-level="1">Participate in issue discussions (bug/feature/RFC)</li>
</ul>
To do that, check out the <a href="https://github.com/opentofu/opentofu/blob/main/CONTRIBUTING.md" target="_blank" rel="nofollow noopener">contribution guide</a> and understand more about what you can do.
Some other things you can do to show your support to OpenTofu’s initiative:
<ul>
<li style="font-weight: 400;" aria-level="1">Sign the manifesto and pledge your time to help develop this project. This can be done <a href="https://github.com/opentofu/manifesto" target="_blank" rel="nofollow noopener">here</a>, by forking the repository, adding your pledge at the end of the table, and creating a pull request.</li>
<li style="font-weight: 400;" aria-level="1">Join OpenTofu’s <a href="https://www.reddit.com/r/opentofu/" target="_blank" rel="nofollow noopener">Reddit community</a>.</li>
<li style="font-weight: 400;" aria-level="1">Follow OpenTofu on <a href="https://twitter.com/OpenTofuOrg" target="_blank" rel="nofollow noopener">Twitter</a>.</li>
</ul>

There are a couple of interesting features on the way such as state encryption and support of OCI registries. Priorities can shift based on the community’s voice, so you can request features and create RFC’s to implement them.

OpenTofu is the future of the Terraform ecosystem, and we plan to do everything right. We care about the community, and we care about having a truly open-source project to support your IaC needs.

73 Most Useful DevOps Tools to Use in 2024

Terraform vs. AWS CloudFormation : The Ultimate Comparison

What is OpenTofu? Why was it created? How is it licensed? We are answering the most important questions we've seen in different channels.

274-what-is-opentofu

what is opentofu

General | Spacelift Blog

General

Pawel Hytry

As the CEO of Spacelift, I am thrilled to share the exciting news about OpenTofu (formerly OpenTF) becoming a part of the Linux Foundation. Earlier today, Jim Zemlin and Sebastian Stadil <a href="https://www.linuxfoundation.org/press/announcing-opentofu" target="_blank" rel="noopener">made this announcement</a> on the stage of the Open Source Summit in Bilbao. They also revealed that OpenTofu would be going through the process of joining the Cloud Native Computing Foundation.
<h2>So, what exactly is OpenTofu?</h2>
OpenTofu is a fork of the legacy MPL-licensed Terraform. Unlike new releases of Terraform, OpenTofu is, and will always be, truly open source, community-driven, and impartial. The OpenTofu repository is publicly available, allowing you to see everything OpenTofu contributors have been working on.
The <a href="https://opentofu.org/" target="_blank" rel="noopener">OpenTofu initiative</a> was launched with significant initial support, boasting over 18 full-time equivalents (FTEs) committed to the project from four companies. The manifesto has been endorsed by over 140 companies, involving 11 projects with the participation of over 700 individuals. Moreover, the manifesto has received more than 35,000 GitHub stars, and the fork itself has garnered over 6,000 stars in just one week.
<h2>Now, why should you care?</h2>
If you&#8217;re like many Terraform users, you&#8217;ve likely spent the last few weeks pondering the implications of the <a href="https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license" target="_blank" rel="nofollow noopener">BSL announcement</a> for you and your company. Can you continue using Terraform? Can you integrate it into your CI/CD pipeline? Should you consider alternatives like CloudFormation, Pulumi, or Crossplane? Do you need to develop custom tooling for Terraform? Will you be required to pay for Terraform? Is Terraform Cloud or Enterprise your only option now? Is HashiCorp going to put the squeeze on you? Unfortunately, the <a href="https://www.hashicorp.com/blog/hashicorp-updates-licensing-faq-based-on-community-questions" target="_blank" rel="nofollow noopener">ever-changing FAQ </a>provided no clarity.
With OpenTofu, you have a clear path to maintaining the status quo. You won&#8217;t need to fret about BSL and its complexities. OpenTofu is the evolution of legacy Terraform.
<h2>What does joining the Linux Foundation mean for OpenTofu?</h2>
The decision to join the Linux Foundation is significant because it provides OpenTofu with a stable and well-respected organizational home. This move ensures that the project remains independent and avoids the risk of being controlled or influenced by a single company, which is a concern that many in the open-source community share.
By joining the Linux Foundation, you can rest assured that the tool will remain truly open source and neutral, free from the influence of any single company. It will continue to be:
<ul>
<li style="font-weight: 400;" aria-level="1">Truly open source &#8211; under a well-known and widely-accepted license that companies can trust, one that won&#8217;t suddenly change in the future or be at the mercy of a single vendor&#8217;s business plans.</li>
<li style="font-weight: 400;" aria-level="1">Community-driven &#8211; with the community governing the project, regularly reviewing and accepting pull requests based on their merit.</li>
<li style="font-weight: 400;" aria-level="1">Impartial &#8211; ensuring that valuable features and fixes are accepted based on their value to the community, regardless of their impact on any particular vendor.</li>
<li style="font-weight: 400;" aria-level="1">Layered and modular &#8211; featuring a programmer-friendly project structure that encourages building on top of it, fostering a new vibrant ecosystem of tools and integrations.</li>
<li style="font-weight: 400;" aria-level="1">Backwards-compatible &#8211; ensuring that existing code can continue to deliver value for years to come.</li>
</ul>
As a part of the Linux Foundation, the project will be safeguarded against the risk of any single organization altering its licensing terms. It will always remain open.
<h2>Now, why is this important for you and your organization?</h2>
Legacy Terraform served as the foundation for countless infrastructure teams. If you used Terraform, you likely invested significant effort in making it work seamlessly for your company. With the license change, HashiCorp exercised their full control over Terraform effectively limiting the permitted usage. And it might not be over. They could alter the license terms further, mandate payment for Terraform use, and potentially back you into a corner. Using the BSL version of Terraform is likely to put your company at risk. While things might turn out fine, you&#8217;re left at the mercy of a single vendor with complete control over your infrastructure.
OpenTofu addresses real concerns and provides a clear and attractive alternative in the world of infrastructure as code. Its commitment to open-source principles, community-driven development, and neutrality under the Linux Foundation&#8217;s umbrella should all contribute to its rapid rise.
Finally, OpenTofu provides you with a dependable path to maintain the status quo. You can breathe easy, knowing that you won&#8217;t need to navigate the complexities of BSL. OpenTofu is the natural progression of legacy Terraform, backed by a strong and independent foundation.

The Future of Terraform - OpenTF Manifesto!

Spacelift's latest statement on HashiCorp's BSL adoption

Exploring the Tech Stack: Spacelift's Supported Tools and Frameworks

OpenTofu (formerly OpenTF) is now a part of the Linux Foundation. See why is this important and what joining the Linux Foundation means for OpenTofu.

273-opentofu-announcement-2

OpenTofu joins the Linux Foundation

OpenTofu Joins the Linux Foundation

BREAKING NEWS: It’s here! The OpenTF fork is public! Take a look at the <a href="https://github.com/opentffoundation/opentf" target="_blank" rel="nofollow noopener">repository</a>, star it, and see all open <a href="https://github.com/opentffoundation/opentf/issues" target="_blank" rel="nofollow noopener">issues</a>.
The community’s response to OpenTF was extraordinary. In less than a month, the manifesto repository has received over 33k stars, with almost 140 companies and 700 individuals pledging their support, and a couple of companies — including Spacelift — even pledged to cover the costs of full-time engineers (five for Spacelift) to be employed by the foundation to maintain OpenTF for a long period, ensuring this project will be on the top level of infrastructure as code (IaC) offerings.

opentf-stars

opentf stars

This kind of growth is exceptional, so everyone’s support is much appreciated, and further support is highly encouraged by the OpenTF community.
<h2>Contributing to OpenTF</h2>
The easiest way to contribute to OpenTF is by <a href="https://github.com/opentffoundation/opentf/issues/new/choose" target="_blank" rel="nofollow noopener">opening an issue</a>! Feature requests, bug reports, broken compatibility reports, old issue reposts, and RFCs are welcome.
If you’d like to propose a major change, you will need to prepare an RFC. All of these changes, including the ones prepared by the core team, will go through the public RFC process to give everyone the possibility to discuss that particular issue. You can easily check out all the RFCs by going to the issues view and using the rfc label filter. To open an RFC and use the template for it, go to issues and select the Submit RFC option.
Contributing a code change can be done in a few easy steps:
<ol>
<li style="font-weight: 400;" aria-level="1">Fork the repository.</li>
<li style="font-weight: 400;" aria-level="1">Make your changes.</li>
<li style="font-weight: 400;" aria-level="1">Create a pull request (you will need to ensure that your commits are signed).</li>
</ol>
Signing your commits ensures you are accepting the <a href="https://developercertificate.org/" target="_blank" rel="noopener">Developer Certificate of Origin </a>(DCO), which is required for making code contributions to OpenTF.
Do you want to learn more about contributing to OpenTF? Check out the <a href="https://github.com/opentffoundation/opentf/blob/main/CONTRIBUTING.md" target="_blank" rel="nofollow noopener">contribution guide</a>!
<h2>What’s next?</h2>
OpenTF’s in-progress items are:
<ul>
<li style="font-weight: 400;" aria-level="1">Sticking with OpenTF as the name of the project or choosing a different one</li>
<li style="font-weight: 400;" aria-level="1">Creating an initial OpenTF Registry, that will be later changed to an official one after it goes through an RFC process.</li>
<li style="font-weight: 400;" aria-level="1">Creating the first stable release of OpenTF that will be a drop-in replacement for Terraform – this will be done once community feedback is received and enough testing is done.</li>
</ul>
<h2>How to continue supporting OpenTF</h2>
Apart from contributing directly to the repository, here are some other things you can do to show your support:
<ul>
<li style="font-weight: 400;" aria-level="1"><a href="https://join.slack.com/t/slack-9uv6202/shared_invite/zt-22ifsm1t2-AF6cL0cOdzivP8E~4deDJA" target="_blank" rel="nofollow noopener">Join OpenTF’s Slack community</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://www.reddit.com/r/opentf/" target="_blank" rel="nofollow noopener">Join OpenTF’s Reddit community</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://twitter.com/opentforg" target="_blank" rel="nofollow noopener">Follow OpenTF for more information on X</a></li>
</ul>
<h2>Key points</h2>
The OpenTF repository is now public, and you have many options for contributing. It will be developed in public, and all the major changes will go through an RFC process to ensure the voice of the community members is heard.

OpenTF Is Announcing Fork of Terraform!

The OpenTF repository is now public! See how you can contribute, what's next, and how to continue supporting OpenTF.

268-opentf-repo

OpenTF – Publishing the Fork

On August 10, 2023, HashiCorp announced that after ~9 years of Terraform being open source, they were suddenly switching it to a non-open source BSL license. 
In response to HashiCorp’s move, Spacelift, along with many other companies joined forces to create an initiative called <a href="https://opentf.org/" target="_blank" rel="nofollow noopener">OpenTF</a> with a <a href="https://opentf.org/" target="_blank" rel="nofollow noopener">manifesto</a> to ensure Terraform always remains open source. The community response to the OpenTF initiative has been enormous! The manifesto has already been signed by over 120 companies, 10 projects, and 500 individuals ready to pledge their time and resources to keep Terraform open source. It has amassed over 25,000 stars on <a href="https://github.com/opentffoundation/manifesto" target="_blank" rel="nofollow noopener">the GitHub repository</a>, and the numbers are growing daily! 
 
But the manifesto was not just a pledge to support Terraform as an open-source tool; it also set out two key aims. The first was to appeal to Hashicorp to return Terraform to the community and abandon the planned license change. Secondly, if the license was not reverted, the manifesto outlined a plan to fork the Terraform project into an OpenTF fork.
<h2>OpenTF has now forked Terraform!</h2>
Since no reversal has been done, and no intent to do one has been communicated, OpenTF is thrilled to announce we have created a fork of the legacy MPL-licensed Terraform under the name OpenTF. Over the last week, Spacelift engineers have been working with teams at other companies, including competitors, to make this project a reality. We want to keep OpenTF truly open-source and governed by the community for the community. 
OpenTF stands for the following ideals:
<ul>
<li style="font-weight: 400;" aria-level="1">True Open Source: Maintained under a well-known and trustworthy license that guarantees stability.</li>
<li style="font-weight: 400;" aria-level="1">Community-Driven: Governance of the project is handed to the community, with a regular review of pull requests based on their merits. Proposed changes will follow a transparent public RFC process.</li>
<li style="font-weight: 400;" aria-level="1">Impartiality: Features and fixes are judged on their community value — not on their value to a specific vendor.</li>
<li style="font-weight: 400;" aria-level="1">Modularity and Layering: The project will be kept layered and modular to enable a dynamic ecosystem of tools and integrations.</li>
<li style="font-weight: 400;" aria-level="1">Backward Compatibility: Keeping it backward-compatible will ensure existing code can create value in the future. </li>
</ul>
<h2>OpenTF will become a part of the Linux Foundation</h2>
OpenTF completed all documents required for it to be accepted into the Linux Foundation, with the ultimate goal of including OpenTF in the Cloud Native Computing Foundation (CNCF). We believe that making a foundation responsible for the project ensures it remains open-source and vendor-neutral.
Many tools we use in our Terraform workflows exist purely because Terraform has been open-source from the outset. That is why Spacelift and the other OpenTF signatories believe the only viable future for Terraform is OpenTF.
<h2>OpenTF Roadmap</h2>
OpenTF has been working on this fork for several days already, with over 10 engineers across multiple companies. Here’s where it’s at now:
<ul>
<li style="font-weight: 400;" aria-level="1">The repository-wide rename to OpenTF is almost complete.</li>
<li style="font-weight: 400;" aria-level="1">Initial steering committee members have been selected.</li>
<li style="font-weight: 400;" aria-level="1">Community documents have undergone cleanup and initial adjustment.</li>
<li style="font-weight: 400;" aria-level="1">CI/CD pipelines and multiple testing harnesses of end-to-end and snapshot tests are now working and green (this ensures backward compatibility).</li>
</ul>
OpenTF plans to publish the repository soon after it has been officially accepted into a foundation and has implemented foundational community guardrails and processes.
In the spirit of being as open as possible, OpenTF has created a <a href="https://github.com/opentffoundation/roadmap/milestones">public repository tracking its progress towards significant milestones</a>. You can subscribe to the issues there to be notified as soon as the fork is public. If you have any questions, please create additional issues on that repository &#8211; the team behind OpenTF will try to respond as quickly as possible.
&nbsp;
<h2>FAQ:</h2>
When will the OpenTF fork be accessible?
The plan is to publish the fork within 1-2 weeks. While this doesn&#8217;t mean an immediate release, the repository itself will be accessible, with alpha and stable releases following shortly thereafter.
Can OpenTF seamlessly replace legacy Terraform?
Yes, OpenTF is designed to be a drop-in replacement for legacy Terraform.
Will OpenTF be compatible with Terraform providers and modules?
Yes, OpenTF will be fully compatible with providers and modules that Terraform supports.
What will be the first release of OpenTF?
The first release, marked 1.6.0-alpha, will be a forked version of the most recent commit still licensed under the MPL.
Who is responsible for maintaining OpenTF? Is there sufficient support?
The OpenTF initiative has pledges from 4 companies, equivalent to 14 full-time engineers. This commitment is expected to double in the coming weeks.
How can I contribute to OpenTF?
Companies interested in pledging resources can email us or submit PRs on the manifesto repository. Currently, the best way for anyone to contribute is to spread awareness. Once the repository is public and the contribution process is formalized, coding contributions will also be welcomed.
Does OpenTF have a public roadmap? Can I influence it?
You can find the current public roadmap <a href="https://github.com/opentffoundation/roadmap/milestones" target="_blank" rel="noopener">on this GitHub repository</a>. We will introduce the RFC process for you to be able to contribute to the roadmap as soon as possible.
Will OpenTF be compatible with future Terraform releases?
OpenTF is committed to being 100% interoperable with future Terraform releases unless the community desires change.
Can OpenTF change its licensing model in the future?
Once OpenTF becomes part of the foundation, it’s governed by the foundation and the project community. Its licensing model cannot change.

What HashiCorp’s license change means for Spacelift customers

OpenTF announced Terraform fork! Learn about the fork, the importance of a foundation and what happens next.

259-announcement-opentf

259.announcement opentf

OpenTF is Announcing Fork of Terraform!

The Future of Terraform, Announcing OpenTF

Craig Dunn

<h2>What happened?</h2>
On August 10th, HashiCorp dropped a bombshell on the open source world announcing that going forward they will be changing the license on their core products, including Terraform, to a Business Source License (BSL v1.1 to be specific). Unlike the Mozilla Public License (MPL v2) that their products were previously licensed under, BSL is not an open source license. While it still allows similar freedoms for individuals to use, share, and modify, it places restrictions on various forms of commercial use.
Commercial development on open source foundations is nothing new and historically has benefited the industry by creating a base for competitive innovation that gives birth to better products and more choice for end users. One such example is the open source version control system Git, licensed under an open source GPL license. Git remains the most widely adopted version control system in the world. There are many successful commercial products built upon Git including GitHub, GitLab, BitBucket and more. End users have a choice between several powerful innovative tools and the Git ecosystem is thriving as a result.
Many open source projects are founded and managed by commercial organizations. This has for a long time been an accepted part of the open source ecosystem. The community benefits with open source projects backed by dedicated resources and structure, and the founding companies benefit by virtue of their position as custodians of the project and can leverage that visibility to aid their own commercial offerings.
To a large extent the balance between commercial interest and open source integrity has been maintained as the nature of open source licenses prevents projects from unilaterally changing their licensing terms. Traditionally, contributors retain the rights to their code which is protected under the same license terms.
In recent years however, we have seen a number of commercial organizations launch projects under open source licenses but require all third parties to sign a contributor license agreement (CLA) before any contributions will be merged into their source code. The purpose of this CLA is normally to require the contributor to hand over the rights to the code they contribute to the company. CLAs have been seen by many as a risk and an affront to the core principles of open source software since they consolidate the rights of all code to one entity, often with a commercial interest in the project. This is how HashiCorp was able to make this surprise move to Terraform.
The new BSL license that Terraform will adopt going forward contains restrictions on using the software on a hosted or embedded basis which is competitive with HashiCorp’s products.  Rather than encourage open innovation and competition in the Terraform ecosystem, HashiCorp have decided to attempt to block any other companies from competing with their own commercial offerings by snatching Terraform back from its open source foundations, violating the trust of the whole community that have adopted, contributed to, and advocated for Terraform over the past nine years helping make it the most prolific IaC tool we have.
<h2>Community Response: Announcing OpenTF Manifesto</h2>
The actions that HashiCorp has taken this week have left many in the community with very little clarity. The vague nature of the wording in the new license raises more questions than it answers. In fact, the only true clarity that we have is that the custodians of Terraform can and will pull the rug out from under its users whenever they feel that the way in which people use Terraform affects their commercial interests. There are no guarantees that HashiCorp won’t further modify its license to add even more restrictions in the future. Many feel that this introduces too much unpredictability to an ecosystem that thousands of organizations rely on to underpin their core infrastructure.
One thing that we all agree on is that Terraform is a fantastic tool that many of us rely on to deploy and maintain vital infrastructure. It is imperative that Terraform remains an open and collaborative project that serves the interests of the entire community, not just one commercial entity.
Since the announcement of the license change last week there has been a tumultuous amount of activity, speculation and discussion about the future of Terraform and what can be done to not lose such a precious and important asset. As a result, in the true spirit of our community, many companies and individuals have come together in unison to act as one under the umbrella of OpenTF.
<a href="https://opentf.org" target="_blank" rel="noopener">OpenTF</a> is a collaborative initiative supported by many of the most recognized companies and projects in the Terraform ecosystem, including Spacelift, pledging time, funding and resources to ensure the success and stability of the initiative.
On August 15th, just five days after the initial announcement from HashiCorp, OpenTF <a href="https://opentf.org" target="_blank" rel="noopener">released its manifesto</a>. The manifesto lays out OpenTFs intent and goals and sets out a roadmap to ensure the continued survival of Terraform as an open source tool. As a first step, OpenTF is appealing to HashiCorp to reverse their decision and revert Terraform back to a true open source license and put safeguards in place to ensure it stays that way forever.
If unsuccessful in appealing to HashiCorp, OpenTF is paving the way to fork the Terraform project under its original MPL license. Forking a project is never something to be taken lightly.  There are always risks of fragmentation and division within the user base that ultimately hinder the adoption of both sides. Trust has been lost and end users need confidence in the project and its management. That’s why OpenTF is seeking to fork the project into a foundation with true independent and impartial governance that only has one objective; continue to make Terraform the number one IaC tool and deliver what users want.
We at Spacelift believe that OpenTF has the right objectives. Furthermore, we believe that it has the backing and support to make this a huge success for all of us that use and love Terraform and we are proud to be a part of it.
<h2>How can you help?</h2>
You can help OpenTF either as a company, project, or individual by opening up a pull request on the <a href="https://github.com/opentffoundation/manifesto" target="_blank" rel="noopener">OpenTF </a><a href="https://github.com/opentffoundation/manifesto" target="_blank" rel="noopener">manifesto GitHub repository</a>.  Here you can pledge resources, time, and services to the initiative.  If you would just like to show your support for OpenTF, then please star the repository on GitHub, share the website on social media, and help us all spread the word.

Getting Started with Spacelift Self-Hosted on AWS

Announcing OpenTF Manifesto! OpenTF is a community response to the recent HashiCorp BSL license change. See how you can help.

253-opentf

Learn more about new features, updates, and Spacelift product announcements.

Product Features and Updates | Spacelift Blog

Product

Marcin Wyszynski

The introduction of Infrastructure as Code or IaC has transformed the way you can provision and deploy high-performance cloud-based IT infrastructures.
IaC tools, such as Terraform, have been integrated into DevOps toolchains, saving DevOps IaC teams from the excessive manual effort.
While these tools undoubtedly help accelerate building IT infrastructures, their limitations can impact DevOps’ ability to optimize and improve control of their IaC processes supporting future business needs.
In this article, you’ll learn about IT infrastructure limitations that IaC DevOps teams deal with on a daily basis and how Spacelift is able to get past them.

One of the most frequent challenges while using more generic IaC tools is the non-intuitive workflow driven by its reliance on pull requests. Some solutions offer multiple workspaces, but the result can be fragile and nondeterministic. 
Since there’s no concept of mapping projects to branches or tags, anyone commenting on an approved pull request can deploy arbitrary code to production, even if the approval was meant for a short-lived experimental environment.
Spacelift does not depend on pull requests. It is mostly driven by push and tag events, so building a sophisticated Git flow is much easier. Spacelift reports the outcome of its jobs as commit status checks, allowing you to block merging the code on a failing Spacelift check.
Triggering a run can be customized using <a href="https://docs.spacelift.io/concepts/policy/push-policy/" target="_blank" rel="noopener">Git push policies</a>. Thanks to that, Spacelift can provide the same level of comfort and security to teams using one project per repository and those using mono repo with hundreds of interdependent projects. You can read more about our approach to VCS integration <a href="https://docs.spacelift.io/integrations/source-control/github#tracked-branches" target="_blank" rel="noopener">here</a>.

The majority of generic tools don’t offer access control models but rely on comments on pull requests to drive infrastructure deployments. While it is usually fine when a single repository drives a single Terraform project, it becomes a huge liability for more complex scenarios.
Spacelift ships with a sophisticated mechanism allowing administrators to declare <a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">who can log in</a> (and under what circumstances) and what their <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">level of access</a> to each of the managed projects should be. Even our <a href="https://docs.spacelift.io/integrations/chatops/slack" target="_blank" rel="noopener">Slack integration</a> can be subject to policy controls, allowing an admin to grant access to a project <a href="https://docs.spacelift.io/integrations/chatops/slack#managing-access-to-stacks-with-policies" target="_blank" rel="noopener">based on Slack-specific data</a> (think team, channel, user, etc.).

One thing that’s not in scope for most IaC solutions is the way to ensure that your infrastructure is compliant with industry best practices and your company policies.
Spacelift puts policy-as-code in the center of its value proposition and builds a consistent, <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">robust policy framework</a> on top of <a href="https://www.openpolicyagent.org/" target="_blank" rel="nofollow noopener">Open Policy Agent</a>. Apart from providing a comprehensive automated change review and ensuring compliance of your <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">Terraform changes</a>, Spacelift uses the same approach to allow you to declare rules around the <a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">account</a> and <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">project access</a>, <a href="https://docs.spacelift.io/concepts/policy/push-policy/" target="_blank" rel="noopener">handling push notifications</a>, <a href="https://docs.spacelift.io/concepts/policy/run-initialization-policy" target="_blank" rel="noopener">starting runs</a> and <a href="https://docs.spacelift.io/concepts/policy/task-run-policy" target="_blank" rel="noopener">triggering tasks</a>, and creating <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">relationships between projects</a>.

Handling interdependencies between projects has always been Terraform’s Achilles’ heel. The usual approach to this problem is adding another layer of abstraction in the form of a Terraform wrapper like <a href="https://terragrunt.gruntwork.io/" target="_blank" rel="nofollow noopener">Terragrunt</a>. But it’s only a partial solution as it breaks the problem into smaller chunks.
<a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">Spacelift’s trigger policies</a> on the other hand provide a smart, declarative automation layer on top of vanilla Terraform. They allow you to plug into state changes of individual projects and declare dependencies that should be resolved, following the changes that have just been applied. Read more <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">here</a> to discover other exciting possibilities.

<ul>
<li><a href="https://spacelift.io/blog/spacelift-module-registry" target="_blank" rel="noopener">How to Use Spacelift Module Registry</a></li>
<li><a href="https://spacelift.io/blog/why-devops-engineers-recommend-spacelift" target="_blank" rel="noopener">Why DevOps Engineers Recommend Spacelift</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Infrastructure Problems that Spacelift Solves&quot;}" data-sheets-userformat="{&quot;2&quot;:4224,&quot;10&quot;:2,&quot;15&quot;:&quot;Arial&quot;}">Infrastructure Problems that Spacelift Solves</a></li>
</ul>

Another problem to solve externally when using some of the generic tools is authoring and maintaining reusable <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Terraform modules</a> for your organization. Terraform is flexible in allowing modules to come from <a href="https://www.terraform.io/docs/modules/sources.html" target="_blank" rel="nofollow noopener">various sources</a>, but ensuring confidential access, as well as testing and versioning, are left to you, the user.
Until now, the golden standard in that regard has been the <a href="https://www.terraform.io/docs/cloud/registry/index.html" target="_blank" rel="nofollow noopener">private module registry from HashiCorp</a>. But Spacelift offers much more. Far from being just a glorified package manager, Spacelift adds a <a href="https://docs.spacelift.io/vendors/terraform/module-registry" target="_blank" rel="noopener">full CI solution for Terraform modules</a>, out of the box and free of charge. You can thus ensure that your <a href="https://spacelift.io/blog/spacelift-module-registry" target="_blank" rel="noopener">private modules</a> are healthy before you distribute them to the rest of your organization.

If you manage a single or a handful of rarely changing projects, it’s likely that you just set your IaC up once and forget about it. But in a more dynamic environment, where microservices come and go, new environments proliferate and new product teams require their own <a href="https://spacelift.io/blog/terraform-workspaces" target="_blank" rel="noopener">Terraform workspaces</a>. The need to configure it each and every time become a major nuisance, putting a lot of pressure on your DevOps team.
Enter Spacelift. In Spacelift, much of the configuration can be handled by the project owners themselves—you can add Terraform and/or <a href="https://docs.spacelift.io/concepts/configuration/environment" target="_blank" rel="noopener">environment variables</a> and mount files (even inject Terraform code!) programmatically or through the GUI without the need for administrative privileges or changing the central server configuration. For administrators, adding new projects requires minimal hassle since there’s no need to set up webhooks or change any YAML. And it can all be done programmatically using Terraform.

What comes as a pleasant surprise to users of generic CI tools, Spacelift entities such as stacks, contexts, modules or policies can be managed in a declarative way using your favorite infra-as-code tool (this rule applies also to their configuration). Yes, that’s right—<a href="https://docs.spacelift.io/vendors/terraform/terraform-provider" target="_blank" rel="noopener">Spacelift offers a Terraform provider</a> that allows you to programmatically manage the lifecycle of its own resources.
Administrative stacks get credential-less access to the subset of our <a href="https://docs.spacelift.io/integrations/api" target="_blank" rel="noopener">GraphQL API</a> that does not involve managing the actual infrastructure. For more sophisticated use cases, Spacelift allows you to generate API keys that are subject to the same access controls as normal users are, allowing you to create single-purpose tokens for restricted use by your internal scripts.

Generic IaC platforms do not provide any mechanisms to detect if your infrastructure is undergoing drift. Drift is a condition that represents the difference between the desired and the actual state of the infrastructure managed by your tool of choice &#8211; <a href="https://www.terraform.io/" target="_blank" rel="nofollow noopener">Terraform</a>, <a href="https://www.pulumi.com/" target="_blank" rel="nofollow noopener">Pulumi</a>, <a href="https://aws.amazon.com/cloudformation/" target="_blank" rel="nofollow noopener">CloudFormation,</a><a href="https://docs.spacelift.io/vendors/kubernetes/" rel=""> Kubernetes</a>, or another. Drift can be caused by either or a combination of changes directly introduced by external actors &#8211; either humans or machines (scripts) or via the dependency of your resources on external data sources. In any case, drift is not good.
Spacelift has got you covered here. You can configure periodic <a href="https://docs.spacelift.io/concepts/stack/drift-detection" target="_blank" rel="noopener">drift detection </a>to notify you whenever drift happens, and take immediate action. You can even go a step further with optional automatic <a href="https://docs.spacelift.io/concepts/stack/drift-detection#to-reconcile-or-not-to-reconcile" target="_blank" rel="noopener">reconciliation</a>, ensuring your infrastructure always resembles your Terraform configuration.

General-purpose CI/CD platforms provide little to no insight into resource utilization from either a real-time or historical perspective. Which resources are over-or underutilized? 
Developers need to be able to intimately understand the material they’re working with. With regards to infra-as-code, the most important part of this story is understanding the managed resources in-depth. Both from the current perspective and through being able to put each resource in its historical context.
The resources view in Spacelift gives you greater visibility into each and every resource. With this deep insight into resources, DevOps are able to gain an understanding of the lifecycle of each resource managed by Spacelift and document it, regardless of the technology used — <a href="https://www.terraform.io/" target="_blank" rel="nofollow noopener">Terraform</a>, <a href="https://github.com/gruntwork-io/terragrunt" target="_blank" rel="nofollow noopener">Terragrunt</a>, <a href="https://spacelift.io/blog/what-is-pulumi" target="_blank" rel="noopener">Pulumi</a>, <a href="https://docs.spacelift.io/vendors/kubernetes/" target="_blank" rel="noopener">Kubernetes</a>, or <a href="https://aws.amazon.com/cloudformation/" target="_blank" rel="nofollow noopener">CloudFormation</a>.

Last but not least, Spacelift puts an emphasis on great user experience, offering a myriad of creature comforts. <a href="https://docs.spacelift.io/concepts/configuration/context" target="_blank" rel="noopener">Contexts</a> for example allow you to attach entire collections of configuration to individual stacks and modules. <a href="https://docs.spacelift.io/concepts/run/task" target="_blank" rel="noopener">Tasks</a> provide a powerful audited way of running one-off administrative commands on an initialized Terraform environment &#8211; subject to <a href="https://docs.spacelift.io/concepts/run/task" target="_blank" rel="noopener">their own policy constraints</a>. <a href="https://docs.spacelift.io/concepts/stack/#stack-locking" target="_blank" rel="noopener">Stack locking</a> allows a single individual to take exclusive control over a stack to ensure that nobody is able to modify its state while crucial changes are being made.

Most often, there is no point in implementing an in-house solution as the cost and effort of building and maintaining it may exceed its potential benefits. It is much easier and more efficient to leverage ready-to-go platform to provide these features instead.

OpenTofu Tutorial – Getting Started, How to Install & Examples

Get the newsletter

Recent posts