The Platform Engineer's Guide to Migrating Off Terraform Cloud/Enterprise

Last Reviewed

May 15, 2025

The landscape of Infrastructure as Code (IaC) management is continually evolving. While Terraform Cloud (TFC) and Terraform Enterprise (TFE) have been prominent solutions for many, a confluence of factors—ranging from pricing model changes and licensing adjustments to feature limitations and the desire for greater control—is prompting development teams to explore alternatives. This guide offers a developer-focused, technically grounded perspective on migrating off these platforms. It delves into the reasons for such a move, the practical steps involved in the migration itself, and a detailed exploration of three primary alternative paths: a complete open-source stack, leveraging various Terraform Automation and Collaboration Software (TACOs), and adopting a GitHub Actions-centric architecture. The aim is to equip you with the knowledge to make an informed decision that best suits your team's scale, expertise, and strategic goals.

1. Why Migrate Off Terraform Cloud/Enterprise? The Common Triggers

Making the decision to move away from an established platform like Terraform Cloud or Terraform Enterprise isn't taken lightly. It's typically driven by a collection of pain points that accumulate over time, impacting a team's efficiency, budget, or autonomy. Understanding these common triggers is the first step in evaluating whether a migration is right for your organization.

1.1. Pricing Pains: The RUMbling Discontent

A significant catalyst for many teams considering a move has been HashiCorp's shift in Terraform Cloud's pricing model, primarily to Resources Under Management (RUM). This model calculates costs based on the number of resources managed by Terraform, such as cloud instances, Kubernetes clusters, and even individual security group rules or IAM policies.¹ The core issue with RUM pricing is its potential for unpredictability and rapid cost escalation, especially for organizations with a large or growing resource footprint.⁴

For instance, a team managing 600 resources might find an initial annual cost of around $122, which seems reasonable. However, cloning these resources for a pre-production environment would double the resource count to 1200, but the cost could jump to $858—a seven-fold increase rather than a simple doubling. This non-linear scaling ($0.20/resource/year at 600 resources vs. $0.72/resource/year at 1200 resources) makes budgeting difficult and can penalize growth or standard practices like environment duplication.⁷ Some analyses show that costs can become prohibitively expensive at scale, with users reporting significant price hikes, sometimes 300% to 600% of their initial costs under previous models.³ The standard TFC plan, for example, might charge $0.00014 per resource per hour after a free tier of 500 resources.⁴ While this might be beneficial for very small teams managing under 500 resources ³, it quickly becomes a concern as infrastructure scales.

Terraform Enterprise, the self-hosted variant, also comes with substantial costs. Marketplace listings indicate one-time payments starting around $15,000 for a year for a limited number of workspaces and basic support, with average annual costs potentially reaching $37,000.² These figures often don't include the operational overhead of managing the self-hosted instance itself.

The pricing structure of TFC's lower tiers can also be restrictive, with limits on features like policy sets and run tasks, effectively pushing users towards more expensive tiers even if they don't need all the features of that higher tier.¹ This contrasts with some alternatives where more features are included even in free or lower-cost plans.⁴

1.2. Licensing Changes & Uncertainty: The BSL Factor

Beyond pricing, HashiCorp's decision to change the license for Terraform and other core products from the Mozilla Public License v2 (MPL v2) to the Business Source License (BSL) 1.1 has been a major point of contention.¹ The BSL is not a traditional open-source license; while the source code is available, it includes restrictions on use, particularly for entities that might be seen as competing with HashiCorp's commercial offerings. This has created uncertainty and concern within the community about vendor lock-in and the future direction of Terraform's openness.⁵ The ambiguity of what constitutes "competing" use under the BSL has led some organizations to seek alternatives that remain under unequivocally open-source licenses, such as OpenTofu, a community-driven fork of Terraform.² Adding to this unease were, at times, rumors about HashiCorp potentially being sold, further fueling a desire for more stable and predictable tooling foundations.¹

1.3. Feature Limitations & Control: Seeking More Than Just Terraform

While TFC/TFE provide a managed Terraform experience, they come with certain limitations that can frustrate teams looking for broader capabilities or finer-grained control:

Terraform-Only Management: TFC is primarily designed for Terraform. Support for other IaC tools like Pulumi, CloudFormation, Ansible, or Kubernetes direct manifest management is either non-existent or very limited.¹ Teams using a diverse set of IaC tools often find themselves needing multiple management platforms, increasing complexity.

Workflow Rigidity:

No Native Dependency Workflows: TFC lacks native capabilities to define and manage dependencies between workspaces. This makes it difficult to implement complex environment promotion strategies or orchestrate deployments where one set of infrastructure depends on another.¹
Limited Control Over Runner Phases: Users have restricted ability to customize what happens between all runner phases (e.g., before init, after plan, before apply). This limits the integration of custom scripts or checks directly into the core workflow execution.¹
Run Task Limitations: While run tasks allow some third-party tool integration, the number of run tasks and the workspaces they can apply to are often limited in lower pricing tiers.¹

No-Code Provisioning Constraints: The no-code provisioning feature in TFC is often limited to publishing individual modules. This can lead to an anti-pattern where teams create "module of modules" just to fit into this self-service model, complicating module design and maintenance.¹

Policy Limitations: Lower tiers of TFC impose strict limits on the number of policy sets and policies within them (e.g., one policy set with five policies, only one of which can be mandatory).¹ This can be insufficient for organizations needing robust governance.

Support Concerns: Some users have reported dissatisfaction with the level of support received from HashiCorp when encountering issues.¹

1.4. Terraform Core Pain Points: Challenges Inherited or Unsolved

Some of the reasons for seeking alternatives stem from inherent complexities or missing features in Terraform CLI itself, which TFC/TFE may not fully alleviate or might even exacerbate in a managed context:

Workspace Complexity: While Terraform workspaces aim to manage different environments, they can lead to complex code relying heavily on the count parameter and conditional logic, making configurations hard to understand and scale.¹³
Module Version Management: A long-standing limitation is the inability to use variable interpolation within the source and version attributes of a module block. This makes dynamic module sourcing or version pinning based on environment variables cumbersome.¹³
Backend Configuration Rigidity: Hardcoding backend configuration details directly in Terraform files is common, but if not managed carefully (e.g., when copying root modules), it can lead to state file conflicts or accidental destruction if the wrong state is referenced.¹³
Repetitive Provider Configuration: Managing provider configurations across many modules or environments can involve significant code duplication and manual effort.¹³
Debugging Challenges: Debugging HCL can be a frustrating experience. The language lacks robust conditional statements (like traditional if-else blocks outside of ternary operators or resource count/for_each meta-arguments), and developers often rely on outputting intermediate values to understand logic flow. The feedback cycle of init/plan can be slow, especially for large configurations, making iterative debugging a chore.¹⁴ Using terraform console can help but isn't a full debugging environment.¹⁴
Performance Bottlenecks at Scale: As infrastructure grows, Terraform operations (plan and apply) can become very slow. High memory consumption and resource conflicts/dependencies also contribute to performance degradation.¹⁴ Terraform's default concurrency for operations can also be a limiting factor in large environments.¹⁷ While TFE allows tuning concurrency and memory per run, this requires careful capacity planning of the TFE instance itself.¹⁸

These triggers—economic, philosophical, and technical—collectively push teams to evaluate whether Terraform Cloud or Enterprise still aligns with their evolving needs and to explore the diverse ecosystem of alternative IaC management solutions.

2. Core Migration Steps: Getting Your State and Configs Out

Migrating off Terraform Cloud or Terraform Enterprise is a significant undertaking that goes beyond just changing a few lines of configuration. The primary goal is to decouple your IaC workflows from TFC/TFE's state backend and execution environment, giving you the freedom to choose a new operational model. This section outlines the critical steps involved in this transition.

2.1. Pre-migration Checklist: Planning Your Escape

Before you start any technical migration, thorough preparation is key to a smooth transition:

Inventory Existing Setup:

Identify all Terraform Cloud/Enterprise workspaces.
Document the VCS repositories linked to each workspace, including specific branches and working directories.
List all Terraform versions used across workspaces.

State File Audit and Backup:

For each workspace, confirm the current state of its resources.
Crucially, back up all existing state files. This can typically be done via the TFC/TFE API ¹⁹ or by using the terraform state pull command for each workspace.²¹ Store these backups securely.

Configuration Data Collation:

Document all environment variables (both Terraform variables like TF_VAR_name and shell variables) configured in each TFC/TFE workspace.
Securely extract and document all sensitive variables (secrets). These will need to be re-input into your new secrets management solution.
Note any specific VCS connection settings, SSH keys, or Oauth configurations used by TFC/TFE.

Strategic Decisions:

Choose your target backend: Decide whether you'll use a cloud object storage service (AWS S3, Azure Blob, GCS) or if your chosen TACO will manage the state.
Define your new CI/CD strategy: Determine if you'll use a full open-source stack with custom CI/CD, a TACO's built-in CI/CD, or a GitHub Actions-based approach.
Plan for variable and secret management: Select the new system for storing and injecting variables and secrets (e.g., TACO's native store, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, CI/CD platform secrets).

Communication Plan: Inform all relevant stakeholders (development teams, operations, security) about the upcoming migration, potential impacts, and timelines.

2.2. Migrating Terraform State: The Heart of the Operation

The most critical technical step is migrating your Terraform state files. The process differs slightly depending on how your TFC/TFE workspaces were configured.

2.2.1. Migrating from TFC with the cloud {} Block

If your Terraform configurations use the cloud {} block to integrate with Terraform Cloud, the standard terraform init -migrate-state command is often not a reliable method for migrating to a different backend type like S3, Azure Blob, or GCS.²¹ HashiCorp's own documentation and user experiences suggest that this direct migration path is not fully implemented or supported for this scenario.²³

The necessity for a more manual approach when moving away from the cloud {} block—which is often the recommended way to use TFC—can be a source of friction. While standard Terraform allows for relatively seamless state migration between compatible backends using terraform init -migrate-state ²⁴, the cloud {} block introduces a different integration pattern. The lack of a straightforward, automated off-boarding mechanism from this configuration can feel like a soft form of vendor lock-in, or at least an oversight that complicates a common desire to switch platforms. This adds an unexpected layer of complexity and potential for error during a critical infrastructure transition.

Recommended Manual Process (per workspace):

Authenticate (if necessary): If your local CLI isn't already authenticated to TFC, run terraform login <your-tfc-organization-hostname>.
Initialize for TFC: Navigate to the directory of the Terraform configuration corresponding to the TFC workspace. Run terraform init. This ensures your local setup is correctly pointing to the TFC backend.
Pull State Locally: Execute terraform state pull > temp.tfstate.²¹ This command downloads the current state file from TFC and saves it as temp.tfstate in your local directory.
Remove TFC Configuration: Delete the cloud {} block from your Terraform configuration files (e.g., main.tf or a dedicated backend.tf).
Add New Backend Configuration: Add the configuration block for your chosen new backend (S3, GCS, Azure Blob, etc.) to your Terraform files.
Clear Local Backend Cache: Remove the .terraform directory by running rm -rf.terraform/. This is crucial to ensure Terraform "forgets" the previous TFC backend initialization and correctly processes the new backend configuration.
Initialize New Backend: Run terraform init. Terraform will now read your new backend configuration and initialize it.
Push State to New Backend: Execute terraform state push temp.tfstate.²¹ This command uploads the temp.tfstate file (which you pulled from TFC) to your newly configured backend.
Verify: After pushing, you can run terraform plan to ensure Terraform can read the state from the new backend and that it matches your infrastructure.

This process needs to be repeated for each workspace you are migrating. For a large number of workspaces, scripting these steps is highly recommended.

2.2.2. Migrating from Terraform Enterprise (or TFC with backend "remote")

If your TFE instance (or older TFC setup) was configured using a standard backend "remote" block, the terraform init -migrate-state command might offer a smoother transition to another standard backend. However, given the potential for issues, the manual pull/push method described above is generally a safer and more reliable approach.

Alternatively, TFC/TFE provide APIs that can be used to list and download state versions.¹⁹ This could be an option for programmatic state export, especially for archival or complex migration scenarios. The tf-migrate tool, while often mentioned for migrations to TFC/TFE ²⁰, has limited applicability for migrating from TFC when the cloud {} block is in use.

2.2.3. Target Backend Examples

Regardless of the source, you'll need to configure your new backend. Here are common examples:

AWS S3 + DynamoDB:

Terraform Code for S3 Bucket & DynamoDB Table (Best Practice Setup):It's recommended to create these resources with a separate, dedicated Terraform configuration or manually, ensuring they exist before your main configurations try to use them as a backend.

resource "aws_s3_bucket" "tf_state" {
  bucket = "your-terraform-state-bucket-name" // Ensure this is globally unique

  lifecycle {
    prevent_destroy = true
  }
}

resource "aws_s3_bucket_versioning" "tf_state_versioning" {
  bucket = aws_s3_bucket.tf_state.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "tf_state_sse" {
  bucket = aws_s3_bucket.tf_state.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "aws_s3_bucket_public_access_block" "tf_state_public_access" {
  bucket = aws_s3_bucket.tf_state.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_dynamodb_table" "tf_lock" {
  name         = "your-terraform-lock-table-name"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

This configuration establishes an S3 bucket with versioning and server-side encryption enabled, and public access blocked. It also creates a DynamoDB table for state locking, which is crucial for preventing concurrent modifications to the state file.²⁴

Terraform Backend Configuration (backend.tf in your main configuration):

terraform {
  backend "s3" {
    bucket         = "your-terraform-state-bucket-name" // Matches the bucket created above
    key            = "path/to/your/terraform.tfstate"   // e.g., projectA/env/terraform.tfstate
    region         = "us-east-1"                        // Region of the S3 bucket
    dynamodb_table = "your-terraform-lock-table-name"   // Matches the DynamoDB table created
    encrypt        = true                               // Ensures state file is encrypted in S3
  }
}

Snippet Analysis: ²¹ outlines the basic pull/push migration steps. ²⁴ details S3 backend configuration elements and the init -migrate-state command, though for TFC cloud {} block, manual pull/push is more reliable. ²⁸ provides an example of the S3 backend block.

Azure Blob Storage:

Setup: Create an Azure Storage Account and a Blob Container within it. Ensure appropriate access controls and ideally enable versioning and encryption.
Terraform Backend Configuration (backend.tf):

terraform {
  backend "azurerm" {
    resource_group_name  = "your-tfstate-resource-group"
    storage_account_name = "yourtfstatestorageaccount" // Must be globally unique, lowercase, and 3-24 chars
    container_name       = "tfstate"
    key                  = "path/to/your/terraform.tfstate"
    // For authentication, consider using MSI, Service Principal with OIDC, or SAS token
    // use_azuread_auth = true (if using AAD auth)
    // tenant_id = "..."
    // client_id = "..."
    // client_secret = "..." (use environment variables for secrets)
  }
}

Snippet Analysis: ²² describes migrating to Azure Blob Storage, including considerations for workspaces and different authentication methods. ³⁴ provides extensive details on authentication options for the azurerm backend.

Google Cloud Storage (GCS):

Setup: Create a GCS bucket. Enable object versioning for safety.
Terraform Backend Configuration (backend.tf):

terraform {
  backend "gcs" {
    bucket  = "your-terraform-state-gcs-bucket" // Must be globally unique
    prefix  = "path/to/your/terraform.tfstate"  // Path within the bucket
    // For authentication, Application Default Credentials (ADC) are often used when running from GCP.
    // Otherwise, provide 'credentials = "path/to/service-account-key.json"' (use env var for path)
  }
}

Snippet Analysis: ²⁵ and ³⁵ provide detailed guides for migrating to GCS, including bucket setup and the init -migrate-state step. ³⁶ details GCS backend configuration options.

2.3. Migrating Variables, Secrets, and VCS Connections

Simply moving the state file is not enough. TFC/TFE also manage workspace-specific variables, including sensitive secrets, and VCS connections.

Variables: These can usually be exported from the TFC/TFE UI or via API. They need to be re-imported into your new system. This could be:

The variable management system of your chosen TACO.⁵
.tfvars files (less ideal for secrets).
CI/CD pipeline variables.

Secrets (Sensitive Variables): TFC/TFE encrypt sensitive variables at rest. These cannot typically be exported directly. You will need to re-enter these secrets into your new chosen secrets management solution.⁵ This could be:

The TACO's secret store (if it offers one with adequate security).
A dedicated secrets manager like HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager.
CI/CD platform's encrypted secrets (e.g., GitHub Actions Secrets).

VCS Connections: You'll need to re-establish connections between your VCS provider (GitHub, GitLab, etc.) and your new IaC management system (TACO, CI/CD pipeline). This involves setting up webhooks, access tokens, or OIDC configurations.

The process of migrating variables and especially secrets underscores that moving off TFC/TFE is more than just a backend swap; it's an architectural shift. The chosen alternative's capabilities in handling these elements will heavily influence the migration effort and the subsequent operational model. If the new system doesn't have robust, integrated variable and secret management, you'll need to implement and manage these capabilities separately, adding to the complexity of the open-source or GitHub Actions paths.

2.4. Leveraging Automated Migration Tools (Where Applicable)

Several tools can assist with migrations, but their applicability for moving off TFC/TFE varies:

HashiCorp's tf-migrate: This CLI tool ²⁰ is primarily designed for migrating state to HCP Terraform or Terraform Enterprise, or between other standard backends. It is generally not effective for migrating state from a TFC workspace configured with the cloud {} block to a standard backend like S3.

TACO-Specific Migration Kits:

Scalr Migration Kit: If you are migrating to Scalr, this kit can help export configurations from TFC and generate Terraform/OpenTofu code to manage your Scalr setup.¹ It typically handles workspace settings and variables but may require manual state migration for complex cases.
env0/Spacelift Migration Tool: Similarly, if env0 or Spacelift is your target, their migration tool can assist in copying workspace settings, VCS configurations, and variable values (excluding sensitive ones) from TFC to env0/Spacelift environments.⁵ State migration might still involve manual steps or API usage.

These tools streamline parts of the migration to a specific platform but don't offer a universal solution for exiting TFC/TFE to any arbitrary backend or setup.

2.5. Updating CI/CD Pipelines and Local Developer Workflows

Once state and variables are migrated, your CI/CD pipelines and local developer workflows must be updated:

Authentication: CI/CD pipelines will no longer use TFC/TFE API tokens. They'll need to be configured with new credentials for your chosen backend (e.g., IAM roles for S3 via OIDC, service principals for Azure Blob, service accounts for GCS) and potentially for your new TACO if one is chosen. Local developer setups will also need to reconfigure authentication.

Terraform Commands:

If moving to a pure CLI-based workflow (open-source path or GitHub Actions), your CI/CD will execute standard terraform init, terraform plan, and terraform apply commands, pointing to the new backend.
If moving to a TACO, you might use the TACO's own CLI or API to trigger runs, which then executes Terraform in the TACO's managed environment.

Backend Initialization: Ensure all terraform init commands in CI/CD and local environments correctly point to the new backend configuration. Remove any TFC/TFE specific login commands or configurations.

This comprehensive migration process, addressing state, variables, secrets, and CI/CD, sets the stage for operating your IaC under a new management paradigm. The next sections will explore what these new paradigms look like in detail.

3. Open Source Path: The Full Open-Source Stack – Maximum Control, Maximum Responsibility

Opting for a full open-source stack means taking complete ownership of your Infrastructure as Code (IaC) pipeline. This path typically involves using the core Terraform Command Line Interface (CLI)—or its open-source fork, OpenTofu, to avoid BSL concerns ²—coupled with self-managed remote backends and an orchestration tool like Terragrunt to manage complexity. This approach offers the highest degree of control and flexibility but also demands significant in-house expertise and operational effort.

The choice of OpenTofu over Terraform in a fully open-source stack is often a deliberate decision stemming from HashiCorp's shift to the Business Source License (BSL) for Terraform.¹ This licensing change raised concerns in the community about the long-term openness of Terraform and potential restrictions on its use, particularly for those building tools or services around it.⁸ OpenTofu emerged as a community-driven, MPLv2-licensed fork, aiming to provide a truly open-source and collaboratively governed alternative.² For organizations prioritizing these open-source principles and community governance, adopting OpenTofu is a way to ensure their IaC foundation remains unencumbered by potentially restrictive commercial licensing, even if it means relying on a fork.

3.1. Remote Backend Choices (Self-Managed)

As detailed in the core migration steps (Section 2.2.3), you'll select a remote backend for your Terraform state files. Common choices include:

AWS S3 + DynamoDB: S3 for state file storage, DynamoDB for state locking.²¹
Azure Blob Storage: For state file storage, with mechanisms for locking.²²
Google Cloud Storage (GCS): For state file storage, with locking capabilities.²⁵

Regardless of the chosen cloud provider, it is paramount to configure the backend with versioning (to recover from accidental deletions or corruptions), server-side encryption (to protect sensitive data in the state file at rest), robust state locking (to prevent concurrent writes and state corruption), and strict access controls (IAM policies granting least privilege access to the state storage and lock mechanism).

3.2. Orchestration and Structure with Terragrunt

While Terraform/OpenTofu provides the core IaC engine, managing multiple environments, ensuring DRY (Don't Repeat Yourself) configurations, and handling inter-module dependencies can become cumbersome with the CLI alone.¹³ Terragrunt, a thin wrapper around Terraform, directly addresses these pain points.³⁷

3.2.1. Key Terragrunt Features

DRY Configurations: Terragrunt allows you to define common configurations (like backend settings, provider versions, and input variables) in one place and inherit them across multiple modules and environments using include blocks and functions like read_terragrunt_config.³⁷ This significantly reduces repetition.

Automated Backend Configuration: Terragrunt can dynamically generate the backend.tf file for each module based on a remote_state block in your terragrunt.hcl files. This ensures consistency and reduces the risk of manual errors in backend setup.⁴³

Example Terragrunt remote_state block for S3:

// Example: root terragrunt.hcl or common configuration file
remote_state {
  backend = "s3"
  generate = {
    path      = "backend.tf" // File to generate
    if_exists = "overwrite_terragrunt" // Behavior if file exists
  }
  config = {
    bucket         = "your-terragrunt-state-bucket" // Central S3 bucket for Terragrunt-managed states
    key            = "${path_relative_to_include()}/terraform.tfstate" // Dynamically sets key based on module path
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "your-terragrunt-lock-table" // Central DynamoDB table for locking

    s3_bucket_tags = { // Tags for Terragrunt to apply if it creates the bucket
      Name        = "Terragrunt State Bucket"
      Environment = "SharedIaC"
    }
    dynamodb_table_tags = { // Tags for Terragrunt to apply if it creates the lock table
      Name        = "Terragrunt Lock Table"
      Environment = "SharedIaC"
    }
  }
}

This configuration (often placed in a root or common terragrunt.hcl file and included by individual modules) tells Terragrunt to use an S3 backend. The key is dynamically generated using path_relative_to_include(), ensuring each module has a unique state file path within the bucket. Terragrunt can even create the S3 bucket and DynamoDB table if they don't exist, applying specified tags.⁴³

Dependency Management: Terragrunt allows you to define explicit dependencies between your infrastructure modules using dependency blocks. This ensures that modules are applied in the correct order and allows you to pass outputs from one module as inputs to another.³⁷

Example Terragrunt dependency block:

// Example: terragrunt.hcl for an application module depending on a VPC module
dependency "vpc" {
  config_path = "../vpc" // Path to the Terragrunt configuration for the VPC module

  // Optional: Mock outputs can be used for local planning if the dependency
  // hasn't been applied yet, or for testing.
  // mock_outputs = {
  //   vpc_id            = "vpc-mock123"
  //   public_subnet_ids = ["subnet-mockpub1", "subnet-mockpub2"]
  //   private_subnet_ids = ["subnet-mockpriv1", "subnet-mockpriv2"]
  // }
  // mock_outputs_allowed_terraform_commands = ["plan", "validate"] // Only use mocks for these commands
}

inputs = {
  vpc_id         = dependency.vpc.outputs.vpc_id
  subnet_ids     = dependency.vpc.outputs.public_subnet_ids // Or private_subnet_ids as needed
  // other application inputs
}

Here, the application module declares a dependency on the "vpc" module. Terragrunt will ensure the VPC is applied before the application. The dependency.vpc.outputs map provides access to the output values from the VPC module.⁴⁷ mock_outputs can be useful for local development or CI plan stages before dependencies are deployed.⁴⁷

Managing Multiple Environments/Accounts: Terragrunt excels at managing infrastructure across multiple environments (e.g., dev, staging, production) and multiple cloud accounts or regions. This is typically achieved through a hierarchical directory structure where common configurations are inherited and environment/account-specific inputs are overridden.³⁷

3.2.2. Typical Terragrunt Project Structure

A common and effective way to structure Terragrunt projects, often influenced by practices from organizations like Cloudposse, involves a "live" repository (e.g., infrastructure-live) containing the Terragrunt configurations that deploy reusable Terraform modules (which might reside in a separate infrastructure-modules repository or be sourced from public/private registries).

Directory Layout:

A root terragrunt.hcl often defines global configurations like the remote_state block, provider versions, and common input variables.
Environment-specific configurations might be organized into directories like _envcommon (for settings shared across all environments within an account/region) or through files like env.hcl, account.hcl, and region.hcl at different levels of the hierarchy, which are then included into component configurations.
The infrastructure is broken down into components (e.g., vpc, eks, rds, app-service), each with its own terragrunt.hcl file. These files specify the source of the underlying Terraform module and provide the necessary inputs.

Example terragrunt.hcl Files:

Root terragrunt.hcl (Example for AWS S3 backend):

// infrastructure-live/terragrunt.hcl
locals {
  aws_region     = "us-east-1"
  company_name   = "mycorp"
  // Other global variables or locals
}

remote_state {
  backend = "s3"
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite_terragrunt"
  }
  config = {
    bucket         = "mycorp-tfstate-${get_aws_account_id()}" // Example: Bucket per account
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = local.aws_region
    encrypt        = true
    dynamodb_table = "mycorp-tf-locks" // Single lock table often sufficient

    profile        = get_env("AWS_PROFILE", "default") // For local execution
  }
}

generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
provider "aws" {
  region  = "${local.aws_region}"
  # Assume role configuration can also be centralized here
  # default_tags {
  #   tags = {
  #     TerragruntGenerated = "true"
  #     Environment       = try(basename(dirname(get_terragrunt_dir())), "unknown") // Basic env tagging
  #   }
  # }
}
EOF
}

// Common inputs to be merged into all child modules
inputs = merge(
  {
    aws_region = local.aws_region
  },
  // Potentially load more common inputs from other files
  // yamldecode(file("${get_terragrunt_dir()}/common_vars.yaml"))
)

This root configuration sets up the S3 backend, generates a basic AWS provider configuration, and defines some local variables and common inputs.

Environment Configuration (e.g., environments/dev/env.hcl):

// infrastructure-live/environments/dev/env.hcl
locals {
  environment_name = "dev"
  instance_size    = "t3.micro"
  // Other dev-specific variables
}

inputs = {
  environment = local.environment_name
  // Dev specific tags or configurations
}

This file defines variables and inputs specific to the 'dev' environment.

Component terragrunt.hcl (e.g., using a Cloudposse module for an S3 bucket):

// infrastructure-live/environments/dev/us-east-1/app-storage/terragrunt.hcl
include "root" {
  path = find_in_parent_folders() // Includes the root terragrunt.hcl
}

include "environment" {
  path = find_in_parent_folders("env.hcl") // Includes dev/env.hcl
}

// Potentially include account or region specific HCL files as well

locals {
  // Read context from included files and merge
  context_vars = {
    namespace   = include.root.locals.company_name
    environment = include.environment.locals.environment_name
    stage       = "main" // Or derive from path
    name        = "app-data"
    attributes  = ["logs"]
    region      = include.root.locals.aws_region
    //... other context fields required by Cloudposse modules
    tags = {
      Terraform   = "true"
      Terragrunt  = "true"
      Environment = include.environment.locals.environment_name
    }
  }
}

terraform {
  source = "git::https://github.com/cloudposse/terraform-aws-s3-bucket.git?ref=2.2.0" // Pin to a specific version
}

inputs = merge(
  include.root.inputs,
  include.environment.inputs,
  {
    context = local.context_vars // Pass the constructed context object
    // Module-specific inputs for terraform-aws-s3-bucket
    acl     = "private"
    versioning_enabled = true
    // name, namespace, environment, etc., are usually derived from the context object by the module
  }
)

Based on ⁵² (Cloudposse context), ⁵⁵ (Cloudposse module usage), ⁵⁶ (general structure). This component terragrunt.hcl includes configurations from parent files (root, environment). It constructs a context object, a common pattern in Cloudposse modules for consistent naming and tagging. It then sources a specific version of a Cloudposse S3 bucket module and passes the context object along with other module-specific inputs.

‍The adoption of Terragrunt, particularly with established conventions like those from Cloudposse (e.g., atmos tool for enhanced CLI experience and stack management ⁵², and the context.tf pattern for standardized module inputs ⁵²), creates a highly opinionated framework. This structure is powerful for achieving DRY configurations and managing complex deployments. However, it also means teams invest in learning this specific ecosystem. While this solves many Terraform OSS pain points, it moves away from "vanilla" Terraform skills and can increase the learning curve for new team members or those unfamiliar with Terragrunt's HCL extensions and operational model. Debugging also requires understanding these layers of abstraction.⁴¹

3.3. Tradeoffs for the Full Open-Source Stack

Choosing the full open-source path has significant implications:

Pros:

Maximum Control & Flexibility: Your team dictates every aspect of the IaC pipeline, from tool versions to workflow logic. There are no vendor-imposed limitations on customization.⁵⁹
Cost-Effectiveness (Direct Software Costs): The primary software components (Terraform/OpenTofu CLI, Terragrunt) are free. Costs are generally limited to the underlying infrastructure for CI/CD runners and state storage backend services (e.g., S3, GCS, Azure Blob).² This avoids per-user, per-resource, or per-run fees associated with managed platforms.
No Vendor Lock-in: Complete freedom to choose, combine, and switch out components of your toolchain. Using OpenTofu further mitigates concerns related to HashiCorp's BSL.⁸
Strong Community Support: Terraform, OpenTofu, and Terragrunt have large, active communities providing ample documentation, examples, and support forums.

Cons:

Higher Operational Overhead: The team is fully responsible for the setup, maintenance, security, and scaling of all tooling components, including the CI/CD system, state backend infrastructure, and keeping Terragrunt/Terraform versions managed.⁴⁰
Significant In-House Expertise Required: Deep knowledge of Terraform/OpenTofu, Terragrunt, the chosen CI/CD system (e.g., Jenkins, GitLab CI, GitHub Actions custom setup), cloud provider services for backends, and security best practices is essential.⁴¹
DIY for Advanced Features: Implementing features like RBAC, comprehensive Policy as Code (PaC), advanced audit trails, and sophisticated drift detection requires integrating and managing separate open-source tools (e.g., OPA, Checkov) or building custom solutions. There's no out-of-the-box UI for centralized management or visualization.⁶²
Potential for "Yak Shaving": Teams can spend a disproportionate amount of time building and maintaining the IaC platform itself, rather than delivering business value through infrastructure.⁵⁹
Terragrunt's Learning Curve & Complexity: While powerful, Terragrunt adds another layer of abstraction and its own HCL constructs, which can be complex to master.⁴⁰
Performance at Scale with Terragrunt: Large Terragrunt deployments with many modules and inter-dependencies can suffer from performance issues (e.g., slow plan-all or apply-all operations) if not carefully structured and optimized (e.g., using provider caching, minimizing inter-dependency graph complexity).⁵⁸

The "Full Open-Source Stack" is not truly "free" when considering the Total Cost of Ownership (TCO). While direct software licensing costs are minimal or non-existent, the TCO shifts significantly towards indirect costs. These include the extensive engineering hours required for initial setup, ongoing maintenance, security hardening, integration of disparate tools, and the operational support for the entire custom-built platform.⁶¹ This path demands a high level of team expertise, discipline, and a dedicated effort to essentially build and run an internal IaC platform service.

3.3.1. Developer Experience Considerations

Pain Points Addressed:

Eliminates TFC/TFE pricing concerns and licensing restrictions (especially with OpenTofu).
Provides developers with complete control over the IaC workflow and toolchain.

Pain Points Introduced:

Debugging: Troubleshooting can be complex, involving not just Terraform/OpenTofu errors (TF_LOG is indispensable ¹⁴) but also Terragrunt's generated code, include block logic, and dependency resolutions.⁴¹ Issues might also arise from the custom CI/CD pipeline or backend misconfigurations.
Performance Management: Developers might face slow feedback loops with large Terragrunt plan-all or apply-all operations if the setup isn't optimized.⁵⁸ Understanding and tuning Terragrunt's caching and dependency fetching mechanisms becomes important.
Setup and Maintenance Burden: The initial setup of the entire toolchain (backend, CI/CD, Terragrunt structure) can be time-consuming. Ongoing maintenance of versions, security patches for CI runners, and backend infrastructure falls on the team.⁵⁹
Lack of Centralized UI: Without integrating additional tools, there's no central dashboard for visualizing deployments, state, or managing collaboration, which can be a drawback compared to managed platforms.

3.4. Success Indicators for the Full Open-Source Path

Success with this approach is typically indicated by:

Demonstrable reduction in direct IaC vendor licensing costs.
A high degree of automation across the IaC lifecycle, tailored precisely to the organization's specific needs and workflows.
The presence of a skilled and dedicated platform or DevOps team capable of efficiently managing, securing, and evolving the complex toolchain.
Faster resolution of IaC-related issues due to deep system understanding and full control over all components.
The ability to quickly adopt new open-source innovations or adapt the platform to changing requirements without vendor constraints.

This path is most suitable for organizations with mature DevOps practices, strong in-house technical expertise, a culture of ownership, and a clear understanding of the long-term commitment required to maintain such a system.

4. SaaS Path: Leveraging TACOs – Managed Experience with Varying Flavors

For teams seeking to offload some of the operational burden associated with a fully self-managed open-source stack, Terraform Automation and Collaboration Software (TACOs) present a compelling alternative. These platforms are typically built on top of or around Terraform/OpenTofu, offering a suite of enhanced capabilities designed to streamline IaC workflows, improve collaboration, and enforce governance.¹⁰ They aim to address the limitations of using Terraform OSS in isolation and provide a more managed experience, often as direct alternatives to Terraform Cloud/Enterprise.⁵⁹

Common features found in TACOs include centralized state management, integrated CI/CD pipelines for IaC, Role-Based Access Control (RBAC), Policy as Code (PaC) enforcement (often using Open Policy Agent - OPA), drift detection, collaborative workflows, and user interfaces or dashboards for better visibility.¹¹

The TACO market is diverse, with vendors differentiating on crucial aspects such as their pricing models (which can be run-based, resource-based, deployment-based, or user-based), the breadth of IaC tools they support beyond Terraform, and the depth of specific features like cost management, policy engine flexibility, or workflow customization options.³ This variety means that selecting a TACO is not a one-size-fits-all decision. It requires a careful evaluation of an organization's primary reasons for moving off TFC/TFE—be it cost, the need for greater flexibility, multi-tool support, or more robust governance—and then mapping these requirements to the TACO that best addresses those specific needs. It's a mistake to assume all TACOs offer an identical value proposition.

Furthermore, while TACOs aim to simplify IaC management by abstracting away some of the complexities of self-managing state and CI/CD pipelines ⁷⁷, they introduce their own layer of abstraction and, with it, a new set of platform-specific behaviors and potential for vendor lock-in. The "ease of debugging" and "integration challenges" can shift from troubleshooting Terraform code in a familiar environment to diagnosing the TACO's internal behavior, its policy evaluations, or its interaction with underlying runners.⁶⁶ This requires developers to acquire new skills and a deep understanding of the chosen TACO platform, which can be a form of "soft" lock-in.

A significant development in the TACO landscape is the widespread support for OpenTofu by many leading vendors, including Scalr, Spacelift, and env0.⁸ This rapid adoption following Terraform's BSL change provides a crucial pathway for users who are concerned about HashiCorp's licensing but still desire the benefits of a managed IaC platform. It allows organizations to pair an open-source IaC engine with the convenience and advanced features of a TACO, validating OpenTofu as a viable alternative and offering a less disruptive migration path for those prioritizing open-source principles.

4.1. Scalr

Scalr positions itself as a remote operations backend for Terraform and OpenTofu, emphasizing a hierarchical organizational model, predictable run-based pricing, and flexible workflows.⁴

Key Features:

Hierarchical Model: Organizes resources into Admin Scope, Environment Scope, and Workspaces, allowing for inheritance of configurations (variables, provider credentials, policies) in a way that can mirror cloud provider organizational structures (e.g., AWS Organizations).⁹²
Run-Based Pricing: Charges primarily per qualifying Terraform/OpenTofu run (apply or dry run), with a free tier including 50 runs/month and all features. Paid plans offer volume discounts, and there are no extra costs for users, concurrency (starts at 5, scalable), or self-hosted agents on paid tiers.⁴
Policy as Code (OPA): Integrates Open Policy Agent for both pre-plan (evaluating run context like source, user) and post-plan (evaluating planned resource changes) checks. Supports policy groups, impact analysis for policy changes, and OPA functions.¹⁰⁷
Flexible Workflows: Supports GitOps (including Atlantis-style PR comments for plan/apply), CLI-driven runs (local execution with remote state), and module-driven workflows (self-service catalog).⁶⁵
RBAC: Granular Role-Based Access Control with over 120 permissions that can be grouped into custom roles and assigned at account, environment, or workspace scopes.⁸⁶
Drift Detection: Provides drift detection and reporting capabilities.⁴
OpenTofu Support: Natively supports OpenTofu alongside Terraform.⁸
Integrations: Native integrations with tools like Datadog, Slack, AWS EventBridge, and support for Checkov.⁸⁶
Global Module Registry: Allows modules to be registered at the account scope and shared across environments.⁸⁶

Architecture Overview:
Scalr's architecture is designed around a three-tiered hierarchy:

Administration Scope: The top-level control plane for managing environments, global IAM, policies (OPA), module registry, provider configurations, and variables. Provides a global dashboard for all operations.⁹²
Environment Scope: Logical groupings of workspaces, teams, and inherited configurations. Environments enable self-service for platform teams and isolate resources.⁹²‍
Workspace Scope: Where Terraform/OpenTofu runs are executed, state is stored (either managed by Scalr or user's own backend), and deployment-specific objects are linked.⁹² This model allows for object inheritance; for example, variables or policies defined at the admin scope can be assigned and inherited by environments, which are then inherited by workspaces.⁹²

OPA Policy Example (Scalr Context - Enforce Tagging):

package terraform
import input.tfplan as tfplan

# Define required tags
required_tags = {"Environment", "Owner", "Project"}

# Helper to check if all required tags are present
has_all_required_tags(resource_tags) {
    all_required_present := {tag | tag := required_tags[_]; resource_tags[tag]}
    count(all_required_present) == count(required_tags)
}

deny[reason] {
    resource := tfplan.resource_changes[_]
    # Check for resources being created or updated (not deleted)
    action := resource.change.actions[count(resource.change.actions) - 1]
    array_contains(["create", "update"], action)

    # Check if the resource type typically supports tags (customize as needed)
    taggable_resource_types := {"aws_instance", "aws_s3_bucket", "aws_vpc"}
    taggable_resource_types[resource.type]

    # Get the tags from the 'after' state of the resource
    tags_after = resource.change.after.tags
    not has_all_required_tags(tags_after)

    missing_tags := required_tags - {key | tags_after[key]}
    reason := sprintf("Resource '%s' of type '%s' is missing required tags: %s. All resources must have Environment, Owner, and Project tags.", [resource.address, resource.type, missing_tags])
}

# Helper function from Scalr docs (or similar)
array_contains(arr, elem) {
  arr[_] == elem
}

Based on Scalr's OPA documentation ¹⁰⁷, policies use package terraform and the deny[reason] structure. This policy checks tfplan.resource_changes for specified resource types being created or updated. It verifies if the tags attribute in the after state contains all keys defined in required_tags. If not, it generates a denial reason listing the missing tags.

Pricing Model: Free tier (50 runs/month, all features). Paid tiers are run-based, with monthly or annual subscriptions offering bulk run purchases and volume discounts. Flex rate of $0.99/run if pre-paid runs are exceeded. No extra charges for users, workspaces, resources under management, concurrency, self-hosted agents, SAML, or support on paid plans.⁴

Target Use Cases: Organizations seeking a TFC alternative with predictable, run-based pricing, strong governance through a hierarchical model and OPA, and flexible workflow options (GitOps, CLI, self-service). Particularly suitable for enterprises managing multiple teams and environments who need granular RBAC and consistent policy enforcement.

4.2. Spacelift

Spacelift is a sophisticated CI/CD platform for IaC, supporting a wide array of tools beyond Terraform and focusing on customizable workflows, strong governance, and developer self-service.³

Key Features:

Multi-IaC Tool Support: Natively supports Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Kubernetes (manifests, Kustomize, Helm), and Ansible, allowing for mixed-tool workflows.³
Policy as Code (OPA): Extensive OPA integration for various policy types: Plan, Approval, Trigger, Push, Notification, Login, Access, Initialization, Task. Allows fine-grained control over the entire lifecycle.¹¹⁴
Drift Detection and Remediation: Automatically detects infrastructure drift and can be configured to remediate it.⁹³
Worker Pools: Offers public (Spacelift-managed) and private (self-hosted) worker pools. Users can bring their own runner images for full customization of the execution environment.¹⁰
Blueprints & Spaces: Blueprints (YAML templates) for self-service infrastructure provisioning. Spaces provide logical grouping for stacks and RBAC.¹
Stack Dependencies: Define dependencies between stacks, allowing outputs from one stack to be used as inputs in another, and triggering downstream runs.³
Lifecycle Hooks: Customize workflows by adding commands before/after any runner phase.¹⁰
OpenTofu Support: Supports OpenTofu.⁸
Credential Management: Native integrations for dynamic, short-lived credentials with AWS, Azure, and GCP.⁹³

Architecture Overview:
Spacelift's architecture revolves around Stacks, which are linked to VCS repositories and define the IaC tool, branch, and working directory. Spaces group these Stacks for organization and policy application. Workers (public or private) execute the runs (plan, apply, tasks). Policies (OPA) are attached to Stacks or Spaces to govern behavior at various points. Cloud integrations manage secure access to cloud providers.93 Lifecycle hooks allow custom commands to be injected into the worker phases.

OPA Policy Example (Spacelift Context - Plan Policy to restrict instance types):

package spacelift

# Deny if any aws_instance is created or updated with a type not in the allowed list
deny[reason] {
    # Iterate over each resource change in the plan
    resource_change := input.terraform.resource_changes[_]

    # Check if the resource is an aws_instance
    resource_change.type == "aws_instance"

    # Check if the action is create or update (and not delete)
    array_contains(["create", "update"], resource_change.change.actions[_])
    not array_contains(resource_change.change.actions, "delete")


    # Define allowed instance types
    allowed_types := {"t3.micro", "t3.small", "m5.large"}

    # Get the instance type from the 'after' state
    instance_type_after := resource_change.change.after.instance_type

    # Check if the instance type is not in the allowed list
    not allowed_types[instance_type_after]

    reason := sprintf("Instance '%s' uses disallowed type '%s'. Allowed types are: %s", [resource_change.address, instance_type_after, allowed_types])
}

array_contains(arr, elem) {
  arr[_] == elem
}

Spacelift plan policies use package spacelift and expect deny or warn rules. The input object provides access to plan data, typically under input.terraform.resource_changes.¹¹⁷ This policy iterates through resource changes, identifies aws_instance resources being created or updated, and checks if their instance_type in the after state is in a predefined allowed set. If not, it generates a denial message.

Pricing Model: Free tier (2 users, 1 concurrency, 1 API key). Paid tiers (Starter, Starter+, Business, Enterprise) scale with users, workers, and features. Starter begins at $399/month (10 users, 2 public workers). Business and Enterprise are quote-based and offer private workers, advanced features like Blueprints, and self-hosting options.⁹³

Target Use Cases: Organizations needing a highly customizable and governable CI/CD platform for multiple IaC tools, complex dependencies, and GitOps workflows. Suited for teams that require fine-grained policy control and potentially self-hosted runners.

4.3. env0

env0 offers a TACO platform focused on developer self-service, cost management, and support for multiple IaC frameworks, with a deployment-based pricing model.⁵

Key Features:

Deployment-Based Pricing: Primarily charges per successful terraform apply (or equivalent for other tools), not per resource or user, aiming for predictability.⁶
Multi-IaC Framework Support: Supports Terraform, OpenTofu, Terragrunt (including run-all capabilities), Pulumi, CloudFormation, Kubernetes, and Helm.⁵
Cost Management & Visibility: Integrates Infracost for cost estimation before deployment. Provides actual cost visibility, budget overrun alerts, and centralized cost tagging controls.⁶
Governance & RBAC: Dynamic RBAC with custom roles. Policies via OPA for approval workflows. Five-layer hierarchy (Organization, Templates, Projects, Environments, Workflows) for variable and secret granularity.⁵
Drift Management: Automated drift detection with alerts. "Cloud Compass" for IaC coverage analysis and risk assessment. "Cloud Analyst" (AI-powered) for infrastructure insights. Smart remediation options, including updating code to reflect cloud changes.⁶
Self-Service & Collaboration: Reusable templates, custom workflows, PR planning (Atlantis-style flows with PR comments), ephemeral environments with TTL, and environment scheduling.¹¹
OpenTofu Support: Supports OpenTofu.⁹¹
Terragrunt Support: Strong support for Terragrunt, including run-all operations at scale.⁹⁰

Architecture Overview:
env0's platform is structured hierarchically: Organizations contain Projects, which use Templates to define Environments. Workflows can orchestrate multiple environments. It integrates with VCS for IaC code, uses its own runners (or self-hosted agents for enterprise) for execution, and interacts with cloud providers for deployment. State can be managed by env0 or a self-managed backend.5

OPA Policy Example (env0 Context - Deny deployment if cost diff exceeds $100):

package env0 # env0 expects policies to be in the 'env0' package

# Deny deployment if the estimated monthly cost difference is greater than $100
deny[msg] {
    input.costEstimation.monthlyCostDiff > 100
    msg := sprintf("Deployment cancelled: Estimated monthly cost increase of $%.2f exceeds the $100 limit.",)
}

# Allow deployment if triggered by an admin user for a specific project, regardless of cost
allow {
    input.deployerUser.email == "admin@example.com" # Example admin user
    input.template.name == "critical-project-template" # Example project template
}

# Default to pending if no explicit deny or allow
pending[msg] {
    not deny[_]
    not allow
    msg := "Deployment requires manual approval."
}

env0 OPA policies expect package env0.¹³⁸ The input object provides context like costEstimation, deployerUser, template, and plan data.¹³⁸ This policy denies deployments if monthlyCostDiff exceeds 100, allows deployments by a specific admin for a specific template, and defaults to pending approval. env0 uses deny, pending, warn, or allow results.¹³⁸

Pricing Model: Tiered pricing (Cloud Compass, Cloud Navigator, Cloud Pilot) based on a daily platform fee plus $1 per active environment per day. Tiers unlock more advanced features like AI Cloud Analyst and advanced drift remediation. Unlimited users, concurrent runs, and deployment minutes are generally included in paid tiers. A free trial or quote is typically required for exact pricing.⁴

Target Use Cases: Teams and enterprises looking for predictable deployment-based pricing, strong multi-IaC framework support (especially Terragrunt), integrated cost management, and developer self-service with robust governance.

4.4. Atlantis (Self-Hosted TACO)

Atlantis is a popular open-source tool that provides Terraform (and OpenTofu) pull request automation, enabling a GitOps workflow.⁸⁸

Key Features:

Open Source & Self-Hosted: Free to use (software cost), with full control over the deployment environment.⁸⁸
GitOps PR Workflow: Automation is triggered by comments (e.g., atlantis plan, atlantis apply) on pull requests in supported VCS (GitHub, GitLab, Bitbucket, Azure DevOps).⁸⁸ Plan outputs are posted back to the PR.
State Locking: Leverages Terraform's native backend locking mechanisms. Atlantis itself can also provide a locking mechanism to prevent concurrent applies on the same project/workspace.¹⁴¹
Customizable Workflows: Per-repository/project server-side configuration via atlantis.yaml or terragrunt.hcl (for Terragrunt integration) allows defining custom plan and apply steps.⁸⁸
Terragrunt Support: Can be configured to work with Terragrunt.

Deployment Architecture:
Atlantis runs as a server application (typically in Docker, Kubernetes, or on a VM). It listens for webhook events from your configured VCS provider. When a relevant event occurs (e.g., PR comment), Atlantis checks out the code, executes the appropriate Terraform/Terragrunt commands in a sandboxed environment, and interacts with the configured Terraform state backend. Plan files are stored on the Atlantis server's disk by default, so persistent storage is recommended.88

Policy as Code/RBAC: Atlantis itself has limited built-in RBAC or PaC. Access control primarily relies on VCS repository permissions and branch protection rules. atlantis.yaml can define which users/teams can approve applies for specific projects. Integration with tools like OPA for policy checking requires custom scripting within the defined workflows.⁸⁸

Pricing Model: The Atlantis software is free and open-source. Costs are associated with hosting and maintaining the Atlantis server, its dependencies (like persistent storage), and the underlying CI/CD and state backend infrastructure.⁴

Target Use Cases: Teams deeply committed to a PR-driven GitOps model for Terraform, who are comfortable self-hosting and managing their automation tools, and do not require the extensive UI, RBAC, or multi-IaC features of commercial SaaS TACOs. It's a good fit for organizations wanting to keep their credentials and execution environment entirely within their own control.

4.5. Tradeoffs for TACOs

Pros:

Reduced Operational Burden: TACOs manage the underlying infrastructure for state storage (or integrate seamlessly with yours), CI/CD execution, and often provide built-in security features, reducing the DIY effort compared to a full open-source stack.⁵⁹
Enhanced Collaboration & Governance: Features like UIs, RBAC, Policy as Code integrations (OPA/Sentinel), audit logs, and centralized dashboards improve team workflows and provide better control and visibility over IaC operations.¹¹
Faster Time to Value: Generally quicker to set up a robust and feature-rich IaC pipeline compared to building everything from scratch.⁷⁷
Specialized IaC Features: TACOs often offer mature, out-of-the-box solutions for drift detection, cost estimation, secret management, and multi-IaC tool support that would require significant effort to replicate in a DIY setup.³

Cons:

Subscription Costs: TACOs typically involve subscription fees that can vary significantly based on the vendor, their pricing model (RUM, per-run, per-user, per-environment), usage levels, and the features required. These costs can become substantial for large organizations.³
Vendor Lock-in: Relying on a specific TACO's proprietary features, APIs, and workflows can make it more challenging to switch to a different platform or a pure open-source approach later on.¹²
Customization Limits: While many TACOs offer customization (e.g., Spacelift's lifecycle hooks, env0's custom flows), they may not provide the same level of deep, unfettered customization possible with a fully self-built pipeline.¹¹
Security Concerns (for SaaS TACOs): Some organizations may have reservations about entrusting their cloud credentials, Terraform state (if TACO-managed), and infrastructure code orchestration to a third-party SaaS provider, although most reputable TACOs have strong security measures and some offer self-hosted agent or even full self-hosted deployment options.⁵⁹

4.5.1. Developer Experience with TACOs

Pain Points Addressed:

Simplifies Terraform state management, locking, and versioning.
Provides a user interface for visibility into runs, state history, and resource deployments.
Automates common CI/CD tasks specific to IaC, such as plan generation on PRs and controlled applies.
Often offers integrated policy checking and RBAC, reducing the need for separate tool integrations.

Pain Points Introduced:

Debugging: Troubleshooting can shift from Terraform CLI issues to platform-specific issues. If the TACO's logging is not sufficiently detailed or its internal execution environment is opaque, debugging can be challenging.⁶⁶ Debugging policy evaluations (e.g., OPA within the TACO) requires understanding the TACO's specific input data structures and policy execution context.
Integration Challenges: Integrating tools or processes not natively supported by the TACO can be difficult, often relying on limited webhook capabilities or the TACO's specific API/plugin model.⁵⁹
Performance Bottlenecks: The TACO platform itself can introduce performance bottlenecks due to its own overhead, queuing mechanisms, worker availability, or API rate limits imposed by the service.⁵⁹
Learning Curve: Each TACO has its own interface, concepts (e.g., Spacelift Stacks vs. Scalr Workspaces vs. env0 Environments), and policy language specifics, requiring an initial learning investment from the development team.

4.6. Success Indicators for the TACO Path

Adopting a TACO is generally successful if it leads to:

Improved DORA Metrics: Tangible improvements in Deployment Frequency, Lead Time for Changes, Mean Time To Recovery (MTTR), and Change Failure Rate for infrastructure deployments.¹⁴⁵
Increased Developer Productivity and Satisfaction: Developers spend less time wrestling with IaC pipeline complexities and more time delivering infrastructure value. Feedback loops are faster and more informative.
Better Adherence to Security and Compliance Policies: Automated policy enforcement through the TACO leads to more consistent and compliant infrastructure.
Reduced Time Spent on Maintaining IaC Pipelines: The platform team offloads much of the pipeline maintenance work to the TACO vendor, freeing up internal resources.
Clear Cost Predictability (depending on the TACO's model): For TACOs with transparent, usage-based pricing (like run-based or deployment-based), infrastructure automation costs become more predictable.

This path is well-suited for organizations that want a balance of control and convenience, are willing to invest in a specialized IaC management platform, and can leverage its features to improve governance, collaboration, and operational efficiency.

5. Path 3: Complete GitHub Actions Architecture – CI/CD Native IaC

For teams deeply embedded in the GitHub ecosystem, managing Infrastructure as Code (IaC) directly within GitHub Actions presents a compelling alternative. This approach treats IaC configurations (Terraform, OpenTofu, Terragrunt) like any other software project, leveraging GitHub's native CI/CD capabilities for automation, version control, and collaboration.⁷⁴ The core idea is to consolidate IaC pipelines within the existing CI/CD framework, avoiding the introduction of a separate TACO platform.

While GitHub Actions provides immense flexibility, successfully implementing a robust, scalable, and secure IaC pipeline using it essentially means the team is building their own "mini-TACO." This requires significant CI/CD and DevOps expertise. The burden of implementing features commonly found in TACOs (like advanced state visualization, granular RBAC beyond GitHub teams, sophisticated drift detection, and IaC-specific UIs) shifts from vendor fees to internal development and maintenance costs.⁵⁹

The security posture of such a pipeline also rests heavily on disciplined configuration. Meticulous setup of OpenID Connect (OIDC) for cloud provider authentication, the principle of least privilege for IAM roles, and careful management of GITHUB_TOKEN permissions are paramount.⁶⁸ Misconfigurations in these areas can inadvertently create overly permissive access to cloud environments, turning the CI/CD system into a significant security risk. This places a higher security onus on the implementing team compared to a TACO, which often provides more built-in security abstractions and guardrails.⁶⁷

Nevertheless, for organizations that prioritize a unified CI/CD platform, possess strong internal CI/CD and security expertise, and are prepared for the development effort, GitHub Actions can be a powerful and natural extension for IaC management. However, teams seeking more out-of-the-box, IaC-specific features (like detailed state views, resource visualizers, or integrated cost estimation without extra tooling) may find it lacking without substantial custom development.⁶⁵

5.1. Key Components & Capabilities within GitHub Actions

Workflow Orchestration: YAML files (.github/workflows/) define the entire IaC pipeline, including plan, apply, testing, and environment promotion logic.⁶⁴

State Management: Standard remote backends (AWS S3, Azure Blob, GCS) are configured within the Terraform/OpenTofu code and accessed by GitHub Actions workflows during initialization. Secure access to these backends is critical.¹⁵⁷

Note: While some actions like cloudposse/github-action-terraform-plan-storage manage plan files ¹⁵⁷, Terraform state files are managed via the standard backend configuration in your .tf files.

Secret Management: GitHub Encrypted Secrets are used to store sensitive information like cloud provider credentials (if not using OIDC), API keys, or tokens needed by the workflows.⁶⁷

Secure Authentication with OIDC: This is the recommended best practice for authenticating GitHub Actions workflows to cloud providers (AWS, Azure, GCP) without using long-lived static credentials. Workflows obtain short-lived tokens from GitHub, which are then exchanged for temporary cloud credentials via a trusted IAM role/service principal.⁶⁸

Example GitHub Actions OIDC Configuration for AWS:

name: Terraform Apply to AWS with OIDC

on:
  push:
    branches:
      - main # Trigger on push to the main branch

permissions:
  id-token: write   # Required to request the OIDC JWT token
  contents: read    # Required for actions/checkout to read repository contents
  pull-requests: write # Optional: to comment plan output on PRs

jobs:
  terraform:
    name: 'Terraform Apply'
    runs-on: ubuntu-latest
    environment: production # Link to GitHub Environment for secrets and protection rules

    steps:
    - name: Checkout code
      uses: actions/checkout@v4

    - name: Configure AWS Credentials using OIDC
      uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/YourGitHubActionsProdRole # Replace with your IAM role ARN
        aws-region: YOUR_AWS_REGION # e.g., us-east-1

    - name: Setup Terraform
      uses: hashicorp/setup-terraform@v3
      with:
        terraform_version: 1.7.x # Specify your Terraform version

    - name: Terraform Init
      run: terraform init -backend-config="bucket=your-tfstate-bucket" -backend-config="key=prod/terraform.tfstate" -backend-config="region=YOUR_AWS_REGION" -backend-config="dynamodb_table=your-lock-table"

    - name: Terraform Plan
      id: plan
      run: |
        terraform plan -no-color -input=false -out=tfplan
        # Add logic here to handle plan output, e.g., comment on PR if applicable

    - name: Terraform Apply
      if: github.ref == 'refs/heads/main' && github.event_name == 'push' # Only apply on push to main
      run: terraform apply -auto-approve -input=false tfplan

This workflow demonstrates checking out code, configuring AWS credentials via OIDC by assuming an IAM role, setting up Terraform, and then running init, plan, and apply. The permissions block is crucial for OIDC. Environment-specific backend configurations are passed to terraform init. The apply step is conditional to run only on pushes to the main branch. Based on.⁶⁸

Environment Promotion: GitHub Environments allow defining distinct deployment targets (e.g., development, staging, production). These can be protected with rules like required reviewers or wait timers. Workflows can target specific environments, inheriting environment-specific secrets and variables.¹⁵⁶ Promotion can be managed by triggering workflows on merges to specific branches (e.g., develop -> staging, main -> production) or through manual workflow dispatch with environment selection.

Locking Mechanisms: Essential for preventing concurrent apply operations on the same state file, which can lead to corruption.

Backend Native Locking: Most recommended. S3+DynamoDB, Azure Blob with leases, and GCS all provide robust locking.¹⁶⁶ Ensure your backend configuration enables this.
Workflow-Level Locking: For more complex scenarios or to serialize jobs acting on the same logical stack (even if state files are different), GitHub Actions concurrency controls (concurrency: group: ${{ github.workflow }}-${{ inputs.environment }}) or custom locking actions (like abatilo/github-action-locks using DynamoDB ¹⁶⁷) can be used. However, these are secondary to backend native locking for state integrity.

Integrating Terragrunt: Terragrunt CLI commands (run-all plan, run-all apply) can be executed within GitHub Actions steps. Specialized Terragrunt GitHub Actions from the marketplace (e.g., gruntwork-io/terragrunt-action ¹⁶⁸ or the-commons-project/terragrunt-github-actions ¹⁷⁰) can simplify setup and provide outputs like plan status.

Example GitHub Actions step for Terragrunt run-all plan:

- name: Terragrunt Run All Plan
  uses: gruntwork-io/terragrunt-action@v2
  with:
    tg_version: '0.55.0' # Specify Terragrunt version
    tf_version: '1.7.5' # Specify Terraform/OpenTofu version
    tg_command: 'run-all plan --terragrunt-non-interactive -out=tfplan'
    # tg_dir: './environments'

Works cited

TFC Migration Kit: Migrate From Terraform Cloud to Spacelift, accessed May 12, 2025, https://spacelift.io/blog/how-to-migrate-from-terraform-cloud
IaC Tool Pricing Comparison: Terraform, Crossplane, and Pulumi - DEV Community, accessed May 12, 2025, https://dev.to/mechcloud_academy/iac-tool-pricing-comparison-terraform-crossplane-and-pulumi-3oe5
Terraform Cloud / Enterprise Pricing - Tiers Overview 2025 - Spacelift, accessed May 12, 2025, https://spacelift.io/blog/terraform-cloud-pricing
HCP Terraform Cloud Pricing Review - 2025 - Scalr, accessed May 12, 2025, https://www.scalr.com/blog/scalr-vs-terraform-cloud-pricing
Switch from Terraform Cloud in Minutes with Our New Migration Tool - Env0, accessed May 12, 2025, https://www.env0.com/blog/switch-from-terraform-cloud-in-minutes-with-our-new-migration-tool
A Complete Guide to Terraform Cloud Pricing - Env0, accessed May 12, 2025, https://www.env0.com/blog/terraform-cloud-pricing-a-complete-guide
Terraform Automation and Collaboration tools (TACOS) pricing calculator - Reddit, accessed May 12, 2025, https://www.reddit.com/r/Terraform/comments/1498cl8/terraform_automation_and_collaboration_tools/
Make the Switch to OpenTofu - Gruntwork, accessed May 12, 2025, https://www.gruntwork.io/blog/make-the-switch-to-opentofu?gi=d8193e523948
From Terraform to OpenTofu: Why and How | Masterpoint Consulting, accessed May 12, 2025, https://masterpoint.io/blog/opentofu-early-adopters/
Terraform Cloud / Enterprise Workspaces vs. Spacelift Stacks, accessed May 12, 2025, https://spacelift.io/blog/terraform-cloud-workspace
Terraform Cloud Alternatives: 2025 In-Depth Guide - Env0, accessed May 12, 2025, https://www.env0.com/blog/terraform-cloud-tfc-alternatives-comprehensive-buyers-guide
Top 8 Terraform Cloud Alternatives for 2025 - Spacelift, accessed May 12, 2025, https://spacelift.io/blog/terraform-cloud-alternatives
10 Biggest Pitfalls of Terraform - Terramate, accessed May 12, 2025, https://terramate.io/rethinking-iac/10-biggest-pitfalls-of-terraform/
Pain points while using terraform - Reddit, accessed May 12, 2025, https://www.reddit.com/r/Terraform/comments/1kcbby4/pain_points_while_using_terraform/
Complete Terraform Debug Guide for 2024 - Zeet.co, accessed May 12, 2025, https://zeet.co/blog/terraform-debug
How to Debug & Troubleshoot Terraform Projects: Tutorial - Spacelift, accessed May 12, 2025, https://spacelift.io/blog/terraform-debug
Solving Terraform Performance Issues in Large-scale Environments - MoldStud, accessed May 12, 2025, https://moldstud.com/articles/p-solving-terraform-performance-issues-in-large-scale-environments
Capacity and Performance - System Overview - Terraform Enterprise - HashiCorp Developer, accessed May 12, 2025, https://developer.hashicorp.com/terraform/enterprise/deploy/replicated/architecture/system-overview/capacity
state-version-outputs API reference for Terraform Enterprise - HashiCorp Developer, accessed May 12, 2025, https://developer.hashicorp.com/terraform/enterprise/api-docs/state-version-outputs
Migrate Terraform state to HCP Terraform or Terraform Enterprise - HashiCorp Developer, accessed May 12, 2025, https://developer.hashicorp.com/terraform/enterprise/migrate
Migrating off Terraform Cloud - World Without Eng, accessed May 12, 2025, https://worldwithouteng.com/articles/migrating-off-terraform-cloud
Migrating State Data Off Terraform Cloud, accessed May 12, 2025, https://nedinthecloud.com/2022/03/03/migrating-state-data-off-terraform-cloud/
How to Migrate off Terraform Cloud | Masterpoint Consulting, accessed May 12, 2025, https://masterpoint.io/blog/how-to-migrate-off-tfc/
Migrating Terraform State Between Backends: A Simple Guide - Terrateam, accessed May 12, 2025, https://terrateam.io/blog/migrating-terraform-state-between-backends/
Store Terraform state in a Cloud Storage bucket, accessed May 12, 2025, https://cloud.google.com/docs/terraform/resource-management/store-state
A guide to the Terraform state file - Env0, accessed May 12, 2025, https://www.env0.com/blog/a-guide-to-the-terraform-state-file
Terraform migrate overview - HashiCorp Developer, accessed May 12, 2025, https://developer.hashicorp.com/terraform/cloud-docs/migrate/tf-migrate
How to Manage Terraform S3 Backend - Best Practices - Spacelift, accessed May 12, 2025, https://spacelift.io/blog/terraform-s3-backend
How to Migrate From Terraform Cloud - DEV Community, accessed May 12, 2025, https://dev.to/spacelift/how-to-migrate-from-terraform-cloud-3nnp
FAQs - OpenTofu, accessed May 12, 2025, https://opentofu.org/faq/
Migrating from Terraform to OpenTofu: The How and Why | Firefly, accessed May 12, 2025, https://www.firefly.ai/academy/migrating-from-terraform-to-opentofu-the-how-and-why
Migrating Terraform State: Moving State Files Between Backends | Firefly, accessed May 12, 2025, https://www.firefly.ai/academy/migrating-terraform-state-moving-state-files-between-backends
Trying to migrate terraform state file from local to Azure storage blob - Reddit, accessed May 12, 2025, https://www.reddit.com/r/Terraform/comments/1ivq9x0/trying_to_migrate_terraform_state_file_from_local/
Backend Type: azurerm | Terraform - HashiCorp Developer, accessed May 12, 2025, https://developer.hashicorp.com/terraform/language/backend/azurerm
Terraform: migrate state from local to remote Google Cloud Storage bucket and back, accessed May 12, 2025, https://fabianlee.org/2023/03/27/terraform-migrate-state-from-local-to-remote-google-cloud-storage-bucket-and-back/
Backend Type: gcs | Terraform - HashiCorp Developer, accessed May 12, 2025, https://developer.hashicorp.com/terraform/language/backend/gcs
Terragrunt: Keep Terraform Dry With A Clean and Efficient Code - Devoteam, accessed May 12, 2025, https://www.devoteam.com/expert-view/terragrunt-keep-terraform-dry/
Comparing Terragrunt and Terraform for Infrastructure Automation - CloudThat, accessed May 12, 2025, https://www.cloudthat.com/resources/blog/comparing-terragrunt-and-terraform-for-infrastructure-automation
What Is Terragrunt And How To Use It Effectively - Zeet.co, accessed May 12, 2025, https://zeet.co/blog/what-is-terragrunt
Terragrunt Tutorial: Examples and Use Cases | env0, accessed May 12, 2025, https://www.env0.com/blog/terragrunt
Terraform Tools: Comparing Terragrunt and Terraspace - Nearform, accessed May 12, 2025, https://www.nearform.com/insights/terraform-tools-terragrunt-terraspace/
These Terraform/OpenTofu Tools Promise to Manage Your Infrastructure Tasks Effectively, accessed May 12, 2025, https://hackernoon.com/these-terraformopentofu-tools-promise-to-manage-your-infrastructure-tasks-effectively
State Backend - Terragrunt, accessed May 12, 2025, https://terragrunt.gruntwork.io/docs/features/state-backend/
terraform-terragrunt-azure-example/terragrunt.hcl at main · betarabbit/terraform-terragrunt-azure-example - GitHub, accessed May 12, 2025, https://github.com/betarabbit/terraform-terragrunt-azure-example/blob/main/terragrunt.hcl
Includes - Terragrunt - Gruntwork, accessed May 12, 2025, https://terragrunt.gruntwork.io/docs/features/includes/
Advantages and Limitations of Terragrunt-Managed Backends - BTI360, accessed May 12, 2025, https://www.bti360.com/advantages-and-limitations-of-terragrunt-managed-backends/
Configuration Blocks and Attributes - Terragrunt, accessed May 12, 2025, https://terragrunt.gruntwork.io/docs/reference/config-blocks-and-attributes/
Stacks - Terragrunt, accessed May 12, 2025, https://terragrunt.gruntwork.io/docs/features/stacks/
Using Terragrunt to Manage Multiple Environments | New Relic Documentation, accessed May 12, 2025, https://docs.newrelic.com/docs/infrastructure-as-code/terraform/terragrunt/
mrpandat/terragrunt-gcp-example - GitHub, accessed May 12, 2025, https://github.com/mrpandat/terragrunt-gcp-example
Units - Terragrunt - Gruntwork, accessed May 12, 2025, https://terragrunt.gruntwork.io/docs/features/units/
Terraform | The Cloud Posse Reference Architecture, accessed May 12, 2025, https://docs.cloudposse.com/resources/legacy/fundamentals/terraform/
Atmos FAQ, accessed May 12, 2025, https://atmos.tools/faq
Anybody use Atmos? : r/Terraform - Reddit, accessed May 12, 2025, https://www.reddit.com/r/Terraform/comments/1bbm6e7/anybody_use_atmos/
AWS IAM Policy with Modules (and Terragrunt) : r/Terraform - Reddit, accessed May 12, 2025, https://www.reddit.com/r/Terraform/comments/1feix5k/aws_iam_policy_with_modules_and_terragrunt/
cloudposse/module/example | Terraform Registry, accessed May 12, 2025, https://registry.terraform.io/modules/cloudposse/module/example/latest
Terragrunt & OpenTofu: Better together - Gruntwork, accessed May 12, 2025, https://www.gruntwork.io/blog/terragrunt-opentofu-better-together
Performance - Terragrunt - Gruntwork, accessed May 12, 2025, https://terragrunt.gruntwork.io/docs/troubleshooting/performance/
For Terraform Deployment, Any CI/CD Can Beat TACOS - The New Stack, accessed May 12, 2025, https://thenewstack.io/for-infrastructure-as-code-ci-cd-can-beat-terraform/
Top 5 Open Source Terraform Tools for 2025 - Bytebase, accessed May 12, 2025, https://www.bytebase.com/blog/top-terraform-tools/
Guide to the Total Cost of Ownership of Open-Source Software - Qt, accessed May 12, 2025, https://www.qt.io/blog/is-open-source-really-free
Terraform Best Practices For CI/CD Pipelines - Terrateam, accessed May 12, 2025, https://terrateam.io/blog/terraform-best-practices-ci-cd/
Terraform vs. Kubernetes: Choosing the Right Tool for Platform Engineering - DuploCloud, accessed May 12, 2025, https://duplocloud.com/blog/terraform-vs-kubernetes-choosing-the-right-tool-for-platform-engineering/
Automate Terraform with GitHub Actions - HashiCorp Developer, accessed May 12, 2025, https://developer.hashicorp.com/terraform/tutorials/automation/github-actions
Terrateam is open source: GitOps for Terraform and OpenTofu - Reddit, accessed May 12, 2025, https://www.reddit.com/r/GitOps/comments/1hx8dhp/terrateam_is_open_source_gitops_for_terraform_and/
Terrateam is Open Source : r/Terraform - Reddit, accessed May 12, 2025, https://www.reddit.com/r/Terraform/comments/1hclh6j/terrateam_is_open_source/
Managing secrets in Terraform: The Complete Guide - Cycode, accessed May 12, 2025, https://cycode.com/blog/secrets-in-terraform/
Integrating OIDC with Github Action to Manage Terraform Deployment on AWS | Firefly, accessed May 12, 2025, https://www.firefly.ai/academy/integrating-oidc-with-github-action-to-manage-terraform-deployment-on-aws
Terraform Automation and Collaboration tools (TACOS) pricing calculator - GitHub, accessed May 12, 2025, https://github.com/diggerhq/tacoscalculator
Infracost + Terraform + GitHub Actions = Automate Cloud Cost Management - Pace 'n Think, accessed May 12, 2025, https://www.pacenthink.io/post/infracost/
CTO's Playbook: Master Your Total Cost of Ownership in 2025 - eLuminous Technologies, accessed May 12, 2025, https://eluminoustechnologies.com/blog/total-cost-of-ownership/
Guide To Calculating TCO On AWS And Tools To Help - CloudZero, accessed May 12, 2025, https://www.cloudzero.com/blog/tco-aws/
Enable logs to debug Terraform - HashiCorp Developer, accessed May 12, 2025, https://developer.hashicorp.com/terraform/internals/debugging
Tools used by the top 1% of Platform Engineers and their Commercial Open Source Alternatives - DEV Community, accessed May 12, 2025, https://dev.to/digger/tools-used-by-the-top-1-of-platform-engineers-and-their-commercial-open-source-alternatives-6l7
What challenges did we solve with Burrito? | Theodo Cloud, accessed May 12, 2025, https://cloud.theodo.com/en/blog/what-challenges-did-we-solve-with-burrito
Top 5 Open Source Terraform Tools for 2025 - Bytebase, accessed May 12, 2025, https://www.bytebase.com/blog/top-terraform-tools
Evaluating the top Terraform CI Platforms : r/devops - Reddit, accessed May 12, 2025, https://www.reddit.com/r/devops/comments/w5fmta/evaluating_the_top_terraform_ci_platforms/
I love TACOS So Much, or at least I thought I did! - Terramate, accessed May 12, 2025, https://terramate.io/rethinking-iac/i-love-tacos-so-much-or-at-least-i-thought-i-did/
Resourcely and TACOS (Terraform Automation and Collaboration Software), accessed May 12, 2025, https://www.resourcely.io/and/tacos
Terraform Cloud Alternatives: Finding the Right IaC Platform for Your Team - Terrateam, accessed May 12, 2025, https://terrateam.io/blog/terraform-cloud-alternative/
TACOS providers : r/Terraform - Reddit, accessed May 12, 2025, https://www.reddit.com/r/Terraform/comments/sgf59w/tacos_providers/
Detect infrastructure drift and enforce policies | Terraform - HashiCorp Developer, accessed May 12, 2025, https://developer.hashicorp.com/terraform/tutorials/cloud/drift-and-policy
Top Terraform Tools to Know in 2025 - Env0, accessed May 12, 2025, https://www.env0.com/blog/top-terraform-tools-to-know-in-2024
Drift detection tools ⚒️ around : r/Terraform - Reddit, accessed May 12, 2025, https://www.reddit.com/r/Terraform/comments/1ifgk2q/drift_detection_tools_around/
Drift Detection with Github Actions - Taccoform, accessed May 12, 2025, https://www.taccoform.com/posts/tfg_p3/
How does Scalr differ from Terraform Cloud?, accessed May 12, 2025, https://www.scalr.com/blog/how-does-scalr-differ-from-terraform-cloud
env0 vs Terraform Cloud: A Comprehensive Feature Comparison, accessed May 12, 2025, https://www.env0.com/alternatives/terraform-cloud-vs-env0
What to Do When Atlantis Doesn't Meet Your Scale | ControlMonkey, accessed May 12, 2025, https://controlmonkey.io/blog/atlantis-terraform-alternative/
Terraform Cloud RUM Pricing Change: What It Means & The Best Alternatives | ElasticScale, accessed May 12, 2025, https://elasticscale.com/blog/the-best-alternatives-to-terraform-cloud/
Gruntwork's Terragrunt Integration | env0, accessed May 12, 2025, https://www.env0.com/integrations/gruntwork-terragrunt
Best Infrastructure as Code Tools | Terraform Alternatives - Env0, accessed May 12, 2025, https://www.env0.com/blog/best-infrastructure-as-code-tools-and-terraform-alternatives
Structuring Scalr - Scalr Documentation, accessed May 12, 2025, https://docs.scalr.io/docs/structuring-scalr
What is Spacelift? Key Features, Benefits & Use Cases - DEV Community, accessed May 12, 2025, https://dev.to/spacelift/what-is-spacelift-key-features-benefits-use-cases-3o4k
Enhance Cloud Asset Management and Reduce Risks - env0, accessed May 12, 2025, https://www.env0.com/solutions/cloud-asset-management
Spacelift Reviews, Ratings & Features 2025 | Gartner Peer Insights, accessed May 12, 2025, https://www.gartner.com/reviews/market/cloud-management-tooling/vendor/spacelift/product/spacelift
env0 Pricing Plans: Choose the Best for Cloud Automation, accessed May 12, 2025, https://www.env0.com/pricing
Scalr, accessed May 12, 2025, https://www.scalr.com/
Spacelift: The IaC Orchestration Platform Engineers Trust, accessed May 12, 2025, https://spacelift.io/
Automate Infrastructure as Code Confidently with env0, accessed May 12, 2025, https://www.env0.com/
Atlantis, accessed May 12, 2025, https://www.runatlantis.io/
Debugging providers | Terraform - HashiCorp Developer, accessed May 12, 2025, https://developer.hashicorp.com/terraform/plugin/debugging
Optimizing Terraform Debugging in CI/CD Pipelines - Reddit, accessed May 12, 2025, https://www.reddit.com/r/Terraform/comments/1eh9syi/optimizing_terraform_debugging_in_cicd_pipelines/
Make the Switch to OpenTofu - Gruntwork, accessed May 12, 2025, https://www.gruntwork.io/blog/make-the-switch-to-opentofu
System Description - Scalr, accessed May 12, 2025, https://www.scalr.com/system-description
Pricing FAQ - Scalr Documentation, accessed May 12, 2025, https://docs.scalr.io/docs/pricing-faq
Scalr Pricing, accessed May 12, 2025, https://www.scalr.com/pricing
Open Policy Agent - Scalr Documentation, accessed May 12, 2025, https://docs.scalr.io/docs/policy-as-code
Everything you need to know about Open Policy Agent (OPA) and Terraform - Scalr, accessed May 12, 2025, https://www.scalr.com/blog/everything-you-need-to-know-about-open-policy-agent-opa-and-terraform
Examples & Use Cases - Scalr Documentation, accessed May 12, 2025, https://docs.scalr.io/docs/examples-use-cases
Terraform Automation: Review the Atlantis Workflow - Scalr, accessed May 12, 2025, https://www.scalr.com/blog/terraform-automation-review-the-atlantis-workflow
Scalr's Blog, accessed May 12, 2025, https://www.scalr.com/blog
Scalr - Datadog Docs, accessed May 12, 2025, https://docs.datadoghq.com/integrations/scalr/
What is Spacelift? Key Features, Benefits & Use Cases, accessed May 12, 2025, https://spacelift.io/blog/what-is-spacelift
How to Use Open Policy Agent (OPA) with Terraform [Examples] - Spacelift, accessed May 12, 2025, https://spacelift.io/blog/open-policy-agent-opa-terraform
spacelift-policies-example-library/run_policy_tests.sh at main - GitHub, accessed May 12, 2025, https://github.com/spacelift-io/spacelift-policies-example-library/blob/main/run_policy_tests.sh
How it works | Spacelift, accessed May 12, 2025, https://spacelift.io/how-it-works
Policy - Spacelift Documentation, accessed May 12, 2025, https://docs.spacelift.io/concepts/policy
Terraform Drift Detection and Remediation [Guide] - Spacelift, accessed May 12, 2025, https://spacelift.io/blog/terraform-drift-detection
Spacelift | The Cloud Posse Reference Architecture, accessed May 12, 2025, https://docs.cloudposse.com/layers/spacelift/
spacelift | The Cloud Posse Reference Architecture, accessed May 12, 2025, https://docs.cloudposse.com/components/library/aws/spacelift/
Spacelift - AWS Marketplace, accessed May 12, 2025, https://aws.amazon.com/marketplace/pp/prodview-drrpy7qnpny5s
Plans and Pricing | Free plan | Spacelift, accessed May 12, 2025, https://spacelift.io/pricing
ENV0 vs Terraform Cloud: A Side-By-Side Evaluation for DevOps Teams | Zeet.co, accessed May 12, 2025, https://zeet.co/blog/env0-vs-terraform-cloud
How Policy-as-Code Enhances Infrastructure Governance with Open Policy Agent (OPA), accessed May 12, 2025, https://www.env0.com/blog/how-policy-as-code-enhances-infrastructure-governance-with-open-policy-agent-opa
AWS Integration - Env0, accessed May 12, 2025, https://www.env0.com/integrations/aws
env0 Blog: Mastering IaC and DevOps for Cloud Success, accessed May 12, 2025, https://www.env0.com/resources/blog?4e0f7321_page=3
Secure Your Infrastructure and Ensure Compliance Today - Env0, accessed May 12, 2025, https://www.env0.com/solutions/security-and-compliance
Terraform Repository Strategies and Structures - Env0, accessed May 12, 2025, https://www.env0.com/blog/tf-repository-strategies-and-structures
Ansible Playbooks: Your Guide to Infrastructure Automation - Env0, accessed May 12, 2025, https://www.env0.com/blog/ansible-playbooks-step-by-step-guide
Terraform Modules Guide: Best Practices & Examples - Env0, accessed May 12, 2025, https://www.env0.com/blog/terraform-modules
Infrastructure as Code (IaC) Resources - Env0, accessed May 12, 2025, https://www.env0.com/resources
Environment Discovery: Automatic Environment Creation from Your Git Workflow - Env0, accessed May 12, 2025, https://www.env0.com/blog/announcing-environment-discovery-automatic-environment-creation-from-your-git-workflow
accessed January 1, 1970, https://www.env0.com/blog/env0-platform-architecture
accessed January 1, 1970, https://docs.env0.com/docs/getting-started/readme
accessed January 1, 1970, https://www.env0.com/how-it-works
accessed January 1, 1970, https://www.env0.com/product
accessed January 1, 1970, https://www.env0.com/blog/env0-architecture-deep-dive
Approval Policies - env0 Documentation, accessed May 12, 2025, https://docs.env0.com/docs/approval-policies
accessed January 1, 1970, https://docs.env0.com/docs/policy-as-code
An Open Source & Self hosted Continuous Deployment tool for Terraform - Reddit, accessed May 12, 2025, https://www.reddit.com/r/selfhosted/comments/1ah7pgg/an_open_source_self_hosted_continuous_deployment/
run-digger · Actions · GitHub Marketplace, accessed May 12, 2025, https://github.com/marketplace/actions/run-digger
Deployment - Atlantis, accessed May 12, 2025, https://www.runatlantis.io/docs/deployment
Deployment | Atlantis, accessed May 12, 2025, https://www.runatlantis.io/docs/deployment.html
The Case for Terraform Modules: Scaling Your Infrastructure Organization - Infisical, accessed May 12, 2025, https://infisical.com/blog/terraform-modules-organization-scaling
16 DevOps Metrics You Should Be Tracking [DORA & Other] - Spacelift, accessed May 12, 2025, https://spacelift.io/blog/devops-metrics
Top 15 DORA Metric Tools for DevOps Success (LATEST) - CodeAnt AI, accessed May 12, 2025, https://www.codeant.ai/blogs/dora-metrics-devops-performance-guide-2
DORA Metrics: An Infrastructure as Code Perspective | env0, accessed May 12, 2025, https://www.env0.com/blog/dora-metrics-an-infrastructure-as-code-perspective
Track DORA metrics - Port overview, accessed May 12, 2025, https://docs.port.io/guides/all/setup-dora-metrics/
Terraform with GitHub Actions : How to Manage & Scale - Spacelift, accessed May 12, 2025, https://spacelift.io/blog/github-actions-terraform
Why Terraform when we have Github actions? : r/AskProgramming - Reddit, accessed May 12, 2025, https://www.reddit.com/r/AskProgramming/comments/16ppxsv/why_terraform_when_we_have_github_actions/
How to Use Terraform in GitHub Actions - Env0, accessed May 12, 2025, https://www.env0.com/blog/terraform-github-actions
Authenticate with OpenID Connect - databricks - Terraform Registry, accessed May 12, 2025, https://registry.terraform.io/providers/databricks/databricks/latest/docs/guides/azure-authenticate-with-oidc
Security hardening for GitHub Actions - GitHub Docs, accessed May 12, 2025, https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions
terraform-github-actions/.github/workflows/tf-plan-apply.yml at main · Azure-Samples/terraform-github-actions · GitHub, accessed May 12, 2025, https://github.com/azure-samples/terraform-github-actions/blob/main/.github/workflows/tf-plan-apply.yml
dflook/terraform-github-actions, accessed May 12, 2025, https://github.com/dflook/terraform-github-actions
How to Create a Secure CI/CD Pipeline Using Okta Terraform | Okta ..., accessed May 12, 2025, https://developer.okta.com/blog/2024/10/11/terraform-ci-cd
cloudposse/github-action-terraform-plan-storage: A GitHub action that enables securely storing and retrieving Terraform plan files - GitHub, accessed May 12, 2025, https://github.com/cloudposse/github-action-terraform-plan-storage
terraform-plan-storage · Actions · GitHub Marketplace, accessed May 12, 2025, https://github.com/marketplace/actions/terraform-plan-storage
Using GitHub Secrets with Terraform - DEV Community, accessed May 12, 2025, https://dev.to/terrateam-io/using-github-secrets-with-terraform-195i
Managing environments for deployment - GitHub Docs, accessed May 12, 2025, https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment
aws-samples/aws-terraform-reusable-workflow - GitHub, accessed May 12, 2025, https://github.com/aws-samples/aws-terraform-reusable-workflow
Configuring OpenID Connect in Amazon Web Services - GitHub Docs, accessed May 12, 2025, https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services
How to promote releases between GitOps environments - mattias.engineer, accessed May 12, 2025, https://mattias.engineer/blog/2023/gitops-environment-promotion/
Reusing workflows - GitHub Docs, accessed May 12, 2025, https://docs.github.com/en/actions/sharing-automations/reusing-workflows
Terraform IAC via GitHub Actions and Terraform cloud : r/devops - Reddit, accessed May 12, 2025, https://www.reddit.com/r/devops/comments/1de6cgv/terraform_iac_via_github_actions_and_terraform/
State: Locking | Terraform - HashiCorp Developer, accessed May 12, 2025, https://developer.hashicorp.com/terraform/language/state/locking
GitHub Action Locks - GitHub Marketplace, accessed May 12, 2025, https://github.com/marketplace/actions/github-action-locks
Actions · GitHub Marketplace - Gruntwork Terragrunt, accessed May 12, 2025, https://github.com/marketplace/actions/gruntwork-terragrunt
A GitHub Action for installing and running Terragrunt, accessed May 12, 2025, https://github.com/gruntwork-io/terragrunt-action
Terragrunt GitHub Actions · Actions · GitHub Marketplace · GitHub, accessed May 12, 2025, https://github.com/marketplace/actions/terragrunt-github-actions

‍