Render

import { Aside } from '@astrojs/starlight/components'; import Before from '@components/Before.astro'; import Since from '@components/Since.astro';

Render the Terragrunt configuration in the current working directory, with as much work done as possible beforehand (that is, with all includes merged, dependencies resolved/interpolated, function calls executed, etc).

The only supported format at the moment is JSON, but support for HCL will be added in a future version.

Example:

The following terragrunt.hcl:

locals {
  aws_region = "us-east-1"
}

inputs = {
  aws_region = local.aws_region
}

Renders to the following HCL by default:

$ terragrunt render
locals {
  aws_region = "us-east-1"
}
inputs = {
  aws_region = "us-east-1"
}

Note the resolution of the aws_region local, making it easier to read the final evaluated configuration at a glance.

Renders to the following JSON when the --format json flag is used:

$ terragrunt render --format json
{
  "locals": { "aws_region": "us-east-1" },
  "inputs": { "aws_region": "us-east-1" }
  // NOTE: other attributes are omitted for brevity
}

You can also use the --write flag to write the rendered configuration to a canonically named file in the same working directory as the terragrunt.hcl file.

Example:

# Note the use of the `--json` shortcut flag.
terragrunt render --json --write

This will write the rendered configuration to terragrunt.rendered.json in the current working directory.

This can be useful when rendering many configurations in a given directory, and you want to keep the rendered configurations in the same directory as the original configurations, without leveraging external tools or scripts.

This is also useful when combined with the --all flag, which will render all configurations discovered from the current working directory.

# Note the use of the `-w` alias for the `--write` flag.
terragrunt render --all --json -w

This will render all configurations discovered from the current working directory and write the rendered configurations to terragrunt.rendered.json files adjacent to the configurations they are derived from.

Expanded dependencies

A dependency block that carries an expansion block renders as it was written, references and all, followed by the elements it expanded into. Each element is commented out, with its body resolved against the iteration it came from:

$ terragrunt render --experiment block-iteration
dependency "aurora" {
  expansion {
    for_each = toset(["web", "api"])
  }

  config_path = "../aurora-${each.key}"
}

# Expands to:
#
# dependency "aurora" {
#   config_path = "../aurora-api"
# }
#
# dependency "aurora" {
#   config_path = "../aurora-web"
# }

count reads the same way:

$ terragrunt render --experiment block-iteration
dependency "shard" {
  expansion {
    count = 2
  }

  config_path = "../shard-${count.index}"
}

# Expands to:
#
# dependency "shard" {
#   config_path = "../shard-0"
# }
#
# dependency "shard" {
#   config_path = "../shard-1"
# }

The expanded blocks are in comments because they are not a valid Terragrunt configuration: they all carry one label, and only the last block with a given label can be referenced. Terragrunt warns about that, and rejects it outright under the duplicate-dependency-labels strict control. They are present as comments to help you predict how Terragrunt will expand the block with an expansion block.

A dependency block with no expansion block renders as it always has.