Terragrunt Config Generator

Terragrunt keeps your Terraform DRY by centralising remote state configuration and module sources in a single terragrunt.hcl file at the root of each module. Hand-writing that file is error-prone: the remote_state block must nest its settings inside a config block, the terraform block needs a valid source, and the inputs map must use correct HCL literal types. The Terragrunt Config Generator scaffolds the whole file for you. Pick a backend (s3, gcs, azurerm or local), fill the relevant bucket, key, region or path fields, set the module source, optionally add an include block and a list of inputs, and the tool serialises valid HCL with correct nesting and typing. Nothing is uploaded and no command is executed; the output is built locally and can be copied or downloaded as terragrunt.hcl. This is perfect when you are bootstrapping a new module, standardising many terragrunt.hcl files across a repo, or teaching the structure to a teammate who has never written one by hand. Because the generator reuses the same HCL serializer that the rest of the site relies on, the emitted file matches real Terragrunt expectations, so you can commit it without a round of terraform/terragrunt validate fixes. The interface also validates inputs up front, so a missing bucket or a malformed input line is reported clearly before any file is produced, which keeps the feedback loop short and avoids the frustration of debugging a half-written configuration.

• Backends - s3 (AWS), gcs (Google Cloud), azurerm (Azure) and local.
• remote_state - correctly nested backend and config blocks.
• terraform source - the module reference is serialised as a string literal.
• include block - optional path to a parent terragrunt.hcl.
• inputs map - one key=value per line, auto-typed as string, number, bool or list.
• Type coercion - true, false, integers and floats are emitted as native HCL types.
• Validation - required fields are checked before generation.
• Stats row - shows block count and line count after each build, so you can sanity-check the output size.
• Export - copy to clipboard or download as terragrunt.hcl.
• Offline - runs entirely in the browser, no network calls.
• Consistent formatting - output follows HCL indentation conventions.
• Repeatable - the same inputs always produce the same file.
• Backend-aware fields - the form adapts labels per selected backend.
• Safe inputs parsing - malformed input lines are reported with a clear message.

1. Pick a backend - choose s3, gcs, azurerm or local.
2. Fill backend fields - bucket, key, region or local path as relevant to that backend.
3. Set the module source - a local path, Git URL or registry module reference.
4. Add an include path - optional, only if you inherit a parent config.
5. Add inputs - one key=value per line for the module variables.
6. Generate - click Generate terragrunt.hcl to build the file.
7. Review the stats - confirm the block and line counts look right and no error appeared.
8. Export - copy or download the terragrunt.hcl for your module.

Worked example - backend s3 with bucket my-tf-state, key env/terraform.tfstate and region us-east-1, source git::https://github.com/org/module.git//app?ref=v1.0.0, include ../terragrunt.hcl and inputs region = us-east-1, instance_count = 3, enabled = true produces a remote_state block whose config map contains the bucket, key and region, a terraform { source = "..." } block, an include { path = "../terragrunt.hcl" } block, and an inputs map where instance_count is serialised as the number 3 and enabled as the boolean true. The downloaded file is ready to commit and run with terragrunt apply. If you instead pick azurerm, the same module source and inputs produce a remote_state config that maps to resource_group_name, storage_account_name and container_name, showing how the generator adapts field meaning per backend without changing the rest of the file.

• Valid HCL - the file is serialised correctly every time.
• Portable - drop the output straight into a module.
• Private - everything runs in the browser.
• Fewer typos - nesting and typing are handled for you.
• Standardised - consistent structure across many modules.
• Fast onboarding - new modules get a correct file in seconds.
• Lower review cost - reviewers see a familiar, correct shape every time.
• Backend flexibility - switch providers without relearning the file shape.