Terragrunt

Terragrunt is an open-source wrapper around Terraform and OpenTofu that organizations use to help keep code DRY. If used in Scalr, Scalr will use all of the Terragrunt commands on top of Terraform or OpenTofu, depending on the pipeline settings.

Configuration

To add Terragrunt, go to the account scope in Scalr, the integrations page, and select Terragrunt. Once selected, it can be enabled for the entire account for use:

There are optional checks that can be enabled for all workspaces that are using Terragrunt:

• terragrunt hclvalidate - Finds all hcl files from the config stack and validates them.
• terragrunt hclfmt - Recursively find hcl files and rewrite them into a canonical format with the check mode enabled.
• terragrunt validate-inputs - Checks if the Terragrunt configured inputs align with the Terraform defined variables.

It will be available to all workspaces once the changes are saved.

Using Terragrunt

End users can enable Terragrunt at the workspace when creating a workspace or by updating the pipeline afterward. When creating a workspace, users are prompted to select the IaC platform (Terraform or OpenTofu and whether or not it should run with Terragrunt:

If Terragrunt is being added after a workspace has already been created, it can be added in the pipeline settings:

Users will see in the run that Terragrunt is being used to execute the commands:

Run-All

The run-all feature in Terragrunt is a powerful command that allows users to orchestrate Terraform or OpenTofu commands across multiple modules in a single execution. It simplifies managing complex infrastructure with multiple dependencies by handling the execution order and dependencies automatically.

When using run-all with Scalr:

• A non-Scalr remote backend must be added to each unit to manage the state. See more here.
• Terragrunt will automatically execute the run-all commands across all relevant modules defined in the workspace.
• Users can observe the execution logs in the Scalr interface, showing the commands being run for each module.
• Dependency resolution ensures a smooth workflow even in complex stacks.

The Terragrunt run-all option in Scalr is available in environments where the Scalr backend is disabled. To use run-all, ensure backend configurations are managed in your terragrunt.hcl files and Scalr's backend is disabled for the environment.

While creating or editing workspace in the Pipeline Setting section:

• Enable Use Terragrunt toggle
• Select Terragrunt version (0.69.1 or higher)
• Set Execute run-all commands on multiple units at once check-box to true

To use run-all, the workspace must use Terragrunt version 0.69.1 or greater. At this point, run-all workspaces do not support the following (they will be supported in the future):

• Structured plan output
• Cost estimation
• Policy checks
• Downloading of plan JSON
• Outputs

Detection of Deleted Units in Terragrunt run-all Workspaces

When managing infrastructure with Terragrunt using the run-all command, it's common to operate across multiple units (terraform modules). As configurations evolve, some of these modules may be removed from the codebase. By default, Terragrunt does not detect or respond to the removal of modules, which can lead to orphaned resources — resources that still exist in the remote state but are no longer declared in the configuration.

To prevent such issues and maintain a clean and accurate infrastructure state, Scalr provides automatic detection of deleted units in run-all workspaces.

How It Works

Scalr tracks the list of Terragrunt units within a run-all workspace based on the folder structure of the workspace working directory. When a run-all plan or apply is executed:

1. Scalr resolves the list of active units by reading the output groups of modules.
2. It compares the resolved list with the units from the previous run stored in its metadata.
3. If any previously known units are no longer present in the latest configuration:
   1. These are flagged as deleted units.

Scalr will surface these deletions and can optionally queue destroy operations for the removed units. Detection of deleted units is enabled by default in run-all workspaces.

Lifecycle of a Deleted Unit

1. Detection: A run-all plan detects that a previously existing module no longer exists.
2. Notification: The deleted unit is surfaced in the plan summary in UI and PR reports.
3. Action: UI assistant offers to manually queue a targeted destroy run of the deleted unit.

Example Outputs

In the workspace dashboard UI, Scalr shows the assistant that previously applied units were deleted from the source code:

Also, users can see a similar warning in runs where Scalr detected the issue:

The same warning users can see in the Plan-only and Plan & Apply PR report summaries:

Best Practices

• Regularly audit the run-all plan output for deleted units.
• Avoid manual backend tampering without updating the configuration.
• Use version control to track intentional module removals.

Limitations

• Detection is based on folder paths; renaming or relocating folders may appear as a deletion and addition.
• Terragrunt must be executed consistently through Scalr or with metadata tracking enabled for accurate results.

FAQ

Q: What happens if I remove a module but don't destroy it?
A: The resources in that module will continue to exist in your cloud provider but are no longer managed by Terraform/Terragrunt. This can cause drift and unintended costs.

Q: Can I disable deleted unit detection?
A: Right now, there's no way to disable deleted unit detection, and if you want to make it configurable, please open a support request at https://support.scalr.com.

Q: Does this work with run-all apply and run-all plan?
A: Yes. Detection is performed on both plan and apply operations.

CLI-Driven Workflow

Terragrunt can be used in a VCS or CLI-driven workspace. If used in a CLI-driven workspace, one extra step is needed to add the Scalr remote backend for remote execution. To establish a connection with the remote workspace, you have to add the following code to the terragrunt.hcl file:

generate "backend" {
  path      = "backend.tf"
  if_exists = "overwrite"
  contents  = <<EOF
terraform {
  backend "remote" {
    hostname     = "<account>.scalr.io"
    organization = "<scalr-environment-name-or-ID>"

    workspaces {
      name = "<workspace-name>"
    }
  }
}
EOF
}

The code above automatically generates a remote backend configuration, which will be used to upload the source code and execute it remotely.

CLI Runs in "run-all" Workspaces

There are a few limitations you have to consider in the "run-all" workspaces:

1. The root of the run-all workspace should have the terragrunt.hcl file with the remote backend block added, as seen above.
2. Units inside the run-all workspace must be configured to use any state backend (S3, Azure, GCP, etc), theremote backend type is not recommended. If a remote backend is added to each unit, OpenTofu/Terraform will create separate remote workspaces, and each unit run will be tracked as individual runs.
3. To trigger a CLI-driven run, you have to call simple commands (terragrunt plan or terragrunt-apply) instead of the terragrunt run-all <command> equivalent. The terragrunt run-all <command> will cause a local execution of the dependent units.