BrunelDocs

Guides

Terraform from a GitHub repository

Generate validated Terraform for your application from its GitHub repository. How Brunel goes from code to modules split by domain, what is and is not generated, and how to apply it safely.

From code to Terraform

  1. Analyze: detectors read the repository and list what it runs, with evidence.
  2. Design: four tiers of provider-agnostic components with sizes, replicas, availability and placement.
  3. Map and price: each component becomes a real service, SKU and Terraform resource type from the provider's catalog.
  4. Validate: security, resilience, observability, CI/CD, budget and compliance rules.
  5. Generate: deterministic templates write the Terraform, never the AI.

What you get

terraform/
  versions.tf  providers.tf  backend.tf  variables.tf  outputs.tf
  network.tf  compute.tf  data.tf  security.tf  observability.tf  cicd.tf
  README.md

Each resource is commented with the component it implements and why. Passwords are never written in the code: AWS RDS manages its own, other databases get a random password stored in the secrets manager.

Validated before you see it

Brunel's CI renders every combination of its test repositories, tiers and providers and runs terraform validate on each (plus kubeconform, actionlint and docker compose config for the other files). A template change that breaks any of them does not ship.

Apply it safely

  1. Configure the remote state in backend.tf (a stub is provided).
  2. Review the variables (variables.tf) and run terraform plan.
  3. Apply from CI rather than a laptop: Brunel can open a pull request with a plan-on-PR, apply-after-merge workflow. See Deployment.

What is not generated

Third-party services without a provider resource (for example an external uptime service when the provider has none) are listed in terraform/README.md for you to set up, never faked.

Terraform from a GitHub repository · Brunel Docs