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

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 }}

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

/>