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

Spacelift's going to AWS re:Invent in Las Vegas 🚀 🚀

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

Introducing Stack Dependencies v.2  🎉 🎉

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

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.

OpenTofu: Open-Source Alternative to Terraform

10 Popular Terraform Alternatives You Should Know in 2023

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>

<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>

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.
The alpha version of OpenTofu is now available &#8211; check out <a href="https://github.com/opentofu/opentofu/releases/tag/v1.6.0-alpha1" target="_blank" rel="nofollow noopener">the official announcement</a> and <a href="https://spacelift.io/blog/opentofu-alpha-release" target="_blank" rel="noopener">our overview of what&#8217;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?

Why Should You Switch to OpenTofu?

Why OpenTofu is a Good Choice for IaC Adopters

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.
The alpha version of OpenTofu is now available &#8211; check out <a href="https://github.com/opentofu/opentofu/releases/tag/v1.6.0-alpha1" target="_blank" rel="nofollow noopener">the official announcement</a> and <a href="https://spacelift.io/blog/opentofu-alpha-release" target="_blank" rel="noopener">our overview of what&#8217;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).
The alpha version of OpenTofu is now available &#8211; check out <a href="https://github.com/opentofu/opentofu/releases/tag/v1.6.0-alpha1" target="_blank" rel="nofollow noopener">the official announcement</a> and <a href="https://spacelift.io/blog/opentofu-alpha-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.

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: The Comprehensive List for 2023

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.

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.

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.

Why DevOps Engineers Recommend Spacelift

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.

Spacelift is an innovative and sophisticated SaaS product for Infrastructure as Code which helps IaC DevOps develop and deploy new infrastructures or changes quickly and with confidence.
Spacelift offers a unique set of IaC management capabilities:
<ol>
<li style="font-weight: 400;" aria-level="1">an intuitive, <a href="https://docs.spacelift.io/concepts/policy/git-push-policy" target="_blank" rel="noopener">versatile</a> and <a href="https://docs.spacelift.io/concepts/run/#run-state-machine" target="_blank" rel="noopener">robust</a> workflow</li>
<li style="font-weight: 400;" aria-level="1">granular access controls on <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</a> level that work well with an <a href="https://docs.spacelift.io/integrations/single-sign-on/" target="_blank" rel="noopener">identity provider of your choice</a> (SSO)</li>
<li style="font-weight: 400;" aria-level="1">an <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">automated code review</a> and <a href="https://docs.spacelift.io/concepts/policy/task-run-policy" target="_blank" rel="noopener">threat detection</a> </li>
<li style="font-weight: 400;" aria-level="1">the ability to <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">declare complex workflows</a> between projects across multiple repositories</li>
<li style="font-weight: 400;" aria-level="1">a <a href="https://docs.spacelift.io/vendors/terraform/module-registry" target="_blank" rel="noopener">built-in private module registry</a> with a full CI system for modules</li>
<li style="font-weight: 400;" aria-level="1">effortless setup and customization with <a href="https://docs.spacelift.io/concepts/configuration/environment" target="_blank" rel="noopener">per-project environment management</a> and <a href="https://docs.spacelift.io/integrations/docker" target="_blank" rel="noopener">Docker integration</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/vendors/terraform/terraform-provider" target="_blank" rel="noopener">programmatic configuration</a> using Terraform</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/concepts/stack/drift-detection" target="_blank" rel="noopener">drift detection </a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/concepts/resources" target="_blank" rel="noopener">resource visualization</a></li>
</ol>
… and a multitude of additional perks like <a href="https://docs.spacelift.io/concepts/configuration/context" target="_blank" rel="noopener">contexts</a>, <a href="https://docs.spacelift.io/concepts/run/task" target="_blank" rel="noopener">tasks</a> or <a href="https://docs.spacelift.io/concepts/stack/#stack-locking" target="_blank" rel="noopener">stack locking</a>.

There are many ways to manage your Infrastructure as Code. Each way is different in terms of complexity and offers a different set of features. It is important to keep in mind that choosing one way or another should be based on business and technical requirements. 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 platforms such as Spacelift to provide these features for you instead.

Spacelift is a flexible orchestration solution for IaC development. It delivers enhanced collaboration, automation and controls to simplify and accelerate the provisioning of cloud based infrastructures

5 Ways to Manage Terraform at Scale - Best Practices

Terraform vs. Ansible : Key Differences and Comparison of Tools

Infrastructure Drift Detection and How to Fix It With IaC Tools

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.

how_spacelift_can_improve_your_iac

How Spacelift Can Improve Your Infrastructure as Code 

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

Terraform Guides and Tutorials | Spacelift Blog

Terraform

Kamil Szczygiel

Learning Terraform can be easy. The HCL configuration language is simple enough to start with basic resource creation straight away. 
But—
Once the code that defines your infrastructure grows in complexity, maintainability, and dependency, an uphill battle can ensue. And that is why working out an efficient deployment workflow is crucial for further development.
In this article you will see five approaches to managing Terraform workflows at scale, what their benefits and downsides are, and what problems they address.
Note: New versions of Terraform will be placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers while also introducing improvements and enhancements. OpenTofu is the future of the Terraform ecosystem, and having a truly open-source project to support all your IaC needs is the main priority.

A quick and easy way to start deploying resources using the Infrastructure as Code pattern is to use Terraform locally from the same machine you’re developing the code on. The only requirement is to have access to the target provider and an installed Terraform binary.
This approach makes it much easier to leverage commands related to day-to-day operations (such as state import, move, remove) or to get outputs than if doing it within the implementations where you have no direct access to the underlying provider.
Even though this is the easiest way to work with Terraform, this is not a best practice, because as soon as you scale and you have multiple DevOps Engineers working on your project, it will become very complicated.
You can also use all of the features of Terraform, such as remote state and state locking, to work with your teammates all-at-once. If you collaborate using a version control system and do not have continuous integration in place, but want to keep your code at a decent level of quality, there are tools to help you.
One of these is <a href="https://github.com/antonbabenko/pre-commit-terraform" target="_blank" rel="nofollow noopener">pre-commit-terraform</a> that will run a set of selected tools to lint the code you’re creating before you even commit it. Even if you have continuous integration available, it’s a handy way to avoid wasting time waiting for results from pull request status checks.
What are the drawbacks of this approach? Each action is manual and must be performed directly by the developer, which leads to several issues. 
In a situation where multiple people are working on the same codebase, you could often encounter a scenario such as this one:
Person A applies their changes to the environment and follows up with a pull request. At the same time, Person B would like to deploy their changes but is blocked as the codebase is not up-to-date with Person A’s changes. Applying the changes in this state would cause damage to the resources created in the previous deployment. When working in larger teams, this will often result in a lot of wasted time just waiting and rebasing on a codebase to apply the changes.
If you happen to write unit tests for <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Terraform modules</a> (and you should be), you’re sure to know they need to be executed manually from your computer. Running them every time you change something in your configuration can be tedious and time-consuming. If you do not yet write tests for your modules, you’d be well advised to start looking at <a href="https://docs.spacelift.io/vendors/terraform/module-registry#tests" target="_blank" rel="noopener">Spacelift modules tests</a> or <a href="https://terratest.gruntwork.io/docs/getting-started/quick-start/" target="_blank" rel="nofollow noopener">Terratest</a>.
Privileged access to an underlying vendor is required, which can easily result in a compromised environment. It’s much harder to keep restricted access within this model, as Terraform must be allowed to create, change, and destroy resources. The same rule applies to a scenario where access to private (internal) resources is required, e.g., every developer has to set up a VPN connection to interact with them.
Moreover, every person working with the codebase needs access to the Terraform state, which creates a security concern due to how Terraform state works. Even if you’re pulling sensitive data from an external system such as Vault, it will be stored within the state file in plaintext once used in a resource. A threat actor could simply run `terraform state pull` to access all the secrets!
Keeping all these issues in mind, let’s take a look at a more automated approach.

Implementing homegrown automation means incorporating Terraform workflow into your continuous integration / continuous deployment process. A specific example would need to directly tie to a CI/CD tool you are using, so let’s try to keep the example as generic as possible.
As the applying actor is the CI/CD system, the hard requirement of privileged access for developers is gone. You can grant this type of access to the execution layer while developers keep read-only permissions. This is true for private (internal) resources, and if your code is being executed on an agent that resides within the target infrastructure with the proper permissions having been set. In a model where everything has to go through the <a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener">CI/CD pipeline</a>, visibility of changes is improved as the system logs produced during the operation execution are available in real-time. 
Linting, compliance checks, and automated unit tests can be moved to pull request status checks, and it’s up to you to configure these steps of the pipeline.
But—
If your CI/CD is executing jobs concurrently, you will end up with race conditions causing pull requests to fail non-deterministically. 
It is not difficult to imagine a situation where two operators open a pull request within several seconds of one another. The pipeline gets triggered immediately for both, and one pull request will be marked as successful, while the other will be marked as failed. This situation will definitely happen if you are using state locking (it is a best practice and you really should be using it).
The explanation is simple: the first pull request has locked the state and therefore the second one could not, so it failed. This issue can be resolved by configuring queued runs, where only one pipeline can run at a time. However, this is not so simple with some CI/CD products.
The biggest issue and concern with this approach is the effort you have to put in to build a complete pipeline. If you consider requirements such as:
<ul>
<li style="font-weight: 400;" aria-level="1">planning on pull requests</li>
<li style="font-weight: 400;" aria-level="1">linting</li>
<li style="font-weight: 400;" aria-level="1">unit tests</li>
<li style="font-weight: 400;" aria-level="1">compliance checks</li>
<li style="font-weight: 400;" aria-level="1">applying once merged</li>
<li style="font-weight: 400;" aria-level="1">periodical drift detection</li>
<li style="font-weight: 400;" aria-level="1">registry for all your versioned modules</li>
<li style="font-weight: 400;" aria-level="1">modules sharing across different parts of the organization</li>
<li style="font-weight: 400;" aria-level="1">shared variable contexts/reusable values</li>
</ul>
It might be tempting to implement solutions for those requirements by yourself. However, taking into account the time and effort required for doing it, you might want to take a look at alternatives, such as open-source tools.

One of the most popular open-source tools to use with Terraform is Atlantis, which describes itself as “Terraform pull request automation”. 
Atlantis provides a way for teams to collaborate on Terraform code changes by creating a pull request workflow. With Atlantis, developers can create, review, and merge Terraform code changes using familiar Git-based workflows. Atlantis also provides features such as automated plan and apply workflows, automatic branch cleanup, and integration with popular collaboration tools like Slack and GitHub.
It doesn’t offer a dedicated User Interface, you will need to use the one provided by your VCS provider, and if you want to use more advanced features like Policy as Code or Drift Detection, you will need to create the integrations inside of your pipeline, as it doesn’t come with these out of the box.
You can read more about it here: <a href="https://spacelift.io/blog/alternative-to-atlantis" target="_blank" rel="noopener">Alternative to Atlantis</a>.

<a href="https://spacelift.io/blog/what-is-terraform-cloud" target="_blank" rel="noopener">Terraform Cloud</a> is an application provided by the company behind Terraform itself—HashiCorp. It is available for free for up to 5 users. Two plans are available for more users: “Team &amp; Governance” and “Business”. As the product is created by Terraform authors themselves, any new feature that makes it to Terraform will be quickly available within Terraform Cloud as well. Neat!
See the comparison: <a href="https://spacelift.io/blog/atlantis-terraform" target="_blank" rel="noopener">Atlantis vs. Terraform Cloud</a>.
<h3>Advantages of Terraform Cloud</h3>
Advanced security compliance mechanisms available through Sentinel allow you to enforce organization standards even before the code actually ships and creates resources with the chosen provider context.
Another important feature is a module registry that acts as an artifact repository for all your modules. It can be compared to JFrog Artifactory, Sonatype Nexus, or other similar software. Having every module in a separate repository and versioning allows you to control code promotion in a granular fashion or quickly roll back to if it allows you to go back to the most recent version only, then we should use “the”, but if it lets you go back to some other earlier version then we should use “a” previous version. 
Having a centralized place to store all the pieces also enables you to quickly browse through available modules, their documentation, inputs, outputs, and used resources. It is a great single pane of glass in terms of module management. However, it can only be used within the same Terraform Cloud organization and cannot be shared. This might be troublesome for operations teams that base their separation on the organization level.
There’s also the remote execution backend, which is an exclusive feature for Terraform Cloud. It allows you to work with Terraform on your local computer as you would usually do, upload your local codebase, and run a plan against it. It is a very efficient way of quickly verifying if what you are working on is actually working.
<h3>Disadvantages of Terraform Cloud</h3>
Along with so many benefits, there are some drawbacks as well. Any linting or module unit tests need to be implemented inside your own continuous integration system. This requires an additional effort the development team has to make to sustain their code quality.
Integrations are limited to what Run Tasks are supporting at any given time, meaning that you cannot really own your workflow. You will need to manage with what you are receiving from Terraform Cloud. 
Another disadvantage is the fact that you cannot control the steps that are happening before and after an operation (init/plan/apply). Run tasks can be added before or after a plan and also before an apply, but you cannot add them before an init or after an apply, which again shows a lack of flexibility, and you will need to build pipelines in Github Action or whatever other CI/CD tool you prefer, to do some simple checks before running your code. The only thing that you can actually do, is run remote Terraform command execution using the CLI, which is not that helpful overall. 
The biggest drawback is the fact that Terraform Cloud doesn’t support any other products apart from Terraform. Of course, this is not its purpose, but as many organizations are using Kubernetes and Ansible in conjunction with Terraform, this would mean that you need to adopt other tools like <a href="https://spacelift.io/blog/argocd" target="_blank" rel="noopener">ArgoCD</a> and Ansible Tower to manage your workflows end to end.

And here we are. You can <a href="https://spacelift.io/terraform-cloud-alternative" target="_blank" rel="noopener">compare Spacelift directly to Terraform Cloud</a>. They share a lot of functionality with each other in terms of the actual deployment execution, but also in the area of compliance.
While Terraform Cloud uses Sentinel mostly (the HashiCorp approach to implementation for compliance as code), Spacelift leverages Open Policy Agent. It is beneficial to have a similar way of working with policies for companies that already incorporate OPA in their workflow (e.g., for Kubernetes). As there is no need to learn another syntax, operators can focus their efforts on providing compliance, instead of learning yet another tool.
With <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy#custom-inputs" target="_blank" rel="noopener">Spacelift’s custom inputs</a>, you can easily integrate any tool inside your workflow, but what really takes this to the next level is the fact that you can even write policies for it.
Do you want tfscan as part of your workflow? Install it and run it in a <a href="https://docs.spacelift.io/concepts/configuration/runtime-configuration/index.html#before_-and-after_-hooks" target="_blank" rel="noopener">before_init hook</a> and save the output to a file with the following format &lt;key&gt;.custom.spacelift.json (where key can be anything you like). Access the data in a plan policy under input.third_party_metadata.custom.&lt;key&gt; and you can write whatever policy you want. Don’t know what data is getting exposed? 
Use <a href="https://docs.spacelift.io/concepts/policy/#policy-workbench" target="_blank" rel="noopener">Spacelift’s policy workbench</a> and play around with the data until you easily understand what policies you can write based on the output of the integrated tool.
Spacelift also allows you to automate your workflow even further. By having a built-in continuous integration for modules, you can shift your linters or unit tests really quickly into one place dedicated to Terraform. It helps you reduce the effort required to implement integration workflow by letting you utilize a solution that you are already using.
<a href="https://docs.spacelift.io/concepts/stack/stack-dependencies" target="_blank" rel="noopener">Stack Dependencies</a> can help you easily deploy everything that you need in one go and building these dependencies is just one click away. As Stack Dependencies are Directed Acyclic Graphs (DAG), one stack can depend on multiple stacks and it can be depended by multiple stacks, but loops cannot exist. This unlocks the possibility of creating a sophisticated workflow without having to build complex pipelines.
Sometimes you need to work with a Terraform state directly to import something, for example. In scenarios where you are leveraging Terraform Cloud, it is often impossible to do this without accessing the provider yourself. In contrast, Spacelift gives you the ability to run literally any command within the context of a particular codebase via <a href="https://docs.spacelift.io/concepts/run/task.html" target="_blank" rel="noopener">tasks</a>. This way, you do not need to grant any additional permissions to import, move, or remove resources directly.
By utilizing <a href="https://docs.spacelift.io/concepts/configuration/context.html" target="_blank" rel="noopener">contexts</a>, you can simply share anything you like across multiple stacks—whether it is a set of environment variables or a file. This is something that becomes much more valuable once your codebase complexity increases.
As mentioned in the previous paragraph, drift detection is something that becomes much more important once your infrastructure grows. With Spacelift, it is possible to schedule periodic drift detection on any stack. Going even further, you can enable automated remediation if any changes are found compared to what you have in your codebase.

Regardless of how you decide to manage your Terraform code base, some best practices apply:
<ul>
<li>Use modules – Modules in Terraform allow you to package a collection of resources as a single logical unit. By doing so, you can create reusable components, making your codebase DRY and consistent. Modularizing code also improves code clarity and reduces duplication. </li>
<li>Leverage Dynamic Blocks – Dynamic Blocks in Terraform let you conditionally create block constructs based on input variables or other logic. This can help reduce repetition in your code and adapt configurations to different scenarios or environments without significant structural changes.</li>
<li>Use loops and conditionals – Count and for_each, allow you to iterate over lists or maps to create resources dynamically. This is particularly useful for scenarios where resource quantities or configurations are different based on input variables. Additionally, conditionals using the ternary(<code>? :</code>) operator can enable or disable configurations based on certain criteria. You can also leverage the for loop when you are building expressions and you also have the ability to use if statements in the loop, allowing you to build any expression you want based on your input.</li>
<li>Take advantage of variable validations – Starting from Terraform 0.13, you can include validation rules for input variables, ensuring that the values provided meet certain conditions before Terraform runs your configuration. This can prevent common configuration errors and ensure that provided input uses the expected formats or constraints.</li>
<li>Manage your state remotely with locking enabled – Using remote backends like AWS S3 paired with DynamoDB for state locking enables safer collaboration among team members. Remote state management ensures state consistency, while state locking prevents concurrent modifications, reducing the risk of state corruption or unintended infrastructure changes.</li>
<li>Scan your code for security vulnerabilities – Security is mandatory, especially when defining infrastructure. Tools like <a href="https://spacelift.io/blog/what-is-checkov" target="_blank" rel="noopener">Checkov</a>,<a href="https://spacelift.io/blog/what-is-tfsec" target="_blank" rel="noopener"> tfsec</a>, or Terrascan can scan your Terraform code for potential security misconfigurations or non-compliant definitions. Regularly scanning and addressing these vulnerabilities reduces the attack surface of your deployed infrastructure.</li>
<li>Implement Policies – Open Policy Agent (OPA) offers a flexible way to define and enforce policies across your Terraform configurations. Using a declarative language called Rego, you can create policies that restrict certain resource configurations, enforce naming conventions, or ensure compliance. Integrating OPA checks into your CI/CD pipeline helps maintain consistent adherence to these policies as your Terraform code evolves.</li>
<li>Implement Linting – Linting refers to the process of analyzing code for potential errors, code inconsistencies, and ensuring it matches the best practices. In the context of Terraform, linting can help catch syntax erros, deprecated code usage, or misconfigurations before they cause issues during an apply.</li>
<li>Test your code – Testing is a fundamental part of any software development project. Using tools such as Terratest or Kitchen-Terraform can help with writing integration tests for your Terraform configurations, ensuring your code is working properly before being deployed to the production environment/</li>
<li>Write thorough documentation – Documentation is vital for understanding the purpose and usage of your Terraform configurations, especially when collaborating with others. Terraform-docs is a handy tool that can automatically generate documentation for your Terraform modules, providing an overview of inputs, outputs, providers, and more. Integrating this into your CI/CD pipeline ensures that your documentation stays up-to-date with your code changes.</li>
</ul>

There are many ways of working with Terraform. Each way is different in terms of complexity, and has a different set of features. It is important to keep in mind that choosing one way or another should be based on business and technical requirements. Most times, there is no point in implementing an in-house solution as the cost and effort of building and maintaining it may often exceed its potential benefits. It is much easier and quicker to leverage platforms such as <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a> to provide these features for you instead.

Spacelift helps manage Terraform state, build more complex workflows, supports policy as code, programmatic configuration, context sharing, drift detection, resource visualization and many more.

Initialize/ plan/ apply your IaC, manage modules, state, and more. 

frame-8479

Frame 8479

Provisioning AWS EKS Cluster with Terraform - Tutorial

How Spacelift Can Improve Your Infrastructure as Code

How to Get Started with Terraform on GCP - Tutorial

This article goes through five approaches to managing Terraform workflows at scale: using Terraform locally, automating it in-house, using open source solution, using Terraform Cloud, and using Spacelift.