Docs

Write a good prompt

• Describe the app in a sentence or two — what it does, plus the runtime, framework, and database if you know them.
• State your scale (traffic or data volume), budget priority, and any compliance (HIPAA / PCI / GDPR). These genuinely change the architecture.
• Set an availability target (e.g. 99.9%) so it recommends the right redundancy — multi-AZ, replicas, failover.
• Pick your cloud, or let it recommend one from your stack; choose Terraform, or CloudFormation on AWS.
• Name any existing infrastructure to reuse (a VPC, an account) so the plan wires into what you already run.
• More specific input gives a more right-sized, better-cited plan — the specificity meter in the tool nudges you toward the fields that matter.

Scope & safety

infra god creates cloud-deployment plans for software applications — that's all it does. Before any plan is generated, your description passes a safety gate: an Amazon Bedrock guardrail that blocks harmful input, plus a lightweight check that it's a genuine deployment request. So it isn't a general-purpose chatbot — off-topic requests get a short, clear message instead of a plan. More on /security.

What each part of the output means

Architecture

The design in plain language — an overview, a component table, and the data flow — with inline [Source N] citations on factual claims.

Sources

The numbered [Source N] references, each linking to an official documentation URL on the cloud provider's own site.

Validation & scan

A visible ✓ / ✗ checklist (architecture QA + a Well-Architected-style security review), plus real `terraform validate` / cfn-lint on the code and a checkov + tflint security & best-practice scan run offline — the specific findings (rule, resource, message) are shown in full. Scanning is advisory: surfaced, not used to block or auto-fix the plan.

Infrastructure as code

Deployable Terraform (or CloudFormation on AWS), generated section by section, assembled deterministically, and checked for zero dangling references — copy it or download it.

Deploy guide

The exact CLI / console steps to provision and ship the stack on your chosen cloud.

Manifest

A downloadable record of the run — your inputs, the docs-corpus version, the model IDs, and pinned provider versions — so the result can be traced and regenerated.

Estimated footprint

An estimated energy and CO₂e figure for the compute that produced the plan, shown with its formula and sources — an estimate, not a measurement.

Limits, honestly

• Not "guaranteed to deploy." Grounded, cited, validated, and consistency-checked are necessary conditions for a good plan — not a promise that `terraform apply` or `cloudformation deploy` succeeds in your specific account, region, or quota.
• A citation verifies a FACT — that a service exists or supports a feature — not that the chosen service is the OPTIMAL fit for your workload. The architecture judgment is still yours to review.
• Terraform gets real `terraform validate` with providers, and the generated IaC is scanned with checkov + tflint, all in the request path. But `terraform plan` still doesn't run (it needs live cloud credentials and state), so validate-clean is not a guaranteed `apply`.
• Static scanning (checkov + tflint) surfaces security and best-practice issues — it does not guarantee a secure or deployable result, and we don't auto-fix every finding. Some flagged items are reasonable trade-offs for a starting-point plan; review them for your context.
• The validator is advisory: it flags gaps (see the failed Azure run on the proof page) rather than blocking the result.
• Energy and carbon figures are transparent estimates with their formula and sources shown — not measurements.