Pulumi vs OpenTofu

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Pulumi
   Pulumi✓fullprobed8/10

   A direct probe confirms Pulumi serves a working llms.txt at https://www.pulumi.com/llms.txt (HTTP 200) with a concise agent-oriented summary, and Pulumi also maintains extensive agent-oriented docs (MCP server docs, CLI docs) that AI assistants can be pointed at. missing for 10: independent/community confirmation that agents successfully consume llms.txt in practice, and a docs.md/markdown-flavored docs endpoint (which returned 404).

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.pulumi.com/llms.txt # Pulumi > Infrastructure as code in real programming languages. Define, deploy…”
   • [claimed-docs] “Pulumi’s MCP server implementation provides AI assistants with the ability to: Query your Pulumi Cloud stacks and their resources, Search ac…”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [probe] “official MCP server documented at https://www.pulumi.com/docs/ai/mcp-server/”

   proof ↗⚑ flag

   OpenTofu—none0/10

   A direct probe of https://opentofu.org/llms.txt returned HTTP 404, and no other evidence pack items reference an llms.txt file or agent-oriented documentation format; the docs are standard human-facing pages only.

   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   Pulumi✓fullprobed9/10

   Pulumi's CLI supports non-interactive flags and JSON output for scripted use, plus an Automation API explicitly designed for running Pulumi programs without the CLI in orchestration/CI contexts; hands-on probes confirm `pulumi preview/up/destroy --non-interactive` work headlessly on a local backend without Pulumi Cloud, and VCS integrations (GitHub/GitLab/Azure DevOps) support CI pipelines. Missing for 10: no first-party CI-specific documentation (e.g., GitHub Actions workflow examples) or independent CI-pipeline case study in the evidence pack.

   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [claimed-docs] “Connect Pulumi with GitHub, GitLab, and Azure DevOps using Pulumi-maintained version control integrations.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”

   proof ↗⚑ flag

   OpenTofu✓fullprobed9/10

   Hands-on probes confirm OpenTofu supports non-interactive, scriptable CI workflows: `-input=false`, `-auto-approve`, `-detailed-exitcode` for change detection, machine-readable JSON plan output via `tofu show -json`, and a full plan→apply→destroy loop with correct exit codes, all installable without a login/keys via brew — exactly what CI/agent automation needs. Missing for 10: no explicit vendor CI/CD integration guide (e.g., GitHub Actions/GitLab CI docs) or third-party CI pipeline examples in the evidence pack.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”

   proof ↗⚑ flag

3. ai-native userUse an official CLI

   weight 2 · round drawn
   Pulumi✓fullprobed9/10

   Pulumi ships an official CLI with documented commands (preview, up, import, destroy) and hands-on probes confirm it runs headlessly with structured JSON output an agent can parse, plus non-interactive/automated flags well suited to AI-native workflows. Missing for 10: no independent third-party review specifically praising the CLI's AI-native ergonomics beyond the vendor probes.

   • [probe] “official CLI documented at https://www.pulumi.com/docs/iac/cli/”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [claimed-docs] “you run `pulumi import` against a specific cloud resource. Pulumi adds the resource to your stack’s state and generates the code needed to m…”

   proof ↗⚑ flag

   OpenTofu✓fullprobed9/10

   OpenTofu ships an official, documented CLI (opentofu.org/docs/cli/) and hands-on probes confirm a full headless workflow — init, plan with machine-readable JSON output, auto-approved apply, and destroy — all scriptable without interactive input, which is exactly what an AI-native/agentic caller needs. It is also a drop-in Terraform replacement, so existing agent tooling built for Terraform's CLI works unchanged. missing for 10: no first-party documentation specifically addressing AI-agent usage patterns or guardrails (e.g., rate limits, agent-specific auth flows) beyond generic CLI/JSON support.

   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”

   proof ↗⚑ flag

4. ai-native userDrive the product through a documented public API

   weight 3 · round to Pulumi
   Pulumi~partialprobed6/10

   Pulumi offers a documented Automation API (programmatic, language-based interface) and a verified MCP server (probed handshake works) plus a CLI with JSON output, giving AI-native users multiple programmatic ways to drive it. However, there is no true public REST/OpenAPI API (openapi.json/swagger endpoints all 404) and no llms.txt-driven docs-md endpoint, so 'documented public API' in the traditional sense is unconfirmed. missing for 10: a documented REST/OpenAPI-style public API, independent third-party corroboration of Automation API usage, and confirmation that MCP/Automation API cover full CRUD parity with the CLI.

   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [claimed-docs] “Pulumi’s MCP server implementation provides AI assistants with the ability to: Query your Pulumi Cloud stacks and their resources, Search ac…”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.pulumi.com/openapi.json, https://www.pulumi.com/swagger.json, https://www.pulumi.com/api…”
   • [probe] “official MCP server documented at https://www.pulumi.com/docs/ai/mcp-server/”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”

   proof ↗⚑ flag

   OpenTofu~partialprobed5/10

   OpenTofu is drivable programmatically via its CLI (headless plan/apply/destroy loop, machine-readable JSON plan output) as confirmed by hands-on probes, which supports AI-native agentic automation, but there is no documented public HTTP/REST/OpenAPI API — probes for llms.txt, docs-md, and openapi/swagger endpoints all 404. missing for 10: a documented public API (REST/OpenAPI/SDK) beyond the CLI, official llms.txt or machine-readable docs endpoint, and any first-party API reference for programmatic/agentic access.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”

   proof ↗⚑ flag

5. ai-native userBuild against official SDKs

   weight 2 · round to Pulumi
   Pulumi✓fullprobed9/10

   Pulumi provides official SDKs across multiple mainstream languages (TypeScript, Python, Go, .NET, Java, YAML) with full provider surface area, plus an Automation API for programmatic use and a documented, hands-on-verified MCP server enabling AI assistants to interact with Pulumi programs. This is strongly corroborated by official docs and a live probe confirming the MCP server handshake works. Missing for 10: independent third-party (non-vendor) benchmarking of SDK completeness/parity across all languages, and no evidence of official SDKs in additional languages like Rust or Java-adjacent ecosystems beyond what's listed.

   • [claimed-docs] “Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL. Each language is equally capable and supports the full surfac…”
   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [claimed-docs] “Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL.”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [claimed-docs] “The Pulumi MCP server works with various AI-powered development tools: **Cursor**...**Anthropic’s Claude Code**...**Windsurf**...**Claude De…”
   • [probe] “official MCP server documented at https://www.pulumi.com/docs/ai/mcp-server/”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”

   proof ↗⚑ flag

   OpenTofu—none0/10

   The evidence pack shows only CLI usage, JSON plan output, and website docs; there is no mention of any official SDK (Go, Python, REST, or agent-oriented) that AI-native developers could build against, and probes explicitly show llms.txt, docs-md, and OpenAPI endpoints returning 404. Missing for 10: any documented official SDK, API/OpenAPI spec, or programmatic library for AI agents to integrate with OpenTofu beyond the CLI.

   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”

   proof ↗⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Pulumi
   Pulumi~partialprobed6/10

   Pulumi documents both an Automation API for embedding Pulumi programs into custom background services (pulumi-docs-2) and 'Neo', an agent described as autonomously provisioning, governing, and optimizing infrastructure from plain-English instructions (pulumi-docs-9, pulumi-docs-20), plus headless CLI runs confirmed via probe (pulumi-probe-6, pulumi-probe-7). However, Neo's autonomous background operation is only vendor marketing copy with no hands-on or independent verification, and Automation API requires the user to build their own scheduling/triggering layer rather than shipping a ready background-automation feature. Missing for 10: hands-on/independent evidence Neo (or another built-in scheduler) actually runs unattended in production, native trigger/schedule primitives beyond Automation API, and community corroboration of autonomous operation.

   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [claimed-docs] “Neo provisions, governs, and optimizes your cloud infrastructure — with enterprise controls built in.”
   • [claimed-docs] “Tell Neo what you need in plain English. It handles dependencies, executes changes, and monitors outcomes automatically.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”

   proof ↗⚑ flag

   OpenTofu~partialprobed4/10

   OpenTofu's CLI is fully non-interactive/keyless and scriptable (headless plan→apply→destroy verified in probes), which is a prerequisite for wiring it into cron jobs or CI/CD pipelines for autonomous runs, but there is no evidence of any built-in scheduler, trigger, webhook, or agent runtime that autonomously initiates or manages background runs on its own. missing for 10: native scheduling/trigger mechanism, evidence of autonomous (not just headless) background operation, first-party automation/orchestration features beyond CLI scriptability.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

2. ai-native userOperate the product with natural-language commands

   weight 2 · round to Pulumi
   Pulumi~partialprobed7/10

   Pulumi Neo is explicitly marketed to accept plain-English infrastructure requests ('Tell Neo what you need in plain English...') and the official MCP server, verified hands-on via JSON-RPC handshake, lets AI assistants translate natural-language prompts into Pulumi CLI/registry operations. However, Neo's NL capability is only vendor-claimed (no hands-on or community verification) and is a separate enterprise product, while the core Pulumi CLI itself remains code/command-driven, not NL-native. Missing for 10: independent or hands-on verification of Neo's natural-language handling, and evidence that natural-language control works without relying on Neo or an external AI coding assistant via MCP.

   • [claimed-docs] “Neo provisions, governs, and optimizes your cloud infrastructure — with enterprise controls built in.”
   • [claimed-docs] “Tell Neo what you need in plain English. It handles dependencies, executes changes, and monitors outcomes automatically.”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [claimed-docs] “The Pulumi MCP server works with various AI-powered development tools: **Cursor**...**Anthropic’s Claude Code**...**Windsurf**...**Claude De…”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”

   proof ↗⚑ flag

   OpenTofu—none0/10

   OpenTofu's interface is HCL configuration plus a fixed CLI command set (plan, apply, test, import, etc.); nothing in the evidence pack shows any natural-language command interface, NL parsing, or AI-native control surface — llms.txt and other AI-discovery probes even returned 404s.

   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”
   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Pulumi—none0/10

   No evidence of an interactive API reference with runnable examples; probes explicitly show no OpenAPI/Swagger spec (404s across candidate paths) and no mention of a live/sandboxed API explorer. Pulumi's docs describe language SDKs and CLI commands but not an interactive, runnable API reference.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.pulumi.com/openapi.json, https://www.pulumi.com/swagger.json, https://www.pulumi.com/api…”
   • [claimed-docs] “Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL.”

   proof ↗⚑ flag

   OpenTofu—none0/10

   OpenTofu's docs are static CLI command references (plan/apply/test/import) with no interactive API explorer or runnable-example sandbox; explicit probes confirm no OpenAPI/swagger spec and no llms.txt discoverability aid.

   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Pulumi—none0/10

   A direct probe for an OpenAPI/equivalent spec at all standard candidate paths returned 404 across the board, and no evidence pack item shows Pulumi publishing a downloadable machine-readable API spec; the llms.txt found is a marketing/context file, not an API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.pulumi.com/openapi.json, https://www.pulumi.com/swagger.json, https://www.pulumi.com/api…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.pulumi.com/llms.txt # Pulumi > Infrastructure as code in real programming languages. Define, deploy…”

   proof ↗⚑ flag

   OpenTofu—none0/10

   Explicit probes confirm no OpenAPI/Swagger spec or llms.txt is available (404s at all candidate paths), and no evidence of any machine-readable API spec being offered.

   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Pulumi
   Pulumi~partialprobed7/10

   Pulumi's testing docs describe integration tests that 'deploy ephemeral infrastructure and run external tests against it' and preview command that makes 'no changes to the stack,' and probes confirm a full headless up/destroy loop against a local file backend without touching Pulumi Cloud or production state. This supports safe sandbox testing, but the evidence never explicitly describes stack-based prod/sandbox isolation or guardrails preventing accidental production impact from an AI agent. Missing for 10: explicit multi-stack environment isolation guidance, agent-specific guardrails against touching prod stacks, and independent hands-on confirmation of safe sandboxing beyond the vendor-run probe.

   • [claimed-docs] “Unit Tests are fast in-memory tests that mock all external calls. Property Tests run resource-level assertions while infrastructure is being…”
   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”

   proof ↗⚑ flag

   OpenTofu~partialprobed5/10

   OpenTofu's `tofu test` command explicitly creates real infrastructure to test configuration and then destroys it, and workspaces/variables allow separate dev/staging/prod environments (multi-environment support mentioned in docs), which supports sandbox-style testing without touching production if configured with separate state/backends. However, there is no dedicated built-in sandboxing feature, no first-party guidance on isolating a sandbox from production data specifically, and no mocking/dry-run-only testing mode beyond plan preview. missing for 10: dedicated sandbox/mock-infrastructure feature, explicit doc guidance on isolating prod vs sandbox state, independent verification of test-command safety in practice.

   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”
   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”
   • [claimed-docs] “Dynamically generate provider configurations with for_each, eliminating repetitive code and improving maintainability. Perfect for multi-reg…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Pulumi—none0/10

   No evidence pack item discusses API versioning or a documented deprecation policy for Pulumi's APIs (CLI, SDK, Automation API, or MCP server); the OpenAPI probe returned 404s and no changelog/versioning policy is cited. Community evidence even mentions Pulumi lagging on deprecated Azure resources with no fix, but this is unrelated to a documented deprecation policy for Pulumi's own APIs.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.pulumi.com/openapi.json, https://www.pulumi.com/swagger.json, https://www.pulumi.com/api…”
   • [community] “I like it, but anybody I pitched it to was like: 'Ewww, TypeScript for Infra.' Pulumi for months used deprecated Azure stuff, and they didn'…”

   proof ↗⚑ flag

   OpenTofu—none0/10

   The evidence pack shows OpenTofu has versioned CLI output formats (e.g., plan JSON format_version) but contains no documentation of a formal API/CLI deprecation policy or version-support guarantees; the axis is applicable to an IaC tool with a CLI/JSON interface, but no evidence supports a documented deprecation policy. Missing for 10: explicit deprecation policy docs, versioning/SLA guarantees, changelog of breaking changes.

   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Pulumi~partialprobed6/10

   Pulumi supports bulk-oriented workflows: pulumi preview --import-file can generate an import covering every resource a program would create, the Automation API allows programmatic orchestration across many stacks or resources, and real-world usage reports deployments of 500+ resources at once. These give an AI agent, via CLI or MCP server, levers for bulk operations, but the docs never explicitly frame a bulk operation across many items workflow for AI agents, and the MCP server evidence only demonstrates single CLI command execution, not batch or bulk semantics. missing for 10: explicit bulk-operation API/CLI docs such as bulk import across many resources in one call or bulk stack updates framed for AI-agent consumption, and hands-on evidence of an agent performing such bulk ops via MCP

   • [claimed-docs] “run `pulumi preview --import-file` to generate an import file listing every resource the program would otherwise create”
   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [community] “Using Pulumi for about 1 year to manage gcp and AWS environments (5+) - each deployment is around 500 resources. At the begining it was bugg…”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”

   proof ↗⚑ flag

   OpenTofu~partialclaimed6/10

   OpenTofu supports bulk-style operations via resource graph parallelization, for_each-driven dynamic provider/module generation, -exclude flag for scoping bulk plan/apply, and programmatic module version updates across many modules, which together enable acting on many items at once. However this is infrastructure-as-code bulk management, not an AI-native batch/agent API, and there's no evidence of a dedicated bulk API, batch job orchestration, or AI-specific tooling for mass operations. missing for 10: dedicated bulk/batch API or agent-facing interface for large-scale multi-item operations, independent hands-on evidence of bulk operations at scale, AI-native tooling specifically for orchestrating many items programmatically.

   • [github] “OpenTofu builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources.”
   • [claimed-docs] “Selectively exclude resources from operations with the -exclude flag. This provides more control during testing and rollouts, allowing you t…”
   • [claimed-docs] “Dynamically generate provider configurations with for_each, eliminating repetitive code and improving maintainability.”
   • [claimed-docs] “Update all your modules programmatically with a single variable change. Never miss updating a module version by accident - keep your infrast…”
   • [claimed-docs] “Dynamically generate provider configurations with for_each, eliminating repetitive code and improving maintainability. Perfect for multi-reg…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round drawn
   Pulumi—none0/10

   The evidence covers Pulumi's languages, testing, state backends, policy-as-code guardrails, import, and MCP/Automation API integrations, but none of it describes a mechanism for defining rules that automatically trigger actions in response to events (e.g., webhooks, event-driven pipelines, or reactive automation). Policy as code (pulumi-docs-5/16) enforces guardrails during deployments rather than triggering actions on arbitrary events, and the Automation API (pulumi-docs-2) is for programmatic invocation, not event-driven rule execution.

   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [claimed-docs] “Pulumi Policies enables you to implement policy as code across your entire cloud infrastructure. You define guardrails in code and apply the…”
   • [claimed-docs] “You define guardrails in code and apply them consistently across resources managed by Pulumi IaC, provisioned with Terraform or CloudFormati…”

   proof ↗⚑ flag

   OpenTofu—none0/10

   OpenTofu's evidence pack covers CLI plan/apply/test/import workflows but shows no rule-based or event-triggered automation engine (e.g., webhooks, event listeners, policy-triggered actions) built into the tool itself.

   ⚑ flag

3. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Pulumi
   Pulumi~partialprobed6/10

   Pulumi's code-based IaC is inherently versionable via standard VCS (git integrations documented), and `pulumi preview`/`pulumi destroy`/state backends give rollback-like control validated hands-on via CLI probes; policy-as-code adds review guardrails. However there's no dedicated 'automation review' workflow, no built-in diff/approval UI beyond preview output, and community feedback flags documentation/complexity issues around dependency management that complicate confident rollback for AI-driven changes. missing for 10: a first-party automated review/approval gate for AI-initiated changes, explicit rollback command/semantics (vs. re-apply prior state), and independent verification of policy-as-code enforcement in practice.

   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi Policies enables you to implement policy as code across your entire cloud infrastructure. You define guardrails in code and apply the…”
   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Connect Pulumi with GitHub, GitLab, and Azure DevOps using Pulumi-maintained version control integrations.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [community] “Pulumi also has a killer Automation feature, where you can code infrastructure migrations, not unlike you'd do for SQL. Neither TF nor CDK a…”
   • [community] “A couple of years ago I started down the Pulumi path... values that are only available in the second phase (eg a subnet ID) can't be accesse…”

   proof ↗⚑ flag

   OpenTofu~partialprobed5/10

   OpenTofu's state is plain text-based (HCL) which enables version control via git, and plan files (tofu plan -out) provide a preview/review mechanism, with tofu destroy/apply providing rollback-like operations, but there's no native built-in versioning, review workflow, or rollback/history feature beyond what git or external tools (e.g. Terraform Cloud-like state history) provide. missing for 10: no first-party state history/rollback mechanism, no built-in review/approval workflow beyond plan output, no independent evidence of an audit trail or diff-based rollback UI.

   • [claimed-docs] “Version control your infrastructure with OpenTofu. Track changes, collaborate with your team, and deploy DNS configurations with a single co…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

Import

1. platform-engineerImport existing cloud resources under management and generate matching configuration code

   weight 3 · round to Pulumi
   Pulumi✓fullclaimed9/10

   Pulumi provides a documented `pulumi import` command that adopts existing resources into stack state and generates matching code in the target language, plus `pulumi preview --import-file` to bulk-generate import files for existing resources, directly matching the story. Docs explicitly describe this as core migration functionality for resources created manually or by other IaC tools. Missing for 10: independent/hands-on verification of the import workflow itself (only preview/apply loop was probed, not import).

   • [claimed-docs] “Adopting the existing resource to bring it under management by Pulumi... is called adoption or import.”
   • [claimed-docs] “Most infrastructure as code projects require working with existing cloud resources, whether those resources were originally created with ano…”
   • [claimed-docs] “you run `pulumi import` against a specific cloud resource. Pulumi adds the resource to your stack’s state and generates the code needed to m…”
   • [claimed-docs] “run `pulumi preview --import-file` to generate an import file listing every resource the program would otherwise create”
   • [claimed-docs] “Migrate from Terraform, CloudFormation, and other tools.”

   proof ↗⚑ flag

   OpenTofu~partialcommunity6/10

   OpenTofu documents `tofu import` for importing existing resources into state, and community evidence confirms `for_each` support for import blocks (bulk import). However, evidence does not show automatic configuration-code generation from imported resources (e.g., a `-generate-config-out` style feature) — missing for 10: documentation/proof of automatic config generation during import, hands-on demonstration of the full import-to-config workflow, and independent verification of accuracy for generated code.

   • [claimed-docs] “The `tofu import` command imports existing resources into OpenTofu.”
   • [community] “"for_each" implementation for "import" blocks... Well, I'm officially on board with this project. We've been told this is impossible for yea…”

   proof ↗⚑ flag

Migration

1. platform-engineerMigrate an existing Terraform-format codebase and its state into this tool

   weight 2 · round to OpenTofu
   Pulumi~partialclaimed6/10

   Pulumi documents importing existing (e.g., Terraform-created) resources via `pulumi import` and `pulumi preview --import-file`, generating Pulumi code and adding resources to Pulumi state, and explicitly markets migration from Terraform/CloudFormation. However, this is resource-by-resource adoption of live infrastructure, not a direct conversion of Terraform HCL codebase or import of Terraform state files themselves — no evidence of a bulk Terraform-state-to-Pulumi-state converter or HCL-to-native-language transpiler tool. missing for 10: evidence of direct Terraform state file import/conversion, bulk/automated HCL-to-Pulumi code conversion tooling, and independent/hands-on confirmation of a full codebase migration success story.

   • [claimed-docs] “Adopting the existing resource to bring it under management by Pulumi... is called adoption or import.”
   • [claimed-docs] “Migrate from Terraform, CloudFormation, and other tools.”
   • [claimed-docs] “Most infrastructure as code projects require working with existing cloud resources, whether those resources were originally created with ano…”
   • [claimed-docs] “run `pulumi preview --import-file` to generate an import file listing every resource the program would otherwise create”
   • [claimed-docs] “you run `pulumi import` against a specific cloud resource. Pulumi adds the resource to your stack’s state and generates the code needed to m…”

   proof ↗⚑ flag

   OpenTofu✓fullprobed7/10

   OpenTofu explicitly positions itself as a drop-in, backwards-compatible replacement for Terraform, and community reports (including real client migrations and "s/terraform/opentofu/g") corroborate that existing Terraform configs and state can be migrated with minimal effort; hands-on probes confirm the CLI runs standard Terraform-style plan/apply/destroy workflows without modification. Missing for 10: an explicit first-party migration guide or documented state-file conversion/validation step (beyond general 'drop-in' claims), and independent verification of state-file compatibility across complex/large codebases.

   • [claimed-docs] “It serves as a drop-in replacement for Terraform, preserving your existing workflows and configurations.”
   • [claimed-docs] “It serves as a **drop-in replacement for Terraform**, preserving your existing workflows and configurations.”
   • [claimed-docs] “Backwards-compatible - so that the existing code can drive value for years to come”
   • [community] “Fortunately using OpenTofu is just s/terraform/opentofu/g at this point.”
   • [community] “The move towards OpenTofu is going to be a slow tide, but it is coming. It's an easy migration... We made the jump for one client, started a…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

Licensing

1. devops-leadRely on an open license and open governance so the tool cannot be relicensed out from under my company

   weight 3 · round to OpenTofu
   Pulumi—none0/10

   The evidence pack contains no mention of Pulumi's license type (e.g., Apache 2.0), its governance model, or any foundation/neutral steward that would prevent unilateral relicensing — only GitHub repo links and generic self-hosting/backend docs. Given the well-known industry concern (post-Terraform BSL) that devops leads would want addressed, this axis clearly applies but no evidence in the pack speaks to license or governance guarantees.

   • [github] “Skip the YAML, and use standard language features like loops, functions, classes, and package management that you already know and love.”
   • [github] “Pulumi automatically provisions and manages your resources on AWS, Azure, Google Cloud Platform, Kubernetes, and 300+ providers”
   • [claimed-docs] “Self-hosting available”

   proof ↗⚑ flag

   OpenTofu✓fullcommunity7/10

   OpenTofu explicitly ties its open-source guarantee to being hosted under the Linux Foundation, a neutral governance body designed to prevent unilateral relicensing — directly addressing the devops-lead's concern. Community commentary raises cultural/governance grumbles but no concrete evidence of relicensing risk or license violation, so this doesn't rise to a dispute. missing for 10: explicit license text/name (e.g., MPL 2.0) in evidence, details on governance structure (TSC, contribution/veto rules), and independent third-party corroboration of the Linux Foundation guarantee.

   • [claimed-docs] “Now that we are part of the Linux Foundation, we can guarantee that OpenTofu will remain: Truly open source”
   • [community] “It seems the license info is not readily available on the website. I can easily find it in the GitHub repo but not on the website. I think i…”
   • [community] “So far it appears to be the same old thing with a different owner. Maintainers act like they own the thing and everyone else (read: the user…”

   proof ↗⚑ flag

Stability

1. developerRely on documented compatibility promises and upgrade guides between releases

   weight 2 · round to OpenTofu
   Pulumi—none0/10

   The evidence pack contains no documentation of versioning/compatibility promises, deprecation policy, or upgrade guides between Pulumi CLI/SDK releases; the closest items (resource import/adoption docs) address migrating existing cloud resources into Pulumi, not release-to-release compatibility. Missing for 10: any semver/compatibility policy docs, breaking-change/deprecation notices, or dedicated upgrade guides between major versions.

   ⚑ flag

   OpenTofu~partialcommunity5/10

   OpenTofu publicly commits to backwards compatibility and positions itself as a drop-in replacement for Terraform, preserving existing configs/workflows, which implies a compatibility promise, but the evidence pack contains no explicit version-to-version upgrade guide documentation for OpenTofu releases themselves, and one community comment notes OpenTofu is 'already diverging from upstream,' raising uncertainty about long-term compatibility guarantees. missing for 10: dedicated upgrade-guide docs between OpenTofu minor/major releases, changelog/breaking-change policy evidence, independent confirmation of smooth upgrades across OpenTofu versions.

   • [claimed-docs] “Backwards-compatible - so that the existing code can drive value for years to come”
   • [claimed-docs] “It serves as a **drop-in replacement for Terraform**, preserving your existing workflows and configurations.”
   • [claimed-docs] “It serves as a drop-in replacement for Terraform, preserving your existing workflows and configurations.”
   • [community] “OpenTofu is already diverging from upstream but is relying on upstream providers so I'm not sure how to feel about it.”
   • [community] “Fortunately using OpenTofu is just s/terraform/opentofu/g at this point.”

   proof ↗⚑ flag

1. ai-native userExport all of my data in open formats and leave

   weight 3 · round to OpenTofu
   Pulumi~partialcommunity5/10

   Pulumi code is written in standard, open programming languages (TS, Python, Go, etc.) rather than a proprietary DSL, and state can be stored in a self-managed 'DIY' backend (S3, Azure Blob, GCS) instead of Pulumi Cloud, giving a path to keep data in open formats and avoid full platform lock-in. However, community evidence notes Pulumi still 'calls into the mothership' for some functionality and there is no documented explicit bulk-export/migration tool for leaving the platform. Missing for 10: dedicated data-export/migration tooling to leave, clear documentation on state file/format portability guarantees, and independent verification that self-hosted deployments have no residual cloud dependency.

   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”
   • [claimed-docs] “Self-hosting available”
   • [community] “Last time I checked... Pulumi only works by calling in to the mothership: i.e. you cannot build an airgapped infrastructure with it. This wa…”
   • [github] “Skip the YAML, and use standard language features like loops, functions, classes, and package management that you already know and love.”

   proof ↗⚑ flag

   OpenTofu~partialprobed6/10

   OpenTofu's state and plan files are plain JSON/HCL (confirmed by the probed `tofu show -json` machine-readable output) and the project is governed as 'truly open source' under the Linux Foundation, meaning there is no proprietary lock-in and configs/state can be freely moved or forked. However, there is no explicit documentation of a dedicated 'export and leave' workflow, no discussion of migrating state to other tools, and no llms.txt/data-export interface (llms.txt 404, no OpenAPI) that would make this openness explicit for AI-native tooling. missing for 10: explicit data-export/portability docs, llms.txt or machine-readable manifest, third-party confirmation of migrating state out of OpenTofu.

   • [claimed-docs] “Now that we are part of the Linux Foundation, we can guarantee that OpenTofu will remain: Truly open source”
   • [claimed-docs] “Backwards-compatible - so that the existing code can drive value for years to come”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [community] “Fortunately using OpenTofu is just s/terraform/opentofu/g at this point.”

   proof ↗⚑ flag

2. ai-native userRead the product's source under an open license

   weight 2 · round to OpenTofu
   Pulumi~partialclaimed4/10

   Evidence confirms Pulumi's core CLI/SDK is published on GitHub (pulumi-gh-1, pulumi-gh-2), so an AI-native user could read source there, but the evidence pack never states an explicit open-source license, and Pulumi's cloud/state backend and Neo agent components are proprietary SaaS (pulumi-docs-4, pulumi-docs-9) rather than open source. missing for 10: explicit license text/statement, confirmation that all product components (not just core CLI/SDK) are open, independent confirmation of license terms.

   • [github] “Skip the YAML, and use standard language features like loops, functions, classes, and package management that you already know and love.”
   • [github] “Pulumi automatically provisions and manages your resources on AWS, Azure, Google Cloud Platform, Kubernetes, and 300+ providers”
   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Neo provisions, governs, and optimizes your cloud infrastructure — with enterprise controls built in.”

   proof ↗⚑ flag

   OpenTofu✓fullcommunity8/10

   OpenTofu's source is publicly hosted on GitHub (opentofu-gh-1) and the manifesto explicitly commits to remaining 'Truly open source' now under the Linux Foundation (opentofu-docs-26); community discussion confirms the license is readily found in the GitHub repo even if not prominent on the marketing site (opentofu-comm-3). Missing for 10: explicit citation of the license text/name (e.g., MPL 2.0) and independent legal/audit confirmation beyond community mention.

   • [github] “OpenTofu builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources.”
   • [claimed-docs] “Now that we are part of the Linux Foundation, we can guarantee that OpenTofu will remain: Truly open source”
   • [community] “It seems the license info is not readily available on the website. I can easily find it in the GitHub repo but not on the website. I think i…”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round drawn
   Pulumi✓fullprobed8/10

   Pulumi's core engine/CLI is open-source and can run fully locally without any cloud dependency — confirmed hands-on via probes showing `pulumi preview`/`up`/`destroy` running headlessly against a local file:// backend with PULUMI_CONFIG_PASSPHRASE for state encryption (pulumi-probe-6, pulumi-probe-7). Docs further describe a 'DIY backend' storing state in self-managed object storage (S3/Azure Blob/GCS) as an alternative to the hosted Pulumi Cloud (pulumi-docs-4, pulumi-docs-14, pulumi-docs-23), and the pricing page explicitly states 'Self-hosting available' for the broader service (pulumi-docs-27), corroborated by a community note that Pulumi's state service has a self-management option (pulumi-comm-19). missing for 10: detailed first-party documentation of deploying the full self-hosted Pulumi Cloud service (UI/API), and independent hands-on verification of that enterprise self-hosted deployment rather than just the DIY state-backend/local-CLI path.

   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”
   • [claimed-docs] “Self-hosting available”
   • [community] “Pulumi maintains its own state service (with option of self management)... As a developer, I quite liked Pulumi resource model, documentatio…”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”

   proof ↗⚑ flag

   OpenTofu✓fullprobed8/10

   OpenTofu is fully open-source (Linux Foundation governed), can be installed and run entirely on one's own infrastructure via multiple install methods, and probes confirm a fully local, keyless CLI workflow (init/plan/apply/destroy) with no SaaS dependency — this is inherently self-hostable since it's just a binary operating on local/backend state. missing for 10: no explicit vendor documentation section titled 'self-hosting' or dedicated guide addressing enterprise/air-gapped self-hosted deployment scenarios, and no independent hands-on report specifically validating self-hosted production use at scale.

   • [claimed-docs] “You can install OpenTofu via a wide range of methods. Please select your operating system and installation method”
   • [claimed-docs] “Now that we are part of the Linux Foundation, we can guarantee that OpenTofu will remain: Truly open source”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [claimed-docs] “Backwards-compatible - so that the existing code can drive value for years to come”

   proof ↗⚑ flag

Agent plan parsing

1. ai-native userGet machine-readable plan output (JSON) that an agent can parse to reason about a proposed change

   weight 3 · round drawn
   Pulumi✓fullprobed9/10

   Pulumi's `pulumi preview --json` produces a structured JSON steps[] array (op, urn, etc.) that an agent can parse to reason about a proposed change, and this was independently verified hands-on in a local, non-interactive run without Pulumi Cloud. Documentation and CLI reference corroborate this as an officially supported flag. missing for 10: no independent third-party (non-vendor) documentation of agents actually consuming this JSON for reasoning, only a single hands-on probe.

   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”

   proof ↗⚑ flag

   OpenTofu✓fullprobed9/10

   Hands-on probe confirms `tofu show -json plan.out` emits machine-readable plan JSON (format_version 1.2) with planned_values, parseable by agent tooling, alongside documented plan/apply CLI workflow supporting `-out=FILE` for later JSON conversion. missing for 10: no independent third-party corroboration beyond the single probe run.

   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”

   proof ↗⚑ flag

Ai infra ops

1. ai-native userHave an agent author an infrastructure change, run a plan headlessly, and present the diff for my approval

   weight 3 · round drawn
   Pulumi✓fullprobed8/10

   Pulumi's Automation API and CLI allow headless plan generation (`pulumi preview --non-interactive --json`) with structured diff output that an agent can parse, and hands-on probes confirm this and the full apply loop work headlessly without Pulumi Cloud; the official MCP server (verified via handshake) lets AI assistants generate infrastructure code and run CLI commands, supporting an agent-authored-and-approved workflow. missing for 10: a single end-to-end demonstrated workflow tying MCP-based code authoring directly into the headless preview/approval loop, and independent (non-vendor) verification of that combined flow.

   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”
   • [claimed-docs] “Pulumi’s MCP server implementation provides AI assistants with the ability to: Query your Pulumi Cloud stacks and their resources, Search ac…”
   • [claimed-docs] “The Pulumi MCP server works with various AI-powered development tools: **Cursor**...**Anthropic’s Claude Code**...**Windsurf**...**Claude De…”

   proof ↗⚑ flag

   OpenTofu✓fullprobed8/10

   Hands-on probes confirm a full headless plan→apply loop: `tofu plan -detailed-exitcode -out=plan.out` runs non-interactively and signals changes, `tofu show -json` emits machine-readable diff output parseable by agent tooling, and `tofu apply plan.out` executes the saved plan for approval-gated apply. This directly matches the story of an agent authoring changes, planning headlessly, and presenting a diff for approval. missing for 10: no first-party agent/CI orchestration example or official docs showing an approval-gate workflow built around the JSON plan output, and no independent (non-vendor) corroboration beyond the probe run.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”

   proof ↗⚑ flag

Automation api

1. developerDrive deployments programmatically from my own application code rather than only through the CLI

   weight 2 · round to Pulumi
   Pulumi✓fullcommunity9/10

   Pulumi's Automation API is explicitly documented as a programmatic interface for running Pulumi programs without the CLI, letting developers drive previews/deploys/destroys directly from application code, and this is corroborated by community mention of coding infra migrations via Automation. missing for 10: independent hands-on verification of the Automation API itself (the probes validate CLI/MCP headless flows but not an actual Automation API SDK call).

   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [community] “Pulumi also has a killer Automation feature, where you can code infrastructure migrations, not unlike you'd do for SQL. Neither TF nor CDK a…”

   proof ↗⚑ flag

   OpenTofu—none0/10

   All evidence describes CLI commands (`tofu plan`, `apply`, `show -json`) and JSON output that can be parsed by external scripts, but there is no official SDK, Go library, or API for embedding OpenTofu operations directly in application code, and probes explicitly show no OpenAPI/API endpoints exist. This means programmatic control still requires shelling out to the CLI rather than a first-class application-integration path.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”

   proof ↗⚑ flag

Plan workflow

1. developerTear down an entire environment cleanly with a destroy operation

   weight 2 · round drawn
   Pulumi✓fullprobed9/10

   Pulumi's `pulumi destroy` command is directly evidenced by a hands-on probe showing it exits 0 and cleanly tears down resources after an apply, running headlessly without cloud dependency, confirming the standard destroy workflow works as documented. missing for 10: no independent/community corroboration specifically discussing destroy behavior (only a first-party probe and docs).

   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [probe] “official CLI documented at https://www.pulumi.com/docs/iac/cli/”

   proof ↗⚑ flag

   OpenTofu✓fullprobed9/10

   OpenTofu docs explicitly describe destroy-mode planning that removes all remote objects leaving an empty state, and a hands-on probe confirms a full plan→apply→destroy loop exiting cleanly (exit 0). This directly matches the story of tearing down an environment cleanly. Missing for 10: independent (non-probe) third-party confirmation of destroy behavior at scale or with complex multi-resource environments.

   • [claimed-docs] “Destroy mode: creates a plan whose goal is to destroy all remote objects that currently exist, leaving an empty OpenTofu state.”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

2. devops-leadRun plan and apply non-interactively in CI using saved plan artifacts and approval flags

   weight 3 · round to OpenTofu
   Pulumi~partialprobed6/10

   Evidence confirms Pulumi CLI supports fully non-interactive plan/apply in CI: `pulumi preview --non-interactive --json` and `pulumi up --non-interactive --yes --skip-preview` both ran headlessly with approval flags (--yes) and produced machine-parseable output, per hands-on probes [pulumi-probe-6][pulumi-probe-7], with `pulumi preview` docs confirming plan-only dry-run behavior [pulumi-docs-8][pulumi-docs-19]. However, the pack contains no evidence of the specific 'saved plan artifact' workflow (e.g., generating and re-applying a persisted plan file) that the story calls out, only generic non-interactive preview/apply. Missing for 10: documentation or hands-on proof of saved-plan-artifact generation/application (e.g., --save-plan/--plan flags), and independent (non-vendor) confirmation of this exact CI pattern.

   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”

   proof ↗⚑ flag

   OpenTofu✓fullprobed9/10

   Docs describe saving plans with `-out=FILE` and applying them via `tofu apply plan.out`, and hands-on probes confirm a full non-interactive plan→apply→destroy loop using `-input=false -auto-approve -detailed-exitcode`, matching the CI approval-flag workflow described in the story. missing for 10: explicit CI/CD pipeline examples (e.g., GitHub Actions/GitLab CI snippets) showing artifact upload/download between plan and apply stages.

   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

3. platform-engineerPreview exactly what will change — creates, updates, and destroys — before applying

   weight 3 · round drawn
   Pulumi✓fullprobed9/10

   Pulumi's `pulumi preview` command explicitly shows creates, updates, and destroys without applying any changes, and this was independently verified via hands-on probe producing structured JSON steps[] output that an agent/tool can consume. Docs and probe evidence corroborate this core plan-apply workflow works headlessly. Missing for 10: independent third-party review specifically praising/critiquing preview accuracy in production use (community evidence is about Pulumi generally, not preview diffing specifically).

   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [claimed-docs] “run `pulumi preview --import-file` to generate an import file listing every resource the program would otherwise create”

   proof ↗⚑ flag

   OpenTofu✓fullprobed9/10

   OpenTofu's tofu plan command is explicitly documented to preview creates, updates, and destroys before applying, with dedicated destroy and refresh-only modes, and this was independently verified via a hands-on probe showing a real plan proposing a create, saved to a file, and later applied and destroyed successfully. Machine-readable plan JSON output further supports precise change previewing. missing for 10: independent third-party review of plan accuracy on complex multi-resource updates beyond the single-resource probe

   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “Destroy mode: creates a plan whose goal is to destroy all remote objects that currently exist, leaving an empty OpenTofu state.”
   • [claimed-docs] “Refresh-only mode: creates a plan whose goal is only to update the OpenTofu state and any root module output values to match changes made to…”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

4. platform-engineerTarget or exclude specific resources in a plan or apply

   weight 1 · round to OpenTofu
   Pulumi—none0/10

   No evidence in the pack mentions Pulumi's targeting/exclusion flags (e.g., `--target`, `--exclude`) for `pulumi preview`/`pulumi up`/`pulumi destroy`; the pack only covers preview mechanics, import, and state/backends without addressing resource-scoped plan/apply. missing for 10: documentation or hands-on proof of --target/--exclude (or equivalent) flags limiting a plan/apply to specific resources.

   ⚑ flag

   OpenTofu✓fullprobed8/10

   OpenTofu explicitly documents the -exclude flag for excluding resources from operations, and -target flag support is implied by drop-in Terraform compatibility plus verified hands-on plan/apply workflows. missing for 10: explicit docs/example for the -target flag itself and independent community confirmation of targeted apply usage.

   • [claimed-docs] “Selectively exclude resources from operations with the -exclude flag. This provides more control during testing and rollouts, allowing you t…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

Ai infra ops

1. ai-native userLet an agent plan and apply with least-privilege credentials and review gates so it cannot make unapproved changes

   weight 2 · round to Pulumi
   Pulumi~partialprobed5/10

   Pulumi provides the building blocks — Policy as Code guardrails (pulumi-docs-5/16), a preview/dry-run step that shows changes before they're applied (pulumi-docs-8/19, pulumi-probe-6), and an MCP server letting AI assistants query/generate/delegate infra changes (pulumi-docs-7/18/26, pulumi-probe-8) — but there is no documented mechanism tying an agent's MCP/CLI actions specifically to least-privilege scoped credentials or an explicit human-approval gate before 'pulumi up' executes for agent-initiated changes. Missing for 10: explicit least-privilege credential scoping for agent identities, a documented approval/review workflow gating agent-triggered applies, and evidence the MCP server itself is constrained from calling 'pulumi up' without human sign-off.

   • [claimed-docs] “Pulumi Policies enables you to implement policy as code across your entire cloud infrastructure. You define guardrails in code and apply the…”
   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [claimed-docs] “Pulumi’s MCP server implementation provides AI assistants with the ability to: Query your Pulumi Cloud stacks and their resources, Search ac…”
   • [claimed-docs] “The Pulumi MCP server works with various AI-powered development tools: **Cursor**...**Anthropic’s Claude Code**...**Windsurf**...**Claude De…”
   • [claimed-docs] “The Pulumi Model Context Protocol (MCP) server enables AI-powered coding assistants to access your Pulumi Cloud resources, generate infrastr…”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”

   proof ↗⚑ flag

   OpenTofu~partialprobed4/10

   OpenTofu's plan/apply separation (saved plan files, machine-readable JSON output via `tofu show -json`, and exit codes) gives an agent a natural review gate where a human or policy layer can inspect a plan before `apply` executes it, as shown in probes -5/-6/-7 and docs-3/-4/-21. However, there is no evidence of built-in least-privilege credential scoping, RBAC, approval workflows, or a policy-as-code engine (Sentinel/OPA equivalent) enforcing that gate — the review step is only possible via external tooling, not something OpenTofu itself provides. Missing for 10: native policy-as-code/policy enforcement, credential scoping/RBAC features, and any documented approval-gate mechanism tied to identity or role.

   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “developers can use speculative plans to verify the effect of their changes before submitting them for code review”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

Policy

1. devops-leadEnforce policy-as-code checks that block non-compliant infrastructure changes before apply

   weight 3 · round to Pulumi
   Pulumi✓fullclaimed8/10

   Pulumi's Policy-as-Code product explicitly lets teams define guardrails in code and apply them consistently across resources managed by Pulumi, Terraform, CloudFormation, or created manually — directly addressing pre-apply compliance enforcement, and this integrates with the CLI's preview/apply workflow to block non-compliant changes before they take effect. Missing for 10: no independent/hands-on evidence of a policy pack actually blocking a non-compliant `pulumi up`, and no detail on CI/CD gating specifics beyond docs claims.

   • [claimed-docs] “Pulumi Policies enables you to implement policy as code across your entire cloud infrastructure. You define guardrails in code and apply the…”
   • [claimed-docs] “You define guardrails in code and apply them consistently across resources managed by Pulumi IaC, provisioned with Terraform or CloudFormati…”
   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”

   proof ↗⚑ flag

   OpenTofu—none0/10

   The evidence pack shows OpenTofu's plan workflow and machine-readable plan JSON output (e.g., opentofu-probe-5, opentofu-probe-6) which could theoretically feed external policy engines, but there is no mention of any built-in or integrated policy-as-code framework (e.g., Sentinel, OPA/Conftest, Checkov) or documented workflow for blocking non-compliant applies. Missing for 10: any policy-as-code engine or gating mechanism, documentation of policy enforcement in CI/CD, and evidence that non-compliant plans are actually blocked before apply.

   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Pulumi
   Pulumi~partialclaimed5/10

   Pulumi lets users choose a self-managed 'DIY' state backend (AWS S3, Azure Blob Storage, Google Cloud Storage) or self-host, which effectively lets a user pick the storage region/provider for state data, and self-hosting is explicitly offered on the pricing page. However, there is no documented region-selection control for the default Pulumi Cloud managed backend itself, and no explicit data-residency/compliance documentation (e.g., EU-only region option) for AI-native workflows. Missing for 10: explicit region-selection UI/API for Pulumi Cloud's managed backend, documented data-residency guarantees or compliance certifications tied to region choice.

   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”
   • [claimed-docs] “Self-hosting available”

   proof ↗⚑ flag

   OpenTofu—none0/10

   OpenTofu's evidence covers state encryption and backend usage but contains no documentation or claims about choosing a storage region/data-residency for state or configuration data. While backend configuration (e.g., S3) inherently involves region settings, none of the evidence addresses residency controls as a feature.

   ⚑ flag

2. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Pulumi—none0/10

   The evidence pack contains no mention of a telemetry/usage-tracking opt-out setting (e.g., an env var, CLI flag, or config option) for Pulumi CLI or MCP server; no documentation or community evidence addresses telemetry controls at all.

   ⚑ flag

   OpenTofu—none0/10

   No evidence in the pack addresses telemetry, usage tracking, or an opt-out mechanism for OpenTofu; the axis is plausible for a CLI tool but nothing documents it.

   ⚑ flag

Languages

1. developerDefine infrastructure in a general-purpose programming language with types, loops, and IDE support

   weight 2 · round to Pulumi
   Pulumi✓fullcommunity9/10

   Pulumi's core value proposition is defining infrastructure in general-purpose languages (TypeScript, Python, Go, .NET, Java) with full access to language features like loops, functions, classes, and types, backed by standard IDE tooling via SDKs; this is corroborated by community testimonials praising the type system and language ergonomics. Missing for 10: no direct evidence of specific IDE plugin/autocomplete features beyond inferred SDK typing benefits, and some community complaints about complexity/documentation temper a perfect score.

   • [claimed-docs] “Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL. Each language is equally capable and supports the full surfac…”
   • [claimed-docs] “Define and manage cloud infrastructure using TypeScript, Python, Go, .NET, Java, and YAML.”
   • [github] “Skip the YAML, and use standard language features like loops, functions, classes, and package management that you already know and love.”
   • [community] “I love Pulumi. It's a joy to use a proper programming language to manage infra. I wish more tools would adapt this.”
   • [community] “I'm in love with Pulumi. Simply one of the best tools I have in my stack. After about a year of use, I simply cannot go back to editing YAML…”
   • [community] “Using Pulumi for about 1 year to manage gcp and AWS environments (5+) - each deployment is around 500 resources. At the begining it was bugg…”

   proof ↗⚑ flag

   OpenTofu—none0/10

   OpenTofu's evidence pack only shows HCL-based declarative configuration (for_each loops, dynamic provider blocks) rather than a general-purpose programming language with types and IDE support; there is no mention of a CDK-like SDK (e.g., TypeScript/Python bindings) that would satisfy this story.

   ⚑ flag

Modules

1. developerConsume and publish reusable modules or components from a public registry

   weight 3 · round drawn
   Pulumi~partialprobed6/10

   Pulumi has a well-documented public Registry of providers/packages (referenced implicitly via 'Pulumi Registry providers' in pulumi-docs-1 and the MCP server description 'querying Pulumi Registry information' in pulumi-probe-8), and 300+ providers are consumable per pulumi-gh-2. However, the evidence pack lacks explicit documentation of a publishing workflow for developers to submit/publish their own reusable components/packages to the public Registry, versioning/discovery mechanics, or community corroboration of publishing experience. missing for 10: first-party docs on the publish/submission process for community packages, evidence of component/package authoring guides, independent/hands-on confirmation of publishing a package to the Registry.

   • [claimed-docs] “Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL. Each language is equally capable and supports the full surfac…”
   • [github] “Pulumi automatically provisions and manages your resources on AWS, Azure, Google Cloud Platform, Kubernetes, and 300+ providers”
   • [probe] “PROBE mcp-handshake (local run): the official Pulumi MCP server (`npx @pulumi/mcp-server@latest stdio`, v0.2.0) answered a JSON-RPC initiali…”

   proof ↗⚑ flag

   OpenTofu~partialclaimed6/10

   OpenTofu's docs highlight a large public registry (23,600+ modules) and version-controlled module usage (opentofu-docs-13, opentofu-docs-24, opentofu-docs-12), confirming module consumption is core to the product. However, there is no direct evidence describing a publishing workflow for modules to the registry (e.g., versioning/publish CLI or registry submission process). missing for 10: explicit publish/versioning workflow documentation, independent confirmation of registry usability, and any hands-on evidence of publishing a module.

   • [claimed-docs] “With a thriving ecosystem of 3,900+ providers and 23,600+ modules, you can build and manage infrastructure across every cloud platform with …”
   • [claimed-docs] “With a thriving ecosystem of **3,900+ providers** and **23,600+ modules**, you can build and manage infrastructure across every cloud platfo…”
   • [claimed-docs] “Update all your modules programmatically with a single variable change. Never miss updating a module version by accident - keep your infrast…”

   proof ↗⚑ flag

Providers

1. developerManage resources across all major clouds and SaaS providers through a broad provider ecosystem

   weight 3 · round drawn
   Pulumi✓fullprobed9/10

   Pulumi's provider ecosystem is well documented with 300+ providers spanning AWS, Azure, GCP, Kubernetes, and SaaS offerings via the Pulumi Registry, corroborated by GitHub docs and confirmed hands-on via CLI probes deploying resources. Community evidence corroborates real-world multi-cloud usage (AWS, GCP, Azure, DigitalOcean) though some note documentation/provider lag issues for niche services. Missing for 10: independent quantification of SaaS-provider breadth beyond major clouds and no dispute-level evidence of provider gaps preventing broad usage.

   • [github] “Pulumi automatically provisions and manages your resources on AWS, Azure, Google Cloud Platform, Kubernetes, and 300+ providers”
   • [claimed-docs] “Pulumi supports TypeScript, JavaScript, Python, Go, .NET, Java, YAML, and HCL.”
   • [community] “Using Pulumi for about 1 year to manage gcp and AWS environments (5+) - each deployment is around 500 resources. At the begining it was bugg…”
   • [community] “We've now got the same stack structure going with Pulumi and Digital Ocean, having the same ease of development with at least 60% cost reduc…”
   • [community] “We switched to Pulumi from terraform for a new project because we can use it for both cloud infrastructure and for k8s configuration.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”

   proof ↗⚑ flag

   OpenTofu✓fullcommunity9/10

   OpenTofu explicitly claims a large provider/module ecosystem (3,900+ providers, 23,600+ modules) covering every major cloud, and being Terraform-compatible means it inherits the entire Terraform provider registry ecosystem; community evidence corroborates drop-in compatibility and easy migration. Missing for 10: independent third-party audit of provider parity/coverage beyond vendor-stated numbers.

   • [claimed-docs] “With a thriving ecosystem of 3,900+ providers and 23,600+ modules, you can build and manage infrastructure across every cloud platform with …”
   • [claimed-docs] “With a thriving ecosystem of **3,900+ providers** and **23,600+ modules**, you can build and manage infrastructure across every cloud platfo…”
   • [claimed-docs] “It serves as a drop-in replacement for Terraform, preserving your existing workflows and configurations.”
   • [community] “Fortunately using OpenTofu is just s/terraform/opentofu/g at this point.”
   • [community] “The move towards OpenTofu is going to be a slow tide, but it is coming. It's an easy migration... We made the jump for one client, started a…”

   proof ↗⚑ flag

Config stacks

1. developerManage per-environment configuration (dev, staging, prod) as separate stacks or workspaces

   weight 2 · round to Pulumi
   Pulumi✓fullprobed7/10

   Pulumi's core primitive of "stacks" is confirmed hands-on (pulumi stack init dev, pulumi preview/up/destroy per stack) and state/config is backend-scoped per stack (pulumi-docs-4/14/23, pulumi-probe-6/7), which is exactly the mechanism developers use to separate dev/staging/prod environments. Missing for 10: explicit documentation citation showing pulumi config set per-stack values and a documented dev→staging→prod promotion workflow, and no independent community confirmation specifically about multi-stack environment management.

   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”

   proof ↗⚑ flag

   OpenTofu~partialclaimed5/10

   OpenTofu's docs explicitly mention using for_each to build 'multi-environment setups (dev/staging/prod)' via provider configuration generation, showing the product can model separate environments, and its drop-in Terraform compatibility implies inherited workspace/state-separation mechanisms. However, there is no direct documentation or probe evidence of a dedicated `tofu workspace` command, backend workspace isolation, or a 'stacks' feature being exercised, so the core mechanism developers would use for per-environment config isn't concretely demonstrated. Missing for 10: explicit `tofu workspace` command docs, evidence of stacks/state isolation per environment, and hands-on proof of switching environments.

   • [claimed-docs] “Dynamically generate provider configurations with for_each, eliminating repetitive code and improving maintainability. Perfect for multi-reg…”
   • [claimed-docs] “It serves as a drop-in replacement for Terraform, preserving your existing workflows and configurations.”
   • [claimed-docs] “It serves as a **drop-in replacement for Terraform**, preserving your existing workflows and configurations.”

   proof ↗⚑ flag

Secrets

1. developerPass secrets and sensitive configuration into deployments without exposing them in code or logs

   weight 3 · round drawn
   Pulumi~partialprobed5/10

   A hands-on probe confirms Pulumi encrypts stack secrets via PULUMI_CONFIG_PASSPHRASE and can run headlessly with encrypted state (pulumi-probe-7), which supports the ability to store sensitive config outside code. However, the evidence pack lacks first-party docs on the `pulumi config set --secret` workflow, secret providers (KMS/Vault), or log redaction behavior, and there is no independent confirmation of masking-in-CLI-output claims. Missing for 10: docs on secret config commands and secret providers, evidence of automatic log/output redaction, and independent (non-vendor) verification of secrets never leaking in logs.

   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”

   proof ↗⚑ flag

   OpenTofu~partialcommunity5/10

   OpenTofu supports encrypting state and plan files at rest (including AES-GCM configuration) so secrets don't leak in stored state/plan artifacts, and it is Terraform-compatible with variable-based configuration that supports sensitive input passing patterns. However, there is no direct documentation on marking variables as sensitive to suppress console/log output, no evidence of secret-manager integrations, and community commentary raises unresolved concerns about safety of checked-in encrypted state. missing for 10: explicit sensitive-variable/log-redaction documentation, secrets-manager/vault integration evidence, independent verification that logs never expose secret values.

   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend.”
   • [claimed-docs] “Configure AES-GCM encryption method”
   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend. In addition, you can also use en…”
   • [community] “I'm very excited for state encryption though! Wondering how safe it is to check an encrypted state file into a public GitHub repo.”

   proof ↗⚑ flag

Drift

1. platform-engineerDetect drift between my declared configuration and the actual cloud resources

   weight 3 · round to OpenTofu
   Pulumi~partialprobed6/10

   Pulumi's `pulumi preview` command computes a diff between declared program state and actual live resources, and this was verified hands-on (JSON steps output) without requiring cloud backend. State-and-backends docs also confirm Pulumi tracks resource state to compare against real infrastructure. However, the evidence never explicitly documents a dedicated `pulumi refresh` command or scheduled/automated drift-detection workflows (e.g. CI drift alerts), which are the more complete drift-detection story. missing for 10: explicit refresh command docs, automated/scheduled drift detection, independent community confirmation of drift-detection accuracy.

   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”
   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”

   proof ↗⚑ flag

   OpenTofu✓fullprobed8/10

   OpenTofu's `tofu plan` explicitly supports a refresh-only mode that updates state to reflect out-of-band changes without applying corrections, which is the canonical drift-detection workflow, and a hands-on probe confirms plan surfaces detected changes via -detailed-exitcode in a real run. Missing for 10: an explicit end-to-end hands-on test showing detection of an externally-modified resource (drift) specifically, and independent/community validation of drift detection accuracy.

   • [claimed-docs] “Refresh-only mode: creates a plan whose goal is only to update the OpenTofu state and any root module output values to match changes made to…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”

   proof ↗⚑ flag

State backends

1. platform-engineerStore state in a remote backend with locking so concurrent runs cannot corrupt it

   weight 3 · round to Pulumi
   Pulumi✓fullcommunity8/10

   Pulumi docs explicitly describe remote backends (Pulumi Cloud managed service, and DIY backends like S3/Azure Blob/GCS) for storing state, and Pulumi Cloud/state services are designed to provide locking to prevent concurrent-run corruption; community evidence corroborates Pulumi's own state service option. missing for 10: explicit documentation/citation of locking mechanics for DIY object-store backends and independent third-party verification of lock behavior under concurrent runs.

   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”
   • [community] “Pulumi maintains its own state service (with option of self management)... As a developer, I quite liked Pulumi resource model, documentatio…”

   proof ↗⚑ flag

   OpenTofu—none0/10

   The evidence pack covers plan/apply/destroy workflows and state encryption, but contains no mention of remote backends, state locking, or concurrent-run protection. Missing for 10: any documentation or probe evidence of remote backend configuration (e.g., S3/consul/etc.), locking mechanism, or verification that concurrent runs are prevented from corrupting state.

   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend.”
   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend. In addition, you can also use en…”

   proof ↗⚑ flag

2. devops-leadEncrypt state at rest so credentials and sensitive values are not readable in plaintext state files

   weight 2 · round to OpenTofu
   Pulumi✓fullprobed7/10

   Pulumi documents encrypted state backends and hands-on probe evidence confirms secrets are encrypted using PULUMI_CONFIG_PASSPHRASE even on a local file backend, verifying secret values are not stored in plaintext. Missing for 10: explicit documentation of KMS/cloud secrets-provider options for encrypting the whole state, independent third-party verification of encryption strength, and clarity on whether non-secret resource properties are also encrypted at rest.

   • [probe] “PROBE cli-apply (local run): on the local file backend, `pulumi up --non-interactive --yes --skip-preview` exited 0 and `pulumi destroy --no…”
   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”
   • [claimed-docs] “Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application ... in addition to simple object storage in AW…”

   proof ↗⚑ flag

   OpenTofu✓fullcommunity9/10

   OpenTofu docs explicitly state built-in state and plan file encryption at rest, for both local and backend storage, with configurable methods like AES-GCM, directly addressing the story. Community sentiment even highlights excitement specifically about this state encryption feature, though the same commenter raises open questions about best practices for encrypted state handling (not a contradiction of the capability itself). missing for 10: independent hands-on verification/probe of the encryption feature actually working (only docs cited, no probe test like the plan/apply probes).

   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend.”
   • [claimed-docs] “Configure AES-GCM encryption method”
   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend. In addition, you can also use en…”
   • [community] “I'm very excited for state encryption though! Wondering how safe it is to check an encrypted state file into a public GitHub repo.”

   proof ↗⚑ flag

3. platform-engineerSafely inspect and modify state — moving, removing, or renaming resources — when refactoring

   weight 2 · round to Pulumi
   Pulumi~partialclaimed5/10

   Pulumi's docs show related state-safety capabilities — `pulumi import`/adoption for bringing existing resources under management (pulumi-docs-6,17,25), and `pulumi preview` for safely previewing changes without applying them (pulumi-docs-8,19,21) — plus general state backend concepts (pulumi-docs-4,14,23). However, the evidence pack never cites the actual `pulumi state mv`, `pulumi state rename`, or `pulumi state delete` commands that platform engineers use specifically for refactoring (moving/renaming/removing resources in state), so the core of the story is only indirectly supported. missing for 10: explicit documentation/evidence of `pulumi state move`, `pulumi state rename`, and `pulumi state delete` commands, plus hands-on confirmation these work safely during refactors.

   • [claimed-docs] “Adopting the existing resource to bring it under management by Pulumi... is called adoption or import.”
   • [claimed-docs] “Most infrastructure as code projects require working with existing cloud resources, whether those resources were originally created with ano…”
   • [claimed-docs] “you run `pulumi import` against a specific cloud resource. Pulumi adds the resource to your stack’s state and generates the code needed to m…”
   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [claimed-docs] “run `pulumi preview --import-file` to generate an import file listing every resource the program would otherwise create”
   • [claimed-docs] “Pulumi supports two classes of state backend: Pulumi Cloud... DIY backend: a “Do It Yourself” backend that stores state in an object store y…”
   • [claimed-docs] “Pulumi supports two classes of state backend: **Pulumi Cloud**: a managed backend...**DIY backend**: a “Do It Yourself” backend that stores …”

   proof ↗⚑ flag

   OpenTofu~partialclaimed3/10

   The evidence pack shows related state-adjacent capabilities—`tofu import` for bringing existing resources into state, refresh-only mode for reconciling state with real infrastructure, and state encryption—but never documents the actual state-surgery commands (e.g., `tofu state mv`, `tofu state rm`, `moved` blocks) that platform engineers use for refactoring resource addresses. Missing for 10: explicit docs/examples of `state mv`/`state rm`/`moved` block workflows, safety guardrails (backups, dry-run) during state edits, and any hands-on/independent confirmation these operations work reliably.

   • [claimed-docs] “Refresh-only mode: creates a plan whose goal is only to update the OpenTofu state and any root module output values to match changes made to…”
   • [claimed-docs] “The `tofu import` command imports existing resources into OpenTofu.”
   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend.”

   proof ↗⚑ flag

Testing

1. developerWrite automated tests for my infrastructure code and run them without touching production

   weight 2 · round to Pulumi
   Pulumi✓fullprobed8/10

   Pulumi documents a dedicated testing framework with Unit Tests (mocked, no real cloud calls), Property Tests, and Integration Tests using standard language test frameworks, plus 'pulumi preview' to check changes without touching production and Automation API for programmatic test orchestration. This directly satisfies writing/running infra tests without touching production. Missing for 10: independent hands-on validation of the testing framework specifically (probes verify preview/up/destroy but not the unit-test mocking flow) and community commentary on test-writing experience.

   • [claimed-docs] “Unit Tests are fast in-memory tests that mock all external calls. Property Tests run resource-level assertions while infrastructure is being…”
   • [claimed-docs] “Unit Tests are fast in-memory tests that mock all external calls.”
   • [claimed-docs] “Unit tests are authored in the same language as the Pulumi program under test. You can use your favorite test and mock frameworks like Mocha…”
   • [claimed-docs] “Show a preview of updates to a stack’s resources... No changes to the stack will actually take place.”
   • [claimed-docs] “Show a preview of updates to a stack’s resources.”
   • [claimed-docs] “The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI.”
   • [probe] “PROBE cli-preview (local run, macOS, pulumi v3.261.0): with a file:// local backend (`pulumi login --local`, no cloud account), `pulumi stac…”

   proof ↗⚑ flag

   OpenTofu~partialclaimed6/10

   OpenTofu ships a native `tofu test` command that creates real infrastructure, checks assertions, then destroys it — directly enabling automated infra tests without touching production, and `tofu plan` speculative plans support pre-review verification. Evidence is first-party docs only with no independent/hands-on corroboration of the test framework's mocking or unit-test capabilities. missing for 10: independent/hands-on validation of `tofu test`, details on mock providers or isolated test environments, community confirmation of test workflow reliability.

   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”
   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”
   • [claimed-docs] “developers can use speculative plans to verify the effect of their changes before submitting them for code review”
   • [claimed-docs] “This ensures that `.tofu` files always take precedence over `.tf` files when both are available. This scenario can be useful for module auth…”

   proof ↗⚑ flag

2. developerValidate and auto-format my configuration before planning

   weight 1 · round drawn
   Pulumi—none0/10

   No evidence of a dedicated 'pulumi validate' or 'pulumi fmt' style command that checks/auto-formats configuration prior to planning; Pulumi's docs only show 'pulumi preview' as a plan-preview step, and formatting is left to standard language tooling since Pulumi programs are written in general-purpose languages. missing for 10: no documented config validation command, no auto-formatting feature, no evidence of pre-plan syntax/config linting distinct from preview.

   ⚑ flag

   OpenTofu—none0/10

   The evidence pack covers plan, apply, test, import, and encryption commands but contains no mention of `tofu validate` or `tofu fmt` (or any auto-formatting/validation capability), so there is no evidence supporting this specific story despite the axis clearly applying to a Terraform-compatible IaC CLI. Missing for 10: any doc or probe evidence of a validate command, a fmt/auto-format command, or their integration into a pre-plan workflow.

   ⚑ flag