Terraform Cloud Alternatives for Multi-Cloud Enterprises [2026]

TL;DR

• Terraform Cloud manages Terraform state and execution runs; Pulumi, CDK, and CloudFormation deployments sit outside its governance boundary, and Sentinel policies never evaluate resources that those tools create.
• The right alternative depends on where your team sits today: a team with complete Terraform coverage and no unmanaged resources needs different tooling than a team inheriting years of manually provisioned AWS accounts with no state file in sight.
• StackGuardian is the only platform in this list that starts before Terraform code exists; it scans live cloud accounts, identifies unmanaged resources, and generates Terraform or OpenTofu configuration from what it finds.

Terraform Cloud centralizes terraform plan and terraform apply execution, stores remote state with locking, and lets reviewers see plan output before infrastructure changes land in production. For a team with complete Terraform coverage and predictable workloads, that scope is enough.

The scope breaks down as infrastructure grows. A platform engineering team managing 400 Terraform workspaces across AWS, Azure, and GCP typically runs multiple IaC tools: Terraform for foundational infrastructure, Pulumi or CDK for application-layer resources, and Helm for Kubernetes workloads. Terraform Cloud does not see any non-Terraform deployments. Sentinel policies don't evaluate CloudFormation stacks or Pulumi programs. Resources created with those tools accumulate outside Terraform state, policy scope, and drift detection.

Add the Terraform licensing change: HashiCorp moved to the Business Source License in 2023, prompting many teams to adopt OpenTofu and further widening the market for alternatives.

This guide covers six platforms that address these gaps in different ways. Each solves a specific part of the problem. Identifying the problem your team actually has determines which platform fits best.

Why Do Engineering Teams Look Beyond Terraform Cloud?

1. RUM Billing Scales with Resource Count, Not with Deployment Activity

Terraform Cloud's Resources Under Management pricing is based on the number of cloud resources in the Terraform state, not on how many runs execute or how many users interact with the platform. A team that provisions 10,000 EC2 instances, RDS clusters, and S3 buckets pays for 10,000 managed resources during months with no deployments. As the infrastructure footprint grows, costs rise with it, regardless of how much the platform is actually used.

2. Terraform's BSL Licensing Change Made OpenTofu a Practical Requirement for Some Teams

HashiCorp moved Terraform from the Mozilla Public License to the Business Source License in August 2023. The BSL restricts commercial use in ways the MPL did not, which has pushed engineering organizations evaluating long-term IaC strategy to choose between staying on Terraform, migrating to OpenTofu, or running both in parallel. Terraform Cloud has no native OpenTofu support. Teams adopting OpenTofu need a platform that runs both runtimes without maintaining separate execution pipelines for each.

3. Sentinel Policies Don't Evaluate Resources Deployed Outside Terraform State

Terraform Cloud's policy engine, Sentinel, evaluates plans produced by terraform plan. A CloudFormation stack deployed through a separate pipeline, an ARM template deployed through Azure DevOps, or a Pulumi program managing application-layer infrastructure all produce resources that exist in the cloud but not in Terraform state. Sentinel never sees them. Security and compliance requirements that apply to the full cloud environment cannot be enforced through Terraform Cloud alone; they can only be enforced for the subset of resources Terraform manages.

4. Console-Created Resources Accumulate in Cloud Accounts with No Terraform State Entry

An engineer provisions an RDS instance through the AWS Console to diagnose a production incident. A database administrator creates an IAM policy through the Azure portal because the Terraform PR review cycle takes 48 hours. A security team modifies a security group directly to respond to an active threat. Each of these resources now exists in the cloud account without a corresponding .tf file, a state entry, or policy coverage. Over months, these manual changes accumulate into a shadow infrastructure layer that Terraform Cloud has no mechanism to detect, report on, or govern.

5. Teams Already Running GitHub Actions or GitLab Pipelines Don't Need a Separate Execution Layer

An engineering organization that deploys application code via GitHub Actions already has runners, OIDC authentication with AWS and Azure, approval gates via GitHub Environments, and reviewer workflows via pull requests. Adding Terraform Cloud introduces a second system with its own authentication model, workspace configuration, and run history, separate from the pipeline history that every engineer already checks. Running terraform plan and terraform apply as workflow steps inside the existing pipeline removes that duplication.

6. Years of Manually Provisioned Cloud Infrastructure Has No Terraform Entry Point

Most enterprise cloud environments didn't start with Terraform. They started with manual provisioning, CloudFormation templates written in 2017, ARM templates nobody actively maintains, and a handful of Terraform modules that cover 30% of deployed resources. Before any platform can govern these resources, they need to exist as Terraform code with corresponding state. Terraform Cloud provides no mechanism to discover unmanaged resources or generate IaC from them; it requires Terraform code to already exist as the starting point.

Three Categories That Define the Alternatives Market

Not every Terraform Cloud alternative solves the same problem. Choosing the wrong category before evaluating features wastes the evaluation.

1. Dedicated Infrastructure Lifecycle Platforms

Example: StackGuardian

These platforms manage the full IaC lifecycle: cloud discovery, IaC generation, workflow orchestration, policy enforcement, and self-service provisioning. They start before Terraform code exists and continue through ongoing governance after deployment. The right fit for teams with significant unmanaged cloud infrastructure or platform engineering requirements.

2. GitOps Automation Platforms

Example: Atlantis

These platforms execute terraform plan and terraform apply from pull requests. A developer opens a PR; the platform posts the plan as a comment; a reviewer approves; and the platform applies it after merge. Narrow scope, low operational overhead. The right fit for teams with complete Terraform coverage that want PR-driven automation without managing a wider platform.

3. CI/CD-Based Terraform Workflows

Examples: GitHub Actions, GitLab CI/CD, Jenkins, Azure DevOps Pipelines

These are general-purpose automation platforms that run Terraform as pipeline stages alongside application deployments. State management, policy enforcement, drift detection, and approval gates are pipeline steps that the team builds and maintains. The right fit for teams standardized on a CI/CD platform that want Terraform to follow the same deployment process as application code.

6 Terraform Cloud Alternatives Compared

1. StackGuardian

StackGuardian is an infrastructure lifecycle platform built around two components: SGCode, which handles cloud discovery, IaC generation, and coverage tracking; and SGOrchestrator, which manages workflow execution, policy enforcement, approval gates, and developer self-service. Unlike Terraform Cloud, which requires Terraform code to already exist, StackGuardian starts with the live cloud environment and works backward, scanning accounts, classifying resources by IaC status, generating Terraform or OpenTofu from unmanaged infrastructure, and building coverage before any deployment workflow runs.

Key Functionalities

• Cloud Resource Discovery: SGCode connects to AWS, Azure, and GCP accounts and discovers every resource across the environment, tracking IaC coverage and classifying resources against connected state backends
• AI-Assisted IaC Generation: Generates Terraform or OpenTofu configuration from selected unmanaged resources, resolves inter-resource dependencies, and validates output through an internal terraform plan before publishing to Git
• IaC Adoption Matrix: Tracks what percentage of the cloud estate has Terraform coverage across eight defined infrastructure states, giving teams a measurable codification target
• Workflow and Stack Templates: Workflow Templates define per-component deployment logic; Stack Templates compose multiple workflows into dependency-linked deployments where outputs from one workflow feed into the next
• Three-Layer Policy Engine: Tirith (StackGuardian's JSON-based framework, with a NoCode builder for UI-configured rules) and OPA/Rego (sourced from Git). Policies are evaluated before applying fires, not only at PR creation
• Runtime Containers: Standardized execution environments with pinned Terraform or OpenTofu versions, helper CLIs, and initialization scripts shared across all workflows
• Self-Service Provisioning: Developers select a published Workflow Template or Stack Template, fill in parameters through a form, and submit; SGOrchestrator handles execution, policy checks, approval gates, and apply without the developer touching a .tf file
• Security, Cost, and Compliance Benchmarks: Continuously evaluates cloud environments across three dimensions with 1,800+ automated checks covering misconfigurations, cost inefficiencies, and compliance violations
• VCS Integrations: GitHub, GitLab, Bitbucket, and Azure DevOps
• IDP Integrations: Backstage (native plugin) and ServiceNow (via workflow steps)

Hands-On: Connecting state backends, discovering unmanaged cloud resources, codifying into Terraform, and deploying through governed templates

Step 1: Connect state backends and discover resources

A platform engineer opens the State Backends tab in SGCode (SGCode → State Backends) and connects the team's S3 buckets. SGCode reads connected state backends and builds a map of already-managed resources against discovered cloud resources.

Here is how the State Backend tab looks after connecting eight AWS backends:

Notice the Authentication successful badge per backend and the nested state file paths, hifolder1/terraform.tfstate alongside root-level terraform.tfstate, confirming SGCode is reading state across multiple workspaces. With the state loaded, SGCode scans the linked cloud accounts and classifies every discovered resource as managed, unmanaged, or drifted against those state files.

Step 2:  Generate IaC and build templates

The engineer selects unmanaged resources. SGCode generates Terraform or OpenTofu configuration for each, resolves dependencies, validates the output through an internal terraform plan, and opens a PR in the connected GitHub repository. After the merge, the IaC Adoption Matrix updates the coverage percentage.

With resources codified, the platform team moves to Develop → Library → IaC & Stack Templates to create the deployment blueprints application teams will use:

The Status column shows which templates are Active and available for self-service consumption, stack-many-c and lurifos-many in the example, and which are Inactive and held for reference only. Stack Templates (shown with the stacked-layers icon) chain multiple Workflow Templates in dependency order, passing outputs from one step to the next as inputs.

Step 3: Attach policy templates and configure runtime containers

Before templates go live, the platform team sets up governance rules under Develop → Library → Policy Templates:

Policies like CKV2_AWS_1 through CKV2_AWS_14 enforce Checkov rules against Terraform plans, VPC configuration, EBS settings, and IAM access controls. Each policy attaches to a Workflow Template. When a deployment runs, SGOrchestrator evaluates attached policies before terraform apply fires. Each policy rule returns one of five statuses: Pass (workflow proceeds), Fail (workflow is blocked), Warn (proceeds with notification), Approval Required (pauses for a named approver), or Unevaluated. For custom workflow steps, exit codes also control flow: 0 for success, 1 for failure, and 11 to trigger conditional approval.

Each template also specifies a Runtime Container, a Docker image that defines the exact Terraform version, CLI tools, and init scripts for that workflow. Outputs written to the shared artifacts directory are referenceable by downstream workflows in a Stack using Reference Variables (e.g., ${reference::template-group.0.outputs.cluster_name}).

Step 4: Self-service deployment

Application teams open the self-service catalog through Backstage, ServiceNow, or the StackGuardian Dev Portal, select a template, fill in parameters through the no-code form, and submit. SGOrchestrator evaluates policies, routes through approval gates, and applies workflows in dependency order, without the developer touching a .tf file.

Pros

• Covers the full IaC lifecycle from unmanaged resource discovery through governed, policy-checked deployment
• Supports Terraform, OpenTofu, CloudFormation, Ansible, Helm, Kubectl, and Terragrunt in a single platform, plus any custom tooling via runtime containers
• No-code policy builder lowers the governance barrier for teams without Rego expertise.
• Workflow-based pricing doesn't grow with resource count the way Terraform Cloud's RUM model does
• Self-service templates let application teams provision infrastructure without writing Terraform.
• Audit trails and policy enforcement across every deployment satisfy SOX, GDPR, and PCI requirements.

Cons

• Platform scope is wider than a Terraform execution engine; smaller teams without discovery or self-service requirements use a fraction of the available functionality
• SGCode auto-discovery currently covers AWS, Azure, and GCP; additional cloud providers are on the roadmap but not yet available

2. Atlantis

Atlantis is an open-source, self-hosted Terraform automation server that connects to GitHub, GitLab, or Bitbucket via webhooks and runs terraform plan and terraform apply from pull requests. It solves one problem: automating Terraform execution from the pull request review workflow without requiring a managed platform. State management, policy enforcement, and drift detection all sit outside Atlantis's scope and require separate tooling or pre-plan hooks.

Key Functionalities

• PR-Triggered Planning: Automatically runs terraform plan when a pull request modifies Terraform configuration and posts plan output as a PR comment
• Comment-Triggered Apply: A maintainer posts atlantis apply as a PR comment to trigger terraform apply after code review
• Workspace Locking: Locks the affected workspace during plan and apply to prevent concurrent runs from conflicting on the same state file.
• Multi-Repository Support: A single Atlantis deployment manages multiple repositories and Terraform projects simultaneously
• Custom Workflows: Teams define pre-plan and post-plan hooks, Terraform version pinning per project, and per-directory execution behavior
• Terragrunt Support: Runs Terragrunt through custom workflow configuration in place of native Terraform commands

Hands-On: Triggering terraform plan from a pull request, locking the workspace, and applying via PR comment

A developer opens a pull request modifying a security group in the networking/ directory. Atlantis receives the GitHub webhook, identifies that networking/ changed, and runs terraform plan against that workspace using credentials configured in the Atlantis server environment. Atlantis immediately locks the workspace to prevent concurrent runs from conflicting on the same state file. Here is how the Atlantis server dashboard looks at this point:

The Locks table shows the default workspace locked against PR #9 by kunchalavikram1427 at 11:18:19. The Jobs table, triggered eleven seconds later at 11:18:30, shows the plan step running against the same repository and workspace. Clicking the plan link opens the full terraform plan output. The plan output is also posted as a comment on the pull request for the reviewer's inspection.

A reviewer reads the plan, approves the PR, and posts atlantis apply as a PR comment. Atlantis runs terraform apply, posts the apply output back to the PR thread, and releases the workspace lock when apply completes. Teams using Terragrunt configure a custom workflow that calls terragrunt plan instead of terraform plan. Pre-plan hooks can call conftest verify against OPA policies before the plan runs, wiring basic policy enforcement without a native policy engine.

Pros

• Free and open source with no SaaS dependency or licensing cost
• Tight PR-to-apply loop: plan and apply history lives alongside code review in the same PR thread
• Works with any Terraform backend, S3, Azure Blob Storage, GCS, without migrating existing state
• Self-hosted deployment gives full control over runner credentials and network access
• Custom workflows support Terragrunt, version pinning, and pre/post hooks

Cons

• No built-in policy enforcement; OPA/Conftest must be wired as a pre-plan hook or a separate CI stage.
• No drift detection Atlantis has no scheduler or polling mechanism for unattended scans.
• No self-service interface exists; every user needs repository access and Terraform knowledge to interact with Atlantis.
• No support for non-Terraform IaC tools
• Teams are responsible for operating, upgrading, and securing the Atlantis server

3. GitHub Actions 

GitHub Actions is a general-purpose CI/CD platform that runs terraform plan and terraform apply as steps inside YAML workflow files stored in the repository. It is not a dedicated Terraform platform; it provides no managed state backend, no native policy engine, and no drift detection. What it provides is full control over every pipeline stage and native integration with the GitHub pull request workflow that many engineering teams already use for application deployments. Teams that already run application CI/CD through GitHub Actions often find that adding Terraform as a workflow step removes the need for a separate IaC platform entirely.

Key Functionalities

• Repository-Native Workflows: YAML workflow files in .github/workflows/ live alongside infrastructure code, version-controlled and reviewable through pull requests
• OIDC Authentication: Workflows assume AWS IAM roles, Azure service principals, or GCP service accounts using short-lived tokens without storing long-lived credentials as repository secrets
• GitHub Environments: Production deployments pause at an environment gate until a designated reviewer approves in the GitHub UI
• Marketplace Actions: Reusable actions for Terraform, OpenTofu, static analysis (Checkov, tfsec, TFLint), and cloud provider interactions
• Self-Hosted Runners: Teams deploy runners inside private networks for workflows requiring access to non-public cloud environments
• Scheduled Workflows: Cron-triggered workflows run terraform plan against the existing state and flag non-zero output for drift reporting

Hands-On: Running a PR-triggered Terraform pipeline with OIDC authentication, environment approval gates, and nightly drift detection

A developer opens a pull request modifying an EKS cluster configuration. A terraform-plan.yml workflow triggers: it runs terraform fmt --check, terraform validate, terraform init against the configured S3 backend, Checkov for static analysis, and terraform plan. The plan output is posted as a PR comment using the hashicorp/setup-terraform action. A reviewer inspects the plan and approves the PR.

After the merge, the terraform-apply.yml workflow is triggered. It targets the production GitHub Environment, pauses for manual approval from a senior engineer, then runs terraform apply. A separately scheduled detect-drift workflow runs nightly; it calls terraform plan against each workspace and flags any non-zero output. Here is how a completed detect-drift run looks in the GitHub Actions job view:

The Terraform Plan step at line 18 outputs No changes. Your infrastructure matches the configuration. The VPC with ID vpc-06fe36788d0330628 matches its state file exactly. The custom DRIFT-DETECTOR: "No changes detected" line on line 22 is a team-defined exit message that the workflow uses to decide whether to post a Slack alert. The full job was completed in 19 seconds across four steps: AWS credentials setup, Terraform setup, init, and plan.

Pros

• No additional platform cost for teams already on GitHub
• Full pipeline control, every stage customizable through YAML and shell commands
• OIDC authentication removes long-lived credential storage from repository secrets
• A large marketplace of community actions reduces setup time for common Terraform patterns
• Supports Terraform and OpenTofu without additional configuration

Cons

• No managed state backend; teams configure and maintain their own S3 or Azure Blob backend.
• Policy enforcement requires adding and maintaining Checkov, tfsec, or Conftest as pipeline steps.
• Drift detection requires a separately built scheduled workflow
• No self-service UI for non-Terraform users
• Workflow complexity grows with workspace count; 200 workspaces require custom logic to determine which workspace plans to apply to each PR

4. GitLab

GitLab CI/CD runs Terraform as pipeline stages defined in .gitlab-ci.yml files stored alongside infrastructure code. It is not a dedicated IaC platform; governance, drift detection, and self-service require additional configuration. Its primary advantage is consolidation: source control, CI/CD, security scanning, merge request approvals, and Terraform execution all live inside a single platform. This matters most for organizations already standardized on GitLab or operating in air-gapped environments where self-managed runners are a compliance requirement.

Key Functionalities

• MR-Triggered Pipelines: Merge request pipelines run automatically when infrastructure code changes, executing fmt, validate, plan, and security stages before merge is allowed.
• GitLab Environments: Separate variable sets, backend configurations, and approval rules per deployment environment (development, staging, production)
• Built-in Terraform HTTP Backend: Stores Terraform state per project in GitLab's storage layer, accessible with CI job token authentication, no external backend required
• Protected Variables: Encrypted CI/CD variables for cloud credentials, API tokens, and Terraform variables with masking in pipeline logs
• Self-Managed Runners: Runners deployed on private infrastructure or inside air-gapped networks with no connectivity requirement to GitLab.com
• Compliance Pipelines: Mandatory pipeline stages enforced across projects without allowing individual teams to skip or override them

Hands-On: Running validate, plan, apply, and destroy through merge request pipelines with GitLab's built-in Terraform state backend

A developer opens a merge request modifying an Azure virtual network configuration. The MR pipeline triggers three stages: a validate stage running terraform fmt --check and terraform validate; a plan stage running terraform init and terraform plan, with plan output saved as a pipeline artifact and rendered as a structured table in the MR UI through GitLab's Terraform report artifact format; and a security stage running Checkov against the Terraform configuration.

After reviewer approval, the pipeline proceeds to the apply stage. Here is how the completed pipeline looks in the GitLab pipeline view:

The pipeline ran four sequential stages: validate, plan, and apply, all of which passed with green checkmarks. The destroy stage is configured as a manual trigger (the play button icon) rather than an automatic stage, preventing accidental teardown without explicit intent. The full pipeline for commit 3aa9be0a ran in 4 minutes 38 seconds on the main branch.

The apply stage runs terraform apply using credentials stored in protected CI/CD variables scoped to that environment and writes the updated state to GitLab's built-in Terraform HTTP backend. GitLab surfaces stored state files directly under Operate > Terraform states in the project sidebar:

The tf_state entry shows Tony Chan updated 8 minutes ago in the Details column, confirming the state was written by the most recent terraform apply run. Any subsequent CI job in the gitlab-managed-terraform project authenticates to this backend using a short-lived job token, with no external S3 bucket or DynamoDB locking table required. Approval records for the production deployment persist in the GitLab Environment deployment history.

Pros

• Single platform for source control, CI/CD, security scanning, and Terraform execution, no additional system to authenticate to or monitor
• The built-in Terraform HTTP backend removes the need to configure an external state backend.
• Compliance pipelines enforce mandatory stages across all teams without individual override.
• SaaS and self-managed deployment options cover air-gapped and strict data-residency environments.
• MR-based approval rules enforce change control natively

Cons

• No native IaC policy enforcement, policy checks require Checkov or Conftest wired as pipeline stages
• No built-in drift detection without a separately scheduled pipeline
• No self-service interface for non-IaC users
• Pipeline configuration grows in complexity as workspace count and environment count increase

5. Jenkins

Jenkins is a self-hosted, open-source automation server that runs Terraform as stages in a Jenkinsfile, a Groovy-based pipeline definition stored in the repository. Jenkins provides no Terraform-specific features. Every part of the infrastructure pipeline, state management, policy checks, approval gates, and drift detection, is implemented by the team as pipeline stages using plugins or shell commands. Its relevance as a Terraform Cloud alternative stems from existing enterprise adoption: organizations with Jenkins already running most automated processes often extend it to cover Terraform rather than introducing a second platform.

Key Functionalities

• Declarative and Scripted Pipelines: Jenkinsfiles define every Terraform stage in either Declarative or Scripted syntax and are stored in the repository alongside infrastructure code.
• Plugin Ecosystem: Integrations with GitHub, GitLab, Bitbucket, HashiCorp Vault, AWS, Azure, Slack, Jira, and Kubernetes through the Jenkins plugin library
• Distributed Agents: Different agents target different environments, development agents with broader IAM permissions, and production agents with tighter credential scoping
• Manual Approval Stages: Pipeline pauses at configured input steps and sends notifications to designated reviewers before proceeding to apply
• Dynamic Kubernetes Agents: Agents are provisioned on Kubernetes for each run and terminated after terraform apply completes, scaling execution without permanent agent infrastructure
• Shared Libraries: Reusable Groovy functions package Terraform pipeline logic into shared libraries that multiple Jenkinsfiles consume

Hands-On: Executing a five-stage Terraform pipeline with Kubernetes agent provisioning, Vault-injected credentials, and manual approval before apply

A developer merges a pull request modifying an RDS instance configuration. A Jenkins multibranch pipeline detects the merge, provisions a Kubernetes agent with the Terraform binary and AWS credentials injected from HashiCorp Vault, and runs five stages in sequence: Checkout Code, Terraform Init, Terraform Plan, a Checkov security scan, and Terraform Apply , with an input step before Apply that sends a Slack notification and waits for a senior engineer to approve in the Jenkins UI. The Jenkins Stage View surfaces per-stage execution times across every build, making it straightforward to see where time is spent and which stages were skipped

Build #1 (11:54) ran the full pipeline via Terraform: Apply (4s), checkout (3s), init (2s), plan, and apply (1min 22s). Build #2 (11:58) carries a No Changes badge: terraform plan detected no diff against the state file, so the Apply stage was skipped entirely and the pipeline moved to Terraform Destroy (1 min 46 s). The average stage times bar across the top confirms that Apply and Destroy dominate the runtime at 1 min 22 s and 1 min 46 s, respectively; the fmt, init, and plan stages together account for under 10 seconds. The agent terminates after the final stage completes; the state is stored in the S3 backend specified in the Terraform configuration and is not managed directly by Jenkins.

Pros

• Maximum pipeline customization, any IaC tool, any workflow logic, any integration
• No per-seat or per-resource licensing cost, only the infrastructure cost of running the Jenkins server
• Fits naturally into organizations where Jenkins already runs every other automated process
• Dynamic Kubernetes agents scale execution capacity without permanent agent infrastructure.
• On-prem execution with no outbound connectivity requirement for air-gapped environments

Cons

• No built-in Terraform state management, policy engine, or drift detection, all require custom pipeline implementation
• Plugin compatibility requires regular auditing; dependency conflicts between plugins create ongoing maintenance overhead
• High operational burden: Jenkins infrastructure, agent pools, plugin upgrades, and security patches are the team's responsibility
• Pipeline complexity accumulates without shared library standardization across Jenkinsfiles

6. Azure DevOps Pipelines

Azure DevOps Pipelines runs Terraform as stages in YAML pipeline files stored in the repository. Like GitHub Actions and GitLab CI/CD, it is a general-purpose CI/CD platform rather than a dedicated IaC management solution; state management, policy enforcement, and drift detection require separate configuration. Its primary advantage in Terraform is native Azure AD identity integration: pipelines authenticate to Azure via Service Connections backed by managed identities or service principals, eliminating the need to store long-lived credentials as pipeline variables.

Key Functionalities

• YAML Pipeline Definitions: Pipeline stages defined as code in the repository, version-controlled alongside Terraform configuration
• Service Connections: Azure AD-backed authentication to Azure, AWS, and GCP without storing long-lived credentials in pipeline variables
• Environment Approval Gates: Deployment environments with configurable required reviewers block the apply stage until approval is received, with approval records persisting in the environment history
• Azure Key Vault Integration: The Key Vault task fetches secrets into pipeline variables at runtime without storing them in the pipeline definition
• Multi-Stage Pipelines: Separate stages for development, staging, and production with independent variable files, backend configurations, and approval policies per stage
• Pipeline Templates: Reusable Terraform plan-and-apply stage definitions consumed by other pipelines through extends syntax, letting a platform team standardize execution logic across all consumers.

Hands-On: Authenticating to Azure through TerraformTaskV4 and Service Connections, running plan with -detailed-exitcode, and applying through environment approval gates

A developer opens a pull request modifying an Azure resource group configuration. A pipeline defined in azure-pipelines.yml triggers: multiple TerraformTaskV4 steps run in sequence, init, validate, plan, and conditionally apply, using an Azure Resource Manager Service Connection to authenticate at runtime. No credentials are stored in the pipeline definition. 

Here is how a completed plan step looks inside the Azure DevOps pipeline job view:

The left panel shows six steps for the current job: Initialize job, Checkout, three TerraformTaskV4 steps (init at 8s, validate at 13s, plan at 15s), and a fourth TerraformTaskV4 still running. The right panel shows the selected plan step executing /usr/local/bin/terraform plan -detailed-exitcode; the -detailed-exitcode flag returns exit code 2 when changes are present and 0 when the infrastructure matches the state, which the pipeline reads to decide whether to proceed with applying. Line 27 outputs No changes. Your infrastructure matches the configuration. after refreshing random_pet.rg_name and azurerm_resource_group.rgagainst their state entries. The state lock is acquired at line 23 and released at line 31, confirming the Azure Blob Storage backend handled concurrent-run protection correctly.

After the plan stage, the deploy-staging stage automatically runs Terraform apply against the staging environment. The deploy-production stage targets the production Azure DevOps Environment, pauses for approval from a configured reviewer group, and then applies after approval. Approval records appear in the environment deployment history alongside pipeline run logs. Terraform variables and backend SAS tokens for Azure Blob Storage are fetched from Azure Key Vault at the start of each stage using the Key Vault task.

Pros

• Native Azure AD identity integration through Service Connections removes long-lived credential management for Azure deployments.
• Environment-specific approval gates with an audit trail are built into the platform, with no additional tooling.
• Pipeline templates let a platform team standardize Terraform execution logic across all consuming pipelines.
• Supports AWS and GCP deployments alongside Azure through provider-specific Service Connections
• Both Microsoft-hosted runners and self-hosted agents for private network deployments

Cons

• No native IaC policy enforcement; policy checks require Checkov or OPA/Conftest wired as pipeline stages.
• No drift detection without a separately scheduled pipeline
• No self-service interface for non-Terraform users
• Terraform deployments to AWS or GCP lose the native identity integration benefit, and provider-specific credentials require manual Service Connection configuration

Terraform Cloud vs Alternatives: Feature Comparison [2026]

What a Migration from Terraform Cloud Requires

Terraform Cloud bundles four things that need separate replacements when you leave: state storage, execution infrastructure, policy enforcement, and credential management. Any migration plan needs to account for all four; switching only the execution layer while leaving state in Terraform Cloud is not a completed migration.

State extraction and backend reconfiguration: Terraform Cloud state is not accessible as a file in a bucket you control. Each workspace state needs to be pulled individually using terraform state pull and saved as a .tfstate JSON file. If you're migrating to StackGuardian, that file uploads directly via Settings → Terraform Configuration → Terraform Customizations → Import Existing Terraform State File; no backend reconfiguration is needed. For other platforms, the cloud {} or remote backend block in each root module needs to be replaced with a self-managed backend (S3, Azure Blob Storage, GCS, or GitLab's HTTP backend). The destination backend must have locking configured (DynamoDB for S3, blob leases for Azure) before state is written to it, and object versioning enabled if audit trails are a compliance requirement.

Execution infrastructure: Terraform Cloud ran terraform plan and terraform apply on HashiCorp-managed compute. The replacement platform needs runners or agents that can reach the Terraform state backend, authenticate to cloud providers, and receive triggers from version control. CI/CD platforms provide this via hosted runners; self-hosted options require the team to provision and maintain compute resources themselves.

Policy replacement: Sentinel policies do not migrate to any alternative platform. Each rule needs to be audited and rewritten before migration completes, using OPA/Rego, Checkov, or a platform-native policy engine. Migrating execution without replacing policy coverage removes governance that was previously enforced automatically.

Credential handover: Terraform Cloud stores cloud provider credentials as workspace- or organization-level variables. The replacement needs a credential mechanism with an equivalent scope: OIDC federation, a secrets manager, Service Connections, or direct cloud account connections, depending on the destination platform.

FAQs

What is the difference between Terraform Cloud and HCP Terraform?

HCP Terraform is the current product name for Terraform Cloud. HashiCorp rebranded Terraform Cloud to HCP Terraform in 2024 as part of a product consolidation under the HashiCorp Cloud Platform. The underlying platform, feature set, and pricing model are unchanged.

Which platform in this list supports OpenTofu natively?

StackGuardian, Atlantis, GitHub Actions, GitLab CI/CD, Jenkins, and Azure DevOps all support OpenTofu. Each platform runs OpenTofu via the CLI; it installs the OpenTofu binary instead of the Terraform binary, and workspace configuration follows the same pattern. Terraform Cloud does not support OpenTofu.

Can GitHub Actions fully replace Terraform Cloud for an enterprise team?

GitHub Actions runs terraform plan and terraform apply from pull requests and handles production approval gates via GitHub Environments. What it does not provide natively: managed remote state (teams configure their own S3 or Azure Blob backend), a policy engine (teams add Checkov or Conftest as workflow steps), and drift detection (teams build scheduled workflows that call plan and report non-zero output). Whether those gaps matter depends on the team's governance requirements.

Is Atlantis a better fit than Terraform Cloud for GitOps workflows?

Atlantis produces a tighter PR-to-apply loop than Terraform Cloud for teams that want plan output directly in the pull request comment thread and apply triggered from a PR comment. Terraform Cloud VCS-driven workspaces also post plan output to PRs, but the run history and apply interface live in the Terraform Cloud UI. Atlantis is self-hosted and free. Terraform Cloud is managed and charges per resource under management. The practical trade-off is the operational overhead of running Atlantis versus the recurring cost of Terraform Cloud's RUM pricing.

Which platform automatically migrates existing cloud infrastructure into Terraform?

StackGuardian's SGCode scans connected AWS, Azure, and GCP accounts, identifies resources without a Terraform state entry, generates Terraform or OpenTofu configuration for selected resources, validates the generated code with an internal plan run, and publishes the result to Git as a pull request. No other platform in this list provides this capability; the remaining platforms assume Terraform code already exists and manage execution from that point forward.

How does StackGuardian's pricing compare to Terraform Cloud's RUM billing at scale?

Terraform Cloud charges a monthly rate that scales with the number of cloud resources in the Terraform state; the bill increases as the infrastructure footprint expands, regardless of how frequently deployments run. StackGuardian uses workflow-based pricing rather than per-resource billing, costs scale with deployment activity, not infrastructure size. For current pricing details, see stackguardian.io/pricing. A team managing 5,000 stable resources with infrequent deployments pays more under a per-resource model than under a per-workflow model. A team running hundreds of daily deployments against a smaller resource count pays more under a per-workflow model. Calculate both against your actual resource count and deployment frequency before deciding.