---
title: Manifest
sidebar:
  order: 5
description: Track generated files with a manifest that includes SHA256 checksums.
---

import { Code } from '@astrojs/starlight/components';
import manifestSchema from '../../../../public/schemas/manifest/v1/schema.json?raw';

## Overview

Boilerplate can produce a **manifest file** that records every file it generated during a run, along with SHA256 checksums for each file. This is useful for:

- **Auditing**: knowing exactly which files were created by a template
- **Drift detection**: comparing checksums to see if generated files were modified after the fact
- **CI/CD pipelines**: programmatically consuming the list of generated files in downstream steps

## Enabling the Manifest

Use the `--manifest` flag to write a manifest to the output directory:

```bash
boilerplate \
  --template-url ./templates/service \
  --output-folder ./output \
  --non-interactive \
  --manifest
```

This creates `boilerplate-manifest.yaml` inside the output folder.

To write the manifest to a custom path, use `--manifest-file`:

```bash
boilerplate \
  --template-url ./templates/service \
  --output-folder ./output \
  --non-interactive \
  --manifest-file ./reports/manifest.yaml
```

`--manifest-file` implies `--manifest`, so you don't need to pass both.

## Format Auto-Detection

The manifest format is determined by the file extension:

| Extension | Format |
|-----------|--------|
| `.json` | JSON |
| `.yaml`, `.yml` (or anything else) | YAML |

## Schema

The manifest contains the following fields:

| Field | Description |
|-------|-------------|
| `SchemaVersion` | URL pointing to the [Manifest Schema](#manifest-schema) for the manifest format |
| `Timestamp` | UTC timestamp of the generation run (RFC 3339) |
| `TemplateURL` | The `--template-url` value used for this run |
| `BoilerplateVersion` | Version of boilerplate that produced the output |
| `SourceChecksum` | Checksum of the template source. For git sources: `git-sha1:<commit>` or `git-sha256:<commit>`. For local sources: `sha256:<hex>` |
| `OutputDir` | The `--output-folder` value used for this run |
| `Variables` | User-defined template variables used during generation (builtin variables are excluded) |
| `Dependencies` | Array of dependencies that were processed (or skipped) during the run |
| `Dependencies[].Name` | Name of the dependency |
| `Dependencies[].TemplateURL` | Resolved template URL for the dependency |
| `Dependencies[].OutputFolder` | Resolved output folder for the dependency |
| `Dependencies[].SourceChecksum` | Checksum of the dependency's template source |
| `Dependencies[].Skip` | Rendered skip expression (present even for skipped dependencies) |
| `Dependencies[].ForEach` | List of `for_each` values used for this entry |
| `Dependencies[].ForEachReference` | The `for_each_reference` variable name, if set |
| `Dependencies[].VarFiles` | Variable files specified on the dependency |
| `Dependencies[].Variables` | Resolved variable values passed to the dependency |
| `Dependencies[].Files` | Array of files generated by this dependency (with checksums) |
| `Dependencies[].Files[].Path` | Path of the generated file, relative to the dependency's output directory |
| `Dependencies[].Files[].Checksum` | Checksum of the file contents, prefixed with the hash algorithm (e.g. `sha256:a1b2c3…`) |
| `Dependencies[].DontInheritVariables` | Whether the dependency opted out of inheriting parent variables |
| `Files` | Array of generated files |
| `Files[].Path` | Path of the generated file, relative to the output directory |
| `Files[].Checksum` | Checksum of the file contents, prefixed with the hash algorithm (e.g. `sha256:a1b2c3…`) |

### YAML example

```yaml
SchemaVersion: "https://boilerplate.gruntwork.io/schemas/manifest/v1/schema.json"
Timestamp: "2026-02-24T12:00:00Z"
TemplateURL: ./templates/service
BoilerplateVersion: v0.6.0
SourceChecksum: "sha256:a1b2c3d4e5f6..."
OutputDir: ./output
Variables:
  ServiceName: my-service
  Port: 8080
Dependencies:
  - Name: vpc
    TemplateURL: ./modules/vpc
    OutputFolder: ./output/vpc
    Variables:
      cidr: "10.0.0.0/16"
    Files:
      - Path: main.tf
        Checksum: "sha256:b2c3d4e5f6a1..."
  - Name: logging
    TemplateURL: ./modules/logging
    OutputFolder: ./output/logging
    Skip: "true"
Files:
  - Path: main.go
    Checksum: "sha256:a1b2c3d4e5f6..."
  - Path: README.md
    Checksum: "sha256:f6e5d4c3b2a1..."
```

### JSON example

```json
{
  "SchemaVersion": "https://boilerplate.gruntwork.io/schemas/manifest/v1/schema.json",
  "Timestamp": "2026-02-24T12:00:00Z",
  "TemplateURL": "./templates/service",
  "BoilerplateVersion": "v0.6.0",
  "SourceChecksum": "sha256:a1b2c3d4e5f6...",
  "OutputDir": "./output",
  "Variables": {
    "ServiceName": "my-service",
    "Port": 8080
  },
  "Dependencies": [
    {
      "Name": "vpc",
      "TemplateURL": "./modules/vpc",
      "OutputFolder": "./output/vpc",
      "Variables": {
        "cidr": "10.0.0.0/16"
      },
      "Files": [
        {
          "Path": "main.tf",
          "Checksum": "sha256:b2c3d4e5f6a1..."
        }
      ]
    },
    {
      "Name": "logging",
      "TemplateURL": "./modules/logging",
      "OutputFolder": "./output/logging",
      "Skip": "true"
    }
  ],
  "Files": [
    {
      "Path": "main.go",
      "Checksum": "sha256:a1b2c3d4e5f6..."
    },
    {
      "Path": "README.md",
      "Checksum": "sha256:f6e5d4c3b2a1..."
    }
  ]
}
```

## Manifest Schema

Boilerplate publishes a formal [JSON Schema](https://json-schema.org/) for the manifest format. The `SchemaVersion` field in every generated manifest contains the schema URL, making it easy to identify which schema version was used and to fetch the schema for validation.

<Code title="manifest/v1/schema.json" lang="json" code={manifestSchema} />

Each run overwrites the previous manifest, so it always reflects the most recent generation. If you need to preserve history across runs, track the manifest in version control (e.g. Git).

## Versioning

The manifest schema is versioned via the URL path (e.g. `.../v1/schema.json`). Every generated manifest records the schema version it conforms to in the `SchemaVersion` field, so consumers can detect which version they are working with.

A new schema version is published whenever the schema changes. Breaking changes (removing fields, changing types, etc.) are avoided when possible, but when necessary they will accompany a breaking release of Boilerplate itself: minor releases before 1.0, and major releases afterwards.
