Promote Terragrunt Environments One at a Time with Scoped run-all apply

Promote infrastructure the way you promote code, environment by environment, with an audit trail. Terragrunt mono-repos typically keep one folder per environment under live, and the promotion discipline is simple: apply dev, verify, apply staging, verify, apply prod. This blueprint encodes that discipline as a Kestra flow. A SELECT input picks the environment, and terragrunt run-all apply is scoped to exactly that folder with --working-dir, so a prod promotion can never accidentally sweep up staging changes.

The demo repository ships inline through inputFiles: one shared root.hcl, one app unit per environment, and a single module that writes an environment-stamped local_file, so the flow runs end to end without cloud credentials.

How it works

1. The environment input (SELECT, defaulting to dev) constrains executions to dev, staging, or prod, so the promotion target is always explicit and recorded on the execution.
2. apply_environment (io.kestra.plugin.terragrunt.cli.TerragruntCLI) materializes the repo layout from inputFiles, then runs terragrunt run-all apply --non-interactive --working-dir live/{{ inputs.environment }}. The --working-dir scope means Terragrunt only discovers units inside the chosen environment folder.
3. Each environment's unit passes its own environment input to the shared module, so the same module code produces per-environment resources, the standard Terragrunt promotion pattern.
4. confirm_promotion posts a Slack message naming the environment and the execution id, and the errors block posts a distinct failure alert that also names the environment.

What you get

• Promotions that are explicit executions with a named target, an operator, a timestamp, and full logs.
• Hard scoping through --working-dir, applying dev can never modify prod.
• One flow serving all environments instead of three near-identical pipelines.
• A Slack record of every promotion and every failed promotion.

Who it's for

• Platform teams moving Terragrunt applies off laptops and into a controlled, logged system.
• Organizations that need to show who promoted what to prod and when.
• Teams standardizing a dev to staging to prod path for infrastructure changes.

Why orchestrate this with Kestra

A promotion run from a terminal leaves no record beyond shell history, and nothing stops a mistyped path from applying the wrong environment. Kestra gives the same command guardrails: the target is a constrained SELECT input, every execution stores its inputs and logs, Slack confirms success or failure by name, and Kestra's RBAC and execution history turn infrastructure promotion into a reviewable process instead of a trust exercise.

Prerequisites

• A Slack incoming webhook for confirmations and failure alerts.
• No cloud credentials are needed for the demo, the module only writes local files. For real infrastructure, pass provider credentials through the task env from {{ secret('...') }} and configure remote state in root.hcl.

Secrets

• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add the SLACK_WEBHOOK_URL secret to your Kestra namespace.
2. Execute the flow with the default dev environment and check the Slack confirmation names dev.
3. Re-run with staging, then prod, to walk a full promotion path.

How to extend

• Replace the inline inputFiles with namespaceFiles or a io.kestra.plugin.git.Clone task so promotions run against your real repository.
• Add an approval step with a Pause task before the prod branch, so promotions to production require a human sign-off.
• Chain a run-all plan task before the apply and attach the plan log for reviewers, as shown in the Terragrunt run-all plan blueprint.
• Switch to OpenTofu by using an image that ships tofu and setting TERRAGRUNT_TFPATH in the task env.

Links

• Terragrunt plugin documentation
• Terragrunt documentation