<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
Section titled “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
Section titled “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.
Required Props
Section titled “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 aboilerplate.ymlfile.
Optional Props
Section titled “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.
Directory Structure
Section titled “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 fileThe 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
Section titled “With Variables”There are several ways to provide variables to a Template.
Standalone Template
Section titled “Standalone Template”The Template displays a form with all variables defined in its boilerplate.yml:
<Template id="vpc-setup" path="templates/vpc" />Using inputsId
Section titled “Using inputsId”Import variables from a separate Inputs block:
<Inputs id="config">```yamlvariables: - 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
Section titled “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">```yamlvariables: - name: OrgName type: string```</Inputs>
<Inputs id="env-config">```yamlvariables: - name: Environment type: enum options: [dev, prod]```</Inputs>
<Template id="infrastructure" path="templates/infra" inputsId={["org-config", "env-config"]}/>Variable Categories
Section titled “Variable Categories”Because a Template has its own boilerplate.yml and can import variables via inputsId, Runbooks needs to decide what happens when both sides define a variable. The result depends on where each variable is defined — Template-only variables are editable, provider-only variables pass through invisibly, and variables defined in both places become read-only. See Inputs & Outputs — Variable Categories for the full explanation.
Template File Syntax
Section titled “Template File Syntax”Template files use Boilerplate’s Go template syntax:
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
Section titled “Using Block Outputs”Template files can reference outputs from other blocks (e.g., Command, Check, TfModule, 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 the full guide on producing outputs, consuming them, dependency behavior, and ID naming rules, see Inputs & Outputs — Block Outputs.
Common Use Cases
Section titled “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
Section titled “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">```yamlvariables: - 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" />