<Template>

The <Template> block generates files from a Gruntwork Boilerplate template directory. It renders a form for any variables defined in the template, and saves generated files to the workspace.

Basic Usage

<Template id="vpc-setup" path="templates/vpc" />

This loads the boilerplate.yml file from templates/vpc/boilerplate.yml (relative to your runbook file), renders a form for the variables, and generates files when the user clicks “Generate”.

vs. TemplateInline

Template and TemplateInline both render Boilerplate templates, but they serve different purposes:

Feature	<Template>	<TemplateInline>
Template source	Directory with boilerplate.yml	Inline in runbook
Form rendered	Yes, from boilerplate.yml	No form (uses Inputs)
File generation	Always saves to workspace	Optional (generateFile={true})
Use case	Generate files from template directories	Show preview of single files inline

Use <Template> when you have a full Boilerplate template directory with multiple files and a boilerplate.yml configuration. Use <TemplateInline> when you want to show a quick inline preview or generate a single file without a separate template directory.

Props

Required Props

• id (string) - Unique identifier for this component. Used to reference this Template’s variables from other blocks.
• path (string) - Path to the boilerplate template directory, relative to the runbook file. The directory must contain a boilerplate.yml file.

Optional Props

• inputsId (string | string[]) - ID of Inputs or Template block(s) to import variable values from. When multiple IDs are provided as an array, variables are merged in order (later IDs override earlier ones).
• target ("generated" | "worktree") - Where template output is written. Defaults to "generated", which writes to the standard generated files directory ($GENERATED_FILES). Set to "worktree" to write directly into the active git worktree (the most recently cloned repo via <GitClone>). Requires a <GitClone> block to have run first.

Tip

Use target="worktree" when you want to generate files directly into a cloned repository. For example, to scaffold new modules or configuration files in an existing repo.

Directory Structure

The path prop should point to a directory containing a boilerplate.yml file and any template files:

<Template id="my-template" path="templates/vpc" />

Expected directory structure:

templates/vpc/
├── boilerplate.yml    # Variable definitions (required)
├── arbitrary_template_files.txt            # Template file

The boilerplate.yml file defines the variables that will be collected from the user. Template files use Boilerplate’s Go template syntax for variable substitution.

With Variables

There are several ways to provide variables to a Template.

Standalone Template

The Template displays a form with all variables defined in its boilerplate.yml:

<Template id="vpc-setup" path="templates/vpc" />

Using inputsId

Import variables from a separate Inputs block:

<Inputs id="config">
```yaml
variables:
  - name: Environment
    type: enum
    options: [dev, staging, prod]
    default: dev
  - name: Region
    type: string
    default: us-east-1
```
</Inputs>

<Template id="vpc" path="templates/vpc" inputsId="config" />

Variables from config are merged with the template’s own variables. Shared variables become read-only in the Template form.

Using Multiple inputsIds

You can reference multiple Inputs blocks by passing an array of IDs. Variables are merged in order, with later IDs overriding earlier ones:

<Inputs id="org-config">
```yaml
variables:
  - name: OrgName
    type: string
```
</Inputs>

<Inputs id="env-config">
```yaml
variables:
  - name: Environment
    type: enum
    options: [dev, prod]
```
</Inputs>

<Template
  id="infrastructure"
  path="templates/infra"
  inputsId={["org-config", "env-config"]}
/>

Variable Categories

When a Template references external inputs via inputsId, variables fall into three categories:

Category	Description	Form Behavior
Local-only	Exists only in the template’s boilerplate.yml	Editable
Imported-only	Exists only in imported sources	Not shown, but passed to template
Shared	Exists in both template and imported sources	Read-only, live-synced

Note

Shared variables are displayed in the form but are read-only and stay synchronized with the values from the imported sources.

Template File Syntax

Template files use Boilerplate’s Go template syntax:

main.tf

resource "aws_vpc" "main" {
  cidr_block = "{{ .CidrBlock }}"

  tags = {
    Name        = "{{ .VpcName }}"
    Environment = "{{ .Environment }}"
  }
}

{{- if .EnableFlowLogs }}
resource "aws_flow_log" "main" {
  vpc_id = aws_vpc.main.id
  # ...
}
{{- end }}

Using Block Outputs

Templates can reference outputs from Command or Check blocks that have already run. This allows you to generate files based on dynamic values produced by previous steps.

Output Syntax

Access block outputs using the _blocks namespace:

# In your template file
account_id = "{{ ._blocks.create_account.outputs.account_id }}"
region     = "{{ ._blocks.create_account.outputs.region }}"

Note

ID Naming: You can use hyphens or underscores in your block IDs (e.g., id="create-account" or id="create_account"). In template syntax, always use underscores: ._blocks.create_account. This is because Go templates interpret hyphens as the subtraction operator.

Note: IDs that would normalize to the same value (e.g., create-account and create_account) cannot coexist in the same runbook.

Output Dependencies

When a Template loads, Runbooks automatically scans the template files for {{ ._blocks.*.outputs.* }} patterns. If those outputs don’t exist yet:

1. A warning is displayed showing which blocks need to run first
2. The “Generate” button is disabled until the required blocks have executed

Example: Using Command Outputs in a Template

## Step 1: Create Account

<Command
  id="create-account"
  path="scripts/create-account.sh"
  title="Create AWS Account"
/>

## Step 2: Generate Configuration

This template uses the account ID from Step 1:

<Template
  id="account-config"
  path="templates/account-config"
/>

And in templates/account-config/main.tf:

# Values populated from the create-account Command's outputs
locals {
  account_id = "{{ ._blocks.create_account.outputs.account_id }}"
  region     = "{{ ._blocks.create_account.outputs.region }}"
}

resource "aws_iam_account_alias" "alias" {
  account_alias = "my-org-${local.account_id}"
}

Combining Inputs and Outputs

You can use both standard inputs (from <Inputs> blocks) and block outputs in the same template:

# Standard inputs from Inputs block
environment = "{{ .Environment }}"
owner       = "{{ .Owner }}"

# Block outputs from Command/Check blocks
account_id  = "{{ ._blocks.create_account.outputs.account_id }}"

See It in Action

Check out the block-outputs feature demo for a complete working demonstration of Template blocks that consume outputs from upstream Command blocks.

Common Use Cases

The <Template> block works especially well for generating files from structured templates:

• Generate infrastructure code: Create Terraform, Terragrunt, or other IaC files based on user inputs.
• Scaffold projects: Generate project structures with configuration files customized to user preferences.
• Create configuration files: Generate CI/CD pipelines, Docker Compose files, Kubernetes manifests, or other config files.
• Multi-file generation: Generate multiple related files that need consistent variable values.

Complete Example

Here’s a complete runbook showing Template with imported variables and validation:

# Deploy a VPC

First, configure your environment:

<Inputs id="env-config">
```yaml
variables:
  - name: Environment
    type: enum
    options: [dev, staging, prod]
    default: dev
  - name: Region
    type: string
    default: us-east-1
```
</Inputs>

Now configure your VPC. The Environment and Region will be inherited from above:

<Template id="vpc-setup" path="templates/vpc" inputsId="env-config" />

/>