# Terraform Support in Maguyva: Infrastructure Context for AI Agents Canonical source: https://maguyva.ai/languages/terraform License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license). Maguyva supports Terraform with AST parsing and symbol extraction so AI agents can trace modules, locals, variables, resource references, and dynamic infrastructure patterns before suggesting changes. ## Support snapshot - Tier: AST and symbol support - Infrastructure - Extensions: .tf, .tfvars - Real AST parsing for syntax-aware search and structural context. - Named symbols feed semantic lookup and cross-reference. Graph navigation is available when relationship extraction is enabled. - This language is indexed for search, but it is not currently persisted into the code graph. - AST parsing and symbol extraction are both available. ## Best fit - Platform teams managing reusable Terraform modules, environment folders, and shared infrastructure patterns. - Repositories where app code changes often require corresponding infrastructure edits or impact review. - Agent workflows that need to understand references and blast radius before touching infrastructure definitions. ## Agent workflows - Trace how variables, locals, modules, and resources connect before editing a plan. - Compare environment variants and module usage to keep changes consistent. - Inspect likely downstream impact before the agent suggests an infrastructure modification. ## Why Terraform needs repo-level context Infrastructure code is where a lot of AI tooling quietly falls back to shallow text handling. That is not good enough. Terraform changes are usually sensitive, reference-heavy, and spread across modules, locals, variables, data sources, and environment-specific folders. The hard part is understanding how the configuration hangs together before changing it. That is why Terraform support matters even if your main application code lives elsewhere. If the repo contains infrastructure code, the agent needs to see it as part of the same system, not as an attachment it should guess about. ## What Maguyva helps agents understand in Terraform Maguyva supports Terraform structurally, which is the useful baseline for following module references, variable flows, and resource relationships. That matters even more once the code uses `count`, `for_each`, dynamic blocks, and shared modules that make the actual plan shape harder to recover from a quick skim. The practical benefit is that the agent can answer repository-level questions such as "where is this module reused?", "what depends on this variable?", or "which environment folders diverge from the pattern?" before it proposes a change. ## What this proves about Maguyva's language coverage Terraform is a good test of whether language coverage is actually useful. It shows whether Maguyva can treat application code, operational code, and infrastructure as one repository-level problem instead of separate islands. If your infrastructure sits next to service code, the [Go guide](/languages/go) is the closest backend pairing. If the same repo includes web or platform packages, the [TypeScript guide](/languages/typescript) is the right adjacent page. ## When this page is useful Use this page if the question is "can the agent keep infrastructure context too?" That is a more realistic question than asking about application languages alone. For the raw matrix, use [compatibility](/docs/compatibility). ## Engine details - Import normalization strips `module` and `source`, which makes module-level references easier to compare. - Terraform's language rules recognize `var`, `local`, `module`, `data`, and resource references for relationship extraction, but the current graph policy does not persist them into Maguyva's code graph. - Terraform-specific control flow such as `count`, `for_each`, and dynamic blocks is treated as first-class structure rather than plain text. ## Useful MCP entry points - `get_task_context`: Use it for prompts like “trace how the VPC module output feeds the ECS service” when you need a stitched answer fast. - `text_pattern_search`: Use exact text for resource addresses, module names, or variable keys before widening the analysis.