Forem: StructKit

Building a Terraform Module Scaffold with structkit

Kenneth Belitzky — Tue, 28 Apr 2026 16:11:15 +0000

Building a Terraform Module Scaffold with structkit

Target: dev.to, /r/devops, /r/Terraform | SEO: terraform module template generator, infrastructure as code scaffolding

TL;DR

If you maintain multiple Terraform modules, you know the pain: every new module starts with copy-pasting the same main.tf, variables.tf, outputs.tf, and .github/ setup. structkit lets you define that structure once in YAML and generate it consistently across your team.

The Problem: Terraform Module Sprawl

As your infrastructure grows, so does your module library. Two things are always true:

New modules start with copy-paste — someone grabs an old module and strips it down
Consistency degrades over time — modules end up with different structures, naming conventions, CI configurations

This causes real pain:

Onboarding engineers spend hours understanding why Module A has a providers.tf but Module B does not
Security reviews find inconsistent IAM patterns across modules
CI pipelines fail because some modules have terratest, others do not

What structkit Does

structkit is a YAML-first scaffolding tool that generates project structures from templates. You define the shape of a project once and structkit materializes it.

pip install structkit

Scaffolding a Terraform Module

Here is a complete structkit.yaml for a standard Terraform module:

files:
  - .tf/{{@ module_name @}}/main.tf:
        content: |
          # {{@ module_name @}} -- {{@ module_description@ }}
          terraform {
            required_version = ">= 1.5"
            required_providers {
              aws = {
                source  = "hashicorp/aws"
                version = "~> 5.0"
              }
            }
          }

      - .tf/{{@ module_name @}}/variables.tf:
          content: |
            variable "name" {
              description = "Name prefix for all resources"
              type        = string
            }

      - .tf/{{@ module_name @}}/outputs.tf:
          content: |
            # Add module outputs here

      - .tf/{{@ module_name @}}/README.md:
          content: |
            # {{module_name}}
            {{module_description}}

            ## Usage
            module "{{module_name}}" {
              source = "./{{module_name}}"
              name   = "my-resource"
            }

      - .github/workflows/terraform.yml:
          content: |
            name: Terraform
            on:
              pull_request:
                branches: [main]
            jobs:
              validate:
                runs-on: ubuntu-latest
                steps:
                  - uses: actions/checkout@v4
                  - uses: hashicorp/setup-terraform@v3
                  - run: terraform init -backend=false
                  - run: terraform validate
                  - run: terraform fmt -check

Generating the Module

structkit generate \
  --config structkit.yaml \
  --var module_name=aws-s3-bucket \
  --var module_description="Opinionated S3 bucket module with versioning and encryption"

Output:

.tf/aws-s3-bucket/
├── main.tf
├── variables.tf
├── outputs.tf
├── README.md
└── .github/workflows/terraform.yml

Every module your team creates has the same CI setup, the same pre-commit hooks, the same README structure.

Team-Wide Standardization

Store templates in a central repository:

yourorg/structkit-templates/
├── terraform-module/structkit.yaml
├── terraform-root/structkit.yaml
├── python-service/structkit.yaml
└── github-action/structkit.yaml

Platform teams own the templates. Product teams consume them. Everyone gets consistency without a manual review process.

Comparing Approaches

Approach	Consistency	Learning curve
Manual copy-paste	Degrades over time	Very low
cookiecutter	Good	Medium
copier	Good (with updates)	Medium-high
structkit	Good	Low (just YAML)

structkit is YAML-first. If you can write YAML (which you already do for Terraform), you can write structkit templates.

What is Next

AI/MCP integration: structkit supports Claude MCP for natural-language scaffolding
GitHub Actions: run structkit in CI to enforce that new modules follow templates

Get Started

pip install structkit

GitHub: httpdss/structkit
PyPI: structkit

Did this help? Star httpdss/structkit and share your use case in the comments!

structkit vs cookiecutter vs copier: Which Project Scaffolding Tool Is Right for You?

Kenneth Belitzky — Sun, 26 Apr 2026 21:36:00 +0000

structkit vs cookiecutter vs copier: Which Project Scaffolding Tool Is Right for You?

If you've ever needed to scaffold a new project — a microservice, a Terraform module, a Python package — you've likely reached for cookiecutter or copier. They've served the community well for years. But in 2025, the needs of platform engineering teams have evolved: remote content sources, AI assistants, and organization-wide consistency at scale are now table stakes.

In this post we compare three tools: cookiecutter, copier, and structkit — to help you pick the right one for your workflow.

TL;DR Comparison

Feature	cookiecutter	copier	structkit
Template storage	Git repo required	Git repo required	YAML file (no repo needed)
Remote file inclusion	❌	❌	✅ GitHub, S3, GCS, HTTP
AI / MCP integration	❌	❌	✅
Update existing projects	❌	✅	✅
Pre/post hooks	✅	✅	✅
Dry run mode	❌	✅	✅
File conflict strategies	❌	✅	✅ (skip, backup, overwrite)
IDE schema validation	❌	❌	✅
Language	Python	Python	Python
GitHub stars	~10k	~7k	~14 (early)

cookiecutter

Best for: Simple, one-time project generation from a git template repo.

cookiecutter is the original. Define a cookiecutter.json and a directory of Jinja2-templated files, push it to GitHub, and anyone can run cookiecutter gh:your-org/your-template.

What it does well:

Huge ecosystem of community templates
Dead-simple mental model
Widely understood across teams

Where it falls short:

Templates must live in their own git repo
Remote content ("include this CI file from our shared templates repo") means copy-pasting into the template itself
No update path — once generated, you're on your own
No dry run, no conflict resolution

Use cookiecutter if: You need quick, one-time scaffolding and there's already a community template for your use case.

copier

Best for: Projects that need to stay in sync with their template over time.

copier is the evolution of cookiecutter. It adds a killer feature: template updates. If the upstream template changes, copier update merges the diff into your existing project. It also adds dry run mode and file conflict strategies.

What it does well:

Template update / migration path (huge win for long-lived projects)
Dry run mode
Multiple conflict strategies (skip, overwrite, patch)
Jinja2 templating compatible with cookiecutter knowledge

Where it falls short:

Templates still require a git repo
Remote content still means copy-pasting
No AI integration
YAML config but still needs the template file tree to be managed

Use copier if: You manage projects that need to track upstream template changes over time — e.g. organizational standards that evolve quarterly.

structkit

Best for: Platform and DevOps teams managing project standards at scale, especially with remote content sources and AI-native workflows.

structkit takes a fundamentally different approach: your entire project structure is defined in a single YAML file — no template repo required. File content can come from anywhere: inline, local, GitHub, S3, GCS, or any HTTP URL.

files:
  - README.md:
      content: |
        # {{@ project_name @}}
        {{@ description @}}
  - .github/workflows/ci.yml:
      file: github://your-org/templates/main/ci.yml
  - terraform/main.tf:
      file: s3://your-bucket/terraform/base-module.tf

variables:
  - project_name:
      description: "Name of your project"

When your org updates the canonical CI template, every new project generated from your structkit YAML gets the update automatically. No template repo to maintain.

What makes structkit different:

1. Remote-first content

Reference your org's canonical CI file from GitHub directly. No copy-pasting, no drift.

2. YAML-first design

The entire structure lives in one file. Commit it to your platform repo. Version it. Review it in a PR. No separate template repository overhead.

3. MCP / AI integration

structkit mcp --server

Your AI assistant (Claude, Cursor, Copilot) can generate project scaffolds from natural language, using your templates as source of truth. This is the scaffolding tool built for the AI era.

4. IDE schema validation

Get autocomplete and validation on your structkit YAML in VS Code, JetBrains, or any JSON Schema-aware editor.

Where structkit is early:

Smaller community and ecosystem (14 stars vs 10k+)
Fewer community templates available out of the box
Docs are still growing

Use structkit if: You're a platform or DevEx team enforcing org-wide standards with remote content sources, or you want to integrate AI assistants into your project creation workflow.

Picking the Right Tool

Your situation	Recommendation
Need a quick one-time scaffold from existing community templates	cookiecutter
Projects that need to stay in sync with evolving org templates	copier
Org-wide standards with remote content sources or AI integration	structkit
Want to try something new with MCP/AI-native workflows	structkit

Getting Started with structkit

pip install structkit
structkit generate my-template ./new-project

GitHub: httpdss/structkit
Docs: structkit documentation
MCP setup: structkit mcp --server

Have questions or want to share how you're using structkit? Join the GitHub Discussions.

structkit is open source (MIT). Contributions and feedback welcome.

Consistent Project Scaffolding at Scale with structkit

Kenneth Belitzky — Fri, 24 Apr 2026 15:06:18 +0000

Consistent Project Scaffolding at Scale with structkit

Every engineering team eventually hits the same wall: onboarding a new service takes half a day of copying files, hunting down the right .gitignore, figuring out which CI template is current, and hoping the intern doesn't miss the security scanning step. The solution is usually a wiki page nobody reads, a "golden repo" that's three quarters out of date, or a Slack message to the platform team that disappears into the void.

structkit exists to solve this problem definitively.

What is structkit?

structkit is an open-source project scaffolding tool that lets you define entire project structures — files, folders, content, permissions, remote assets — in a single YAML file and generate them consistently, anywhere.

Think of it as "infrastructure as code, but for your project structure."

files:
  - README.md:
      content: |
        # {{@ project_name @}}
        {{@ description @}}
  - .github/workflows/ci.yml:
      file: github://your-org/templates/main/ci.yml
  - .gitignore:
      file: github://github/gitignore/main/Python.gitignore

variables:
  - project_name:
      description: "Name of your project"
  - description:
      description: "One-line project description"

Run structkit generate my-template ./new-service and you get a complete, consistent project scaffold in seconds — with the correct CI pipeline, the right .gitignore, and your org's standard README structure.

The Problem with Alternatives

If you've tried cookiecutter or copier, you know they're powerful but have friction:

Templates live in git repos, making version management manual
Remote content (your org's standard CI file) means copy-pasting into the template
No AI integration — you're on your own for keeping templates smart

structkit takes a different approach:

Feature	cookiecutter	copier	structkit
Remote content (GitHub, S3, GCS, HTTP)	❌	❌	✅
AI / MCP integration	❌	❌	✅
Pre/post hooks	✅	✅	✅
Dry run mode	❌	✅	✅
YAML-first (no template repo needed)	❌	❌	✅
Multiple file strategies (skip, backup, overwrite)	❌	✅	✅

The AI-Native Angle: MCP Integration

The part of structkit that gets developers most excited in 2025 is the MCP (Model Context Protocol) integration. structkit ships with a built-in MCP server:

structkit mcp --server

This means your AI assistant (Claude, Cursor, Copilot, etc.) can generate project scaffolds directly from natural language:

"Create a new Terraform module with the standard organization security baseline and a README pre-filled with this module's purpose"

Your templates encode organizational knowledge. The AI executes them. The result is consistent, governed project creation at the speed of conversation.

Real-World Use Cases

Platform engineering teams use structkit to enforce org-wide standards: every new microservice gets the same observability setup, security scanning, and documentation structure — automatically.

DevEx teams use structkit to reduce onboarding time for new engineers. Instead of "read the wiki and copy the golden repo," it's structkit generate service ./my-new-service.

Individual developers use structkit to stop recreating the same boilerplate across side projects — define it once, use it forever.

Getting Started

pip install structkit
structkit generate terraform-module ./my-new-module

Full documentation: structkit docs

structkit is open source (MIT) and actively developed. Star us on GitHub and join the Discussions.