<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”.

Once the files have been generated, the block turns green and regenerates them automatically as the form changes. If generation fails, the error is shown above the form and the block is not green while that error is shown. A template error in one of the template’s files fails generation before any file is written, so the generated files stay as they were. If the first generation fails, the Generate button stays available so the user can retry.

vs. TemplateInline

Template and TemplateInline both render Boilerplate templates:

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 a template directory with a boilerplate.yml	Preview or generate a single file without a template directory

Props

Required props

• id (string). Unique identifier for this component. Other blocks use it to reference this Template’s variables.
• 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 generated files directory ($GENERATED_FILES). "worktree" writes into the active git worktree and requires a <GitClone> block to have run first. The active worktree is the one selected in the workspace, or else the most recently cloned repository.

Tip

Use target="worktree" to generate files into a cloned repository, for example to add new modules or configuration files to 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:

• Directorytemplates/

  • Directoryvpc/

    • 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

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 inputsId values

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

A Template has its own boilerplate.yml and can also import variables via inputsId, so a variable can be defined on either side or both. Variables only the Template defines are editable. Variables only the imported block defines are passed to the template without appearing in the form. Variables defined in both places are read-only in the Template form. See When variables overlap.

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

Template files can reference outputs from other blocks (e.g., Command, Check, DirPicker) using the outputs namespace:

account_id = "{{ .outputs.create_account.account_id }}"

Runbooks scans template files for output references and disables the Generate button until all upstream blocks have run.

For producing outputs, consuming them, dependency behavior, and ID naming rules, see Block outputs.

Complete example

# 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" />