Selecting a Terraform Cloud Alternative

Updated on November 13th 2024
‍
The topic of Terraform Cloud alternatives has been coming up more and more with the announcement of their pricing changes as well as the license change for open source Terraform from the Mozilla Public License to the BUSL. There are many DevOps tools out there that can help with your Terraform workflow automation. Some users might resort to something like Github Actions for a more traditional CD pipeline, but we want to give you all of the information to help you make the best choice for your infrastructure automation.

General CD pipelines will give you a lot of flexibility as it is essentially an open orchestration tool, but you should be prepared to build any customization yourself. For example, if you want to integrate with policy, a cost estimation tool, enable drift detection, or any other open source tool in the space you are likely going to build and maintain it yourself. 

Automation tools purposely built for Terraform create workflow automation that you’ll find to be the best choice for Terraform as they are designed with the Terraform core workflow in mind. Everything from the Terraforms state file to integration with policy, to remote state management is native to these products and Scalr is the only other remote operations back end in the market other than Terraform Cloud. This means that Scalr is a drop-in replacement for Terraform Cloud or even Terraform Enterprise making the migration effort seamless.

In the next few sections, we’ll talk about why Scalr is the best choice if you're looking for Terraform Cloud alternatives that don’t have a heavy lift to migrate for your infrastructure team.

Differentiators

In this section, we’re getting straight to the point and will give you the list of key differences that, beyond pricing, give Scalr the edge over Terraform Cloud.

Backend & Storage

Scalr and Terraform Cloud are both remote operation backends for Terraform. A remote operation backend means that the runs execute in the backend and the state is stored there. While this deployment model works for most customers, we believe that customers should have the flexibility to select what type of backend is used and where the state is stored.

Backends: Terraform Cloud supports only one backend type, which is the Terraform Cloud backend. At Scalr, we want to give more flexibility, which is why you have the choice between using the Scalr backend or ANY backend that Terraform supports. Configured per Scalr environment, this gives users the flexibility needed to onboard all types of deployments without changing the Terraform configuration or where the state is stored. The runs execute in Scalr, and the state is then stored in the backend of choice. The flexibility helps larger organizations that already have many teams using many types of backends prior to onboarding into Scalr.

State Storage: Terraform Cloud only gives users the option to store state in Terraform Cloud. At Scalr, we believe users should choose where their state is stored, whether that is in Scalr or in a location of their choice, such as AWS S3 or a GCP bucket. Users can store their state in their own bucket regardless of the backend that is used, so a Scalr backend with state stored in AWS S3 is an option that many compliance teams opt for. 

Whether it is a backend type or state location, Scalr leaves it up to the user to determine what is best for their organization.

Visibility & Operations

Organizational Model: When you sign up for Scalr, you get an account scope, which you can create environments within. A Scalr environment is similar to a Terraform Cloud organization. The difference is that in Scalr you can create and share multiple objects from the account scope. For example, share your provider credentials, modules, or OPA policies with environments without having to create them over and over like you have to in Terraform Cloud. Also, information rolls up in Scalr. Each scope has a runs dashboard and the account scope has dashboards for runs, workspaces, modules, providers, and more across all environments and workspaces. You don't have to waste time searching for workspaces or runs like you do in Terraform Cloud, making your operations team more productive. The organizational model is the key difference that enables many of the other differentiators to come.

Reporting: Terraform Cloud has the concept of an explorer which shows high-level information around versions and the frequency in which objects like modules and providers are used. As an admin in Scalr, you can view reports, filter by environments and workspace, and take action by drilling into workspaces, runs, and more. The current reports available are:

• Resources under management and even see deleted resources to help with troubleshooting. Actionable buttons like “show run” and “show state” give you the ability to drill into components quickly.
• Which modules are being used, as well as their source and versions.
• Which providers are being used, as well as their source and versions.
• Which Terraform and OpenTofu versions are being used.
• Which workspaces are “stale” and haven't had a run in a specified timeframe.
• What Scalr API token have never been used or those that haven’t been rotated recently.

Pull Request Comments: Terraform Cloud only sends back basic checks to VCS providers to show users whether the run was successful or not. Scalr has in-depth pull request comments that summarize the run and post back the logs if the run fails. The goal of the pull request comments is to make things as least noisy as possible when runs are successful and as noisy as possible when there are errors:

Execute Runs from PR Comments: Terraform Cloud doesn't give users the option to execute a plan or apply from a pull request comment. At Scalr, we understand that many users have used the Atlantis “apply before merge” workflow, and we don’t want you to have to change that. Scalr gives users the flexibility to execute runs from the comments or disable them depending on your organization's requirements.

‍

Run Dashboards: Ever have a maintenance window where you wish you could see all runs across all Terraform Cloud organizations and workspaces in a single place? That’s exactly what the Scalr run dashboard does for you at the account scope. The same concept exists in the environment scope for the workspaces within the environment. Make your DevOps engineers more productive by providing operational information to them in one place.

Global Module Registry: In Terraform Cloud, you have to manage your modules in each organization, which is an unnecessary inconvenience. In Scalr, you can create the module registry at the account scope and share the Terraform modules with all environments. You also have the option of managing modules within environments if a module should only be used by a specific environment.

Security

Provider Credentials: Provider credentials are the way to authenticate to a cloud like AWS, Microsoft Azure, and Google Cloud. Provider credentials can be managed at the account and environment scope and then assigned to workspaces instead of managing them individually within workspaces as you have to in Terraform Cloud. The providers will be injected into the Terraform code during the Terraform plan and apply.

Checkov Integration: Scalr natively supports Checkov, giving users the ability to check for vulnerabilities in their code before the Terraform run executes. Scalr will receive the code, run the check, and prevent the Terraform run from happening if Checkov determines there are vulnerabilities.
‍

‍

RBAC: We have heard countless times that companies are restricted with whom they can invite to Terraform Cloud because of the limitations of the system roles in their RBAC. Scalr has over 120 permissions that can be grouped into custom roles and assigned to teams at the account, environment, or workspace scope. Invite all of the team members who need access, but follow the least privilege doctrine with Scalr.

SCIM Protocol: Have you had to do a cleanup of users because Terraform Cloud does not support the option to automatically add and remove them? Scalr supports the SCIM protocol, which automatically adds and removes users based on their status in your SAML provider. Many security teams see this as a best practice to avoid lingering accounts.

Pre and Post-Plan OPA Checks: Scalr not only checks runs against OPA policies during the post-plan, but also before the plan executes. Prevent runs from starting based on the source executing them, commit authors, workspace name, and anything else available based on tfrun data:

‍Open Policy Agent Impact Analysis: You don’t merge Terraform code changes without a speculative run so why would you do that with OPA? The OPA impact analysis tells you if there are errors or breaking changes to your workspaces before merging the policy to main.

VCS Agents: VCS agents allow you to make your Terraform code available from your internal VCS provider to Scalr without having to open it to the internet, which is critical from a security perspective. This feature does not exist in Terraform Cloud, so you are required to open the VCS provider to the internet, which is not a best practice.

Integrations

AWS EventBridge: The Scalr integration with EventBridge allows users to build event-driven Terraform and OpenTofu pipelines based on events that happen in Scalr. The EventBridge integration supports events such as a Terraform run failure or Scalr audit logs. Users can then expand the integration by integrating EventBridge with a monitoring solution to alert when critical workspaces fail or forward audit logs to a tool such as Cloudwatch.

Slack Integration: Receiving a notification about a Terraform run event is nice, but in Terraform Cloud you still have to go into the UI to approve it. Scalr allows you to approve or deny runs directly from Slack to avoid having to switch contexts.

Datadog Integration: Scalr gives you the ability to stream Terraform run events and metrics to Datadog to have full visibility over Terraform operations. Keep your operations and visibility where it should be.

Pricing & Packaging

The Scalr business model is another key difference that makes it the best Terraform Cloud alternative. Scalr aims to be transparent in all aspects of the business to allow you to make the best choice possible. 

Pricing Plans: Scalr has a free and business tier. The only difference is that the free tier has a max of 50 runs per month. The ONLY thing we charge for at Scalr is a Terraform run.

Run Concurrency: Scalr gives you 5 concurrent runs to start and we’ll scale the concurrency as you scale your runs at no charge. Terraform Cloud has 3 concurrent runs on the standard tier, but no visibility into how much it will cost for more.

Self Hosted Agents: Scalr starts with 25 agents, need more? Just ask and we’ll increase that limit free of charge. Terraform Cloud starts you with 1 agent on the standard tier, but no visibility into how much it will cost for more.

All information based on https://www.hashicorp.com/products/terraform/pricing as of April 2024

Differentiator Summary

Other than pricing, the key difference in Scalr is the inheritance organizational model that enables all of the other differentiators. The reporting, dashboards, and module registry allow you to monitor how your Terraform code is used in a way that is invaluable when running at scale.

The flexibility that Scalr gives you around security, specifically RBAC, ensures that all of your DevOps engineers will be able to without you having to sacrifice on security.

Lastly, everyone wants transparency when it comes to pricing, which is why Scalr believes in a simple pricing model that makes it the only Terraform Cloud alternative.

Similarities

As you look through your alternatives to Terraform Cloud, it’s not only important to look at differentiators, but also how the other offerings have all of the functionality you use daily. As a reminder, Scalr is the only remote operations backend other than Terraform Cloud, meaning you can continue to use the same workflows that you used in Terraform Cloud. Below, we’ll highlight the similarities between the two products:

Structure

While Scalr has an improved structure overall, there are a number of similarities in how the overall organizational model is used and applied: 

• A Scalr workspace is the equivalent of the Terraform Cloud workspace.
• A Scalr environment is the parent of a workspace, which is a similar concept to a Terraform Cloud organization.
• Scalr has the addition of the account scope, where many of the differentiators come into play

Operations

Scalr supports the same workspace options as Terraform Cloud:‍

• VCS: Integrate your Scalr workspace with a VCS provider of your choice to enable PR automation.‍
• Terraform CLI: Use the native Terraform CLI to execute runs in your workspace.‍
• No Code Provisioning: Deploy Terraform code to workspaces directly through the Scalr module registry to make it easier for your novice years to adopt Terraform. Scalr allows you to upgrade module versions in a workspace without redeploying.

In addition, Scalr also has a private module registry, the main difference being that you can maintain the registry at the account or environment scope.

Security

• Self-Hosted Agents: Scalr also has the concept of a self-hosted agent which allows you to execute runs on your own infrastructure, but we don’t limit the number of agents you can use. Often agents are needed to reach Kubernetes clusters that have network restrictions.
• Policy as Code: Scalr has always integrated with Open Policy Agent as the tool of choice for policy as code. Terraform Cloud has recently adopted this, but Scalr takes it to the next level with the policy impact analysis features.
• Provider Credentials: Both products support OIDC authentication for Amazon Web Services, Microsoft Azure, or Google Cloud. Scalr gives more flexibility in where the credentials can be managed and assigned.

These are a few of the ways that Scalr and Terraform Cloud are similar. The similarities will make sure your DevOps teams have a smooth transition from one Terraform automation tool to another. Easing the pain for the team members during a migration is key to the migration process.

Similarities Summary

When looking for Terraform Cloud alternatives you’ll want to understand the undertaking of the migration project. Being that Scalr is also a remote operations backend with similar constructs of workspaces and environments make it the best choice for an easy migration. Your DevOps engineers will have a smooth transition from Terraform Cloud to Scalr helping to maintain productivity during this time.

Summary

Picking an automation tool to replace Terraform Cloud is a big decision, but we wanted to make sure you had all of the information to help with making the best choice possible. At Scalr, we have implemented key differences to help your team members follow best practices when deploying the Terraform code at scale. At the same time, we made sure the general workflow automation was similar enough that your DevOps teams would not have a hard time transitioning.

Interested in seeing how easy it is to migrate? Try it out today on the free tier.

Resources to help with a migration:

• Learn how other companies migrated
• Use our Terraform module to automatically migrate from Terraform Cloud to Scalr
• Use the following script to figure out how many runs you executed in Terraform Cloud
• Understand how Scalr is a better option than Terraform Cloud

‍