Rank #2 of 4 in Infrastructure as Code
Access
Install
brew install opentofuShowcase


Try itExperimental
See what an agent can do with OpenTofu before you ever sign up. Pick a story: recorded sessions replay real probe-harness transcripts; sandboxed self-drive sessions are designed and gated (docs/TRY-IT.md).
$tofu versionrecorded session — replayed, not liveVerified integrations
Connections to other tracked products — hover a chip for the verbatim evidence quote behind it.
By theme — the product's score on each story themeBy theme
Agenticness — how well agents can access and operate the productAgenticnessevidence →
How well agents can access and operate the product
Automation depth — how much of the product can run unattendedAutomation depthevidence →
How much of the product can run unattended
Import migration — stories about import migration in this arenaImport migrationevidence →
Stories about import migration in this arena
Licensing governance — stories about licensing governance in this arenaLicensing governanceevidence →
Stories about licensing governance in this arena
Openness — open source, data portability, and self-hosting storiesOpennessevidence →
Open source, data portability, and self-hosting stories
Plan apply — the plan/apply loop — previewing infrastructure changes and applying them safelyPlan applyevidence →
The plan/apply loop — previewing infrastructure changes and applying them safely
Policy as code — stories about policy as code in this arenaPolicy as codeevidence →
Stories about policy as code in this arena
Privacy posture — data-handling and privacy storiesPrivacy postureevidence →
Data-handling and privacy stories
Providers modules — stories about providers modules in this arenaProviders modulesevidence →
Stories about providers modules in this arena
Secrets config — stories about secrets config in this arenaSecrets configevidence →
Stories about secrets config in this arena
State management — stories about state management in this arenaState managementevidence →
Stories about state management in this arena
Testing validation — stories about testing validation in this arenaTesting validationevidence →
Stories about testing validation in this arena
Story verdicts — every judged story with its evidenceStory verdicts
Follow the green: where the map greys out is where OpenTofu stops today. ✓ full · ~ partial · ! disputed · — none · n/a not applicable.
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
API surface
Drive the product through a documented public API
~5/10
unlocks → Official SDKs · Machine-readable spec · Versioning policy
Subscribe to events via webhooks
n/an/a
Build against official SDKs
—0/10
Issue scoped/least-privilege API credentials for an agent
n/an/a
Connect an agent via an official MCP server
n/an/a
Download a machine-readable API spec (OpenAPI or equivalent)
—0/10
Rely on versioned APIs with a documented deprecation policy
—0/10
Test against a sandbox environment without touching production data
~5/10
Explore an interactive API reference with runnable examples
—0/10
Docs for agents
Point an agent at llms.txt or agent-oriented docs
—0/10
Agentic features
Delegate tasks to a built-in AI assistant inside the product
n/an/a
Operate the product with natural-language commands
—0/10
Plug MCP servers into this product so it can use their tools
n/an/a
Get AI-generated insights and suggestions from my data inside the product
n/an/a
Set up automations that run autonomously in the background
~4/10
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
Import migration — stories about import migration in this arenaImport migration
Stories about import migration in this arena
Licensing governance — stories about licensing governance in this arenaLicensing governance
Stories about licensing governance in this arena
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
Plan apply — the plan/apply loop — previewing infrastructure changes and applying them safelyPlan apply
The plan/apply loop — previewing infrastructure changes and applying them safely
Get machine-readable plan output (JSON) that an agent can parse to reason about a proposed change
✓9/10
Have an agent author an infrastructure change, run a plan headlessly, and present the diff for my approval
✓8/10
Drive deployments programmatically from my own application code rather than only through the CLI
—0/10
Plan workflow
Policy as code — stories about policy as code in this arenaPolicy as code
Stories about policy as code in this arena
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
Providers modules — stories about providers modules in this arenaProviders modules
Stories about providers modules in this arena
Generate infrastructure code from natural language using AI assistance built into the toolchain
n/an/a
Define infrastructure in a general-purpose programming language with types, loops, and IDE support
—–
Consume and publish reusable modules or components from a public registry
~6/10
Manage resources across all major clouds and SaaS providers through a broad provider ecosystem
✓9/10
Secrets config — stories about secrets config in this arenaSecrets config
Stories about secrets config in this arena
State management — stories about state management in this arenaState management
Stories about state management in this arena
Testing validation — stories about testing validation in this arenaTesting validation
Stories about testing validation in this arena
Sorted by importance (agentic first) (high → low) · 54/54 stories · click a row’s chevron for the rationale and evidence
Drive the product through a documented public API G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | partial | 5/10 | Tprobed | |
Connect an agent via an official MCP server G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | n/a | untested | none yet | |
Delegate tasks to a built-in AI assistant inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | n/a | untested | none yet | |
Plug MCP servers into this product so it can use their tools G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | n/a | untested | none yet | |
Run the product headlessly / in CI for automation G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 9/10 | Tprobed | |
Use an official CLI G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 9/10 | Tprobed | |
Set up automations that run autonomously in the background G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 4/10 | Tprobed | |
Build against official SDKs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Download a machine-readable API spec (OpenAPI or equivalent) G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Explore an interactive API reference with runnable examples G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Operate the product with natural-language commands G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Point an agent at llms.txt or agent-oriented docs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Rely on versioned APIs with a documented deprecation policy G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Get AI-generated insights and suggestions from my data inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | n/a | untested | none yet | |
Issue scoped/least-privilege API credentials for an agent G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | n/a | untested | none yet | |
Subscribe to events via webhooks G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | n/a | untested | none yet | |
Test against a sandbox environment without touching production data G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 1 | partial | 5/10 | Tprobed | |
Get machine-readable plan output (JSON) that an agent can parse to reason about a proposed change C Agent plan parsing | ai-native user | Plan apply — the plan/apply loop — previewing infrastructure changes and applying them safelyPlan apply | 3 | full | 9/10 | Tprobed | |
Manage resources across all major clouds and SaaS providers through a broad provider ecosystem C Providers | developer | Providers modules — stories about providers modules in this arenaProviders modules | 3 | full | 9/10 | Xcommunity | |
Preview exactly what will change — creates, updates, and destroys — before applying C Plan workflow | platform-engineer | Plan apply — the plan/apply loop — previewing infrastructure changes and applying them safelyPlan apply | 3 | full | 9/10 | Tprobed | |
Run plan and apply non-interactively in CI using saved plan artifacts and approval flags C Plan workflow | devops-lead | Plan apply — the plan/apply loop — previewing infrastructure changes and applying them safelyPlan apply | 3 | full | 9/10 | Tprobed | |
Detect drift between my declared configuration and the actual cloud resources C Drift | platform-engineer | State management — stories about state management in this arenaState management | 3 | full | 8/10 | Tprobed | |
Have an agent author an infrastructure change, run a plan headlessly, and present the diff for my approval C Ai infra ops | ai-native user | Plan apply — the plan/apply loop — previewing infrastructure changes and applying them safelyPlan apply | 3 | full | 8/10 | Tprobed | |
Self-host the core product G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | full | 8/10 | Tprobed | |
Rely on an open license and open governance so the tool cannot be relicensed out from under my company G Licensing | devops-lead | Licensing governance — stories about licensing governance in this arenaLicensing governance | 3 | full | 7/10 | Xcommunity | |
Consume and publish reusable modules or components from a public registry C Modules | developer | Providers modules — stories about providers modules in this arenaProviders modules | 3 | partial | 6/10 | Cclaimed | |
Export all of my data in open formats and leave G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | partial | 6/10 | Tprobed | |
Import existing cloud resources under management and generate matching configuration code G Import | platform-engineer | Import migration — stories about import migration in this arenaImport migration | 3 | partial | 6/10 | Xcommunity | |
Pass secrets and sensitive configuration into deployments without exposing them in code or logs C Secrets | developer | Secrets config — stories about secrets config in this arenaSecrets config | 3 | partial | 5/10 | Xcommunity | |
Enforce policy-as-code checks that block non-compliant infrastructure changes before apply C Policy | devops-lead | Policy as code — stories about policy as code in this arenaPolicy as code | 3 | none | 0/10 | ||
Store state in a remote backend with locking so concurrent runs cannot corrupt it C State backends | platform-engineer | State management — stories about state management in this arenaState management | 3 | none | 0/10 | ||
Define rules that trigger actions automatically on events G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 3 | none | untested | none yet | |
Prevent my data from being used to train AI models G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 3 | n/a | untested | none yet | |
Encrypt state at rest so credentials and sensitive values are not readable in plaintext state files C State backends | devops-lead | State management — stories about state management in this arenaState management | 2 | full | 9/10 | Xcommunity | |
Tear down an entire environment cleanly with a destroy operation C Plan workflow | developer | Plan apply — the plan/apply loop — previewing infrastructure changes and applying them safelyPlan apply | 2 | full | 9/10 | Tprobed | |
Read the product's source under an open license G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | full | 8/10 | Xcommunity | |
Migrate an existing Terraform-format codebase and its state into this tool C Migration | platform-engineer | Import migration — stories about import migration in this arenaImport migration | 2 | full | 7/10 | Tprobed | |
Perform bulk operations across many items at once G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | partial | 6/10 | Cclaimed | |
Write automated tests for my infrastructure code and run them without touching production C Testing | developer | Testing validation — stories about testing validation in this arenaTesting validation | 2 | partial | 6/10 | Cclaimed | |
Manage per-environment configuration (dev, staging, prod) as separate stacks or workspaces C Config stacks | developer | Secrets config — stories about secrets config in this arenaSecrets config | 2 | partial | 5/10 | Cclaimed | |
Rely on documented compatibility promises and upgrade guides between releases C Stability | developer | Licensing governance — stories about licensing governance in this arenaLicensing governance | 2 | partial | 5/10 | Xcommunity | |
Let an agent plan and apply with least-privilege credentials and review gates so it cannot make unapproved changes C Ai infra ops | ai-native user | Policy as code — stories about policy as code in this arenaPolicy as code | 2 | partial | 4/10 | Tprobed | |
Safely inspect and modify state — moving, removing, or renaming resources — when refactoring C State backends | platform-engineer | State management — stories about state management in this arenaState management | 2 | partial | 3/10 | Cclaimed | |
Do everything through the API that I can do in the UI G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | n/a | 0/10 | ||
Drive deployments programmatically from my own application code rather than only through the CLI G Automation api | developer | Plan apply — the plan/apply loop — previewing infrastructure changes and applying them safelyPlan apply | 2 | none | 0/10 | ||
Choose where my data is stored (region/residency) G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | untested | none yet | |
Control data retention and deletion G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | n/a | untested | none yet | |
Define infrastructure in a general-purpose programming language with types, loops, and IDE support C Languages | developer | Providers modules — stories about providers modules in this arenaProviders modules | 2 | none | untested | none yet | |
Generate infrastructure code from natural language using AI assistance built into the toolchain C Ai authoring | ai-native user | Providers modules — stories about providers modules in this arenaProviders modules | 2 | n/a | untested | none yet | |
Opt out of telemetry and usage tracking G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | untested | none yet | |
Schedule recurring jobs or workflows G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | n/a | untested | none yet | |
Target or exclude specific resources in a plan or apply C Plan workflow | platform-engineer | Plan apply — the plan/apply loop — previewing infrastructure changes and applying them safelyPlan apply | 1 | full | 8/10 | Tprobed | |
Version, review, and roll back my automations G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 1 | partial | 5/10 | Tprobed | |
Validate and auto-format my configuration before planning C Testing | developer | Testing validation — stories about testing validation in this arenaTesting validation | 1 | none | untested | none yet |
Opportunities — the stories that would move this product's scores, from its own judged verdictsOpportunitiestop 8 of 28 stories with headroom
What would move OpenTofu’s scores — derived from its own judged verdicts, biggest headroom first. Each line quotes what the judge found missing; shipping it (or evidencing it publicly) is the fix.
Automation depth — how much of the product can run unattendedDefine rules that trigger actions automatically on events
nonemoves PA Scoreimpact 30
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.
Policy as code — stories about policy as code in this arenaEnforce policy-as-code checks that block non-compliant infrastructure changes before apply
nonemoves PA Scoreimpact 30
Missing: 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.
State management — stories about state management in this arenaStore state in a remote backend with locking so concurrent runs cannot corrupt it
nonemoves PA Scoreimpact 30
Missing: 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.
Agenticness — how well agents can access and operate the productPoint an agent at llms.txt or agent-oriented docs
nonemoves agent-readyimpact 30
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.
Agenticness — how well agents can access and operate the productOperate the product with natural-language commands
nonemoves Built-in AIimpact 30
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.
Agenticness — how well agents can access and operate the productBuild against official SDKs
nonemoves agent-readyimpact 30
Missing: any documented official SDK, API/OpenAPI spec, or programmatic library for AI agents to integrate with OpenTofu beyond the CLI.
Agenticness — how well agents can access and operate the productExplore an interactive API reference with runnable examples
nonemoves API qualityimpact 30
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.
Agenticness — how well agents can access and operate the productDownload a machine-readable API spec (OpenAPI or equivalent)
nonemoves API qualityimpact 30
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.
Showing the top 8 of 28 — every none/partial verdict in the story verdicts table is headroom.
Think a verdict is wrong? Every verdicts-table row has a Flag link — see the methodology.
Coverage map — which docs area, API section, or community source covers which judged storiesCoverage map7 surfaces · 29 covered stories
Where the cited evidence behind each covered verdict came from — the same citations the verdicts table shows, no extra judging.
docs22 stories
- Run the product headlessly / in CI for automation
- Use an official CLI
- Drive the product through a documented public API
- Set up automations that run autonomously in the background
- Test against a sandbox environment without touching production data
- Version, review, and roll back my automations
- Import existing cloud resources under management and generate matching configuration code
- Migrate an existing Terraform-format codebase and its state into this tool
- Export all of my data in open formats and leave
- Self-host the core product
- Get machine-readable plan output (JSON) that an agent can parse to reason about a proposed change
- Have an agent author an infrastructure change, run a plan headlessly, and present the diff for my approval
- Tear down an entire environment cleanly with a destroy operation
- Run plan and apply non-interactively in CI using saved plan artifacts and approval flags
- Preview exactly what will change — creates, updates, and destroys — before applying
- Target or exclude specific resources in a plan or apply
- Let an agent plan and apply with least-privilege credentials and review gates so it cannot make unapproved changes
- Pass secrets and sensitive configuration into deployments without exposing them in code or logs
- Detect drift between my declared configuration and the actual cloud resources
- Encrypt state at rest so credentials and sensitive values are not readable in plaintext state files
- Safely inspect and modify state — moving, removing, or renaming resources — when refactoring
- Write automated tests for my infrastructure code and run them without touching production
opentofu.org11 stories
- Test against a sandbox environment without touching production data
- Perform bulk operations across many items at once
- Version, review, and roll back my automations
- Migrate an existing Terraform-format codebase and its state into this tool
- Rely on documented compatibility promises and upgrade guides between releases
- Target or exclude specific resources in a plan or apply
- Consume and publish reusable modules or components from a public registry
- Manage resources across all major clouds and SaaS providers through a broad provider ecosystem
- Manage per-environment configuration (dev, staging, prod) as separate stacks or workspaces
- Pass secrets and sensitive configuration into deployments without exposing them in code or logs
- Encrypt state at rest so credentials and sensitive values are not readable in plaintext state files
Hacker News9 stories
- Import existing cloud resources under management and generate matching configuration code
- Migrate an existing Terraform-format codebase and its state into this tool
- Rely on an open license and open governance so the tool cannot be relicensed out from under my company
- Rely on documented compatibility promises and upgrade guides between releases
- Export all of my data in open formats and leave
- Read the product's source under an open license
- Manage resources across all major clouds and SaaS providers through a broad provider ecosystem
- Pass secrets and sensitive configuration into deployments without exposing them in code or logs
- Encrypt state at rest so credentials and sensitive values are not readable in plaintext state files
Manifesto docs6 stories
- Migrate an existing Terraform-format codebase and its state into this tool
- Rely on an open license and open governance so the tool cannot be relicensed out from under my company
- Rely on documented compatibility promises and upgrade guides between releases
- Export all of my data in open formats and leave
- Read the product's source under an open license
- Self-host the core product
llms.txt2 stories
GitHub README2 stories
Probe proofs — replayable recordings from the probe harnessProbe proofs
Replayable recordings from our probe harness — see the Prove-It protocol to submit one.
$tofu versionreproduced$ tofu version OpenTofu v1.12.6 on darwin_arm64
$tofu plan -helpreproduced$ tofu plan -help
Usage: tofu [global options] plan [options]
Generates a speculative execution plan, showing what actions OpenTofu would
take to apply the current configuration. This command will not actually
perform the planned actions.
You can optionally save the plan to a file, which you can then pass to the
"apply" command to perform exactly the actions described in the plan.
Plan Customization Options:
The following options customize how OpenTofu will produce its plan. You can
also use these options when you run "tofu apply" without passing it a saved
plan, in order to plan and apply in a single command.
-destroy Select the "destroy" planning mode, which creates a
plan to destroy all objects currently managed by this
OpenTofu configuration instead of the usual behavior.
-refresh-only Select the "refresh only" planning mode, which checks
whether remote objects still match the outcome of the
most recent OpenTofu apply but does not propose any
actions to undo any changes made outside of OpenTofu.
-refresh=false Skip checking for external changes to remote objects
while creating the plan. This can potentially make
planning faster, but at the expense of possibly
planning against a stale record of the remote system
state.
-replace=resource Force replacement of a particular resource instance
using its resource address. If the plan would've
otherwise produced an update or no-op action for this
instance, OpenTofu will plan to replace it instead.
You can use this option multiple times to replace
more than one object.
-target=resource Limit the planning operation to only the given
module, resource, or resource instance and all of its
dependencies. You can use this option multiple times
to include more than one object. This is for
exceptional use only. Cannot be used alongside the
-exclude option.
-target-file=filename Similar to -target, but specifies zero or more
resource addresses from a file.
-exclude=resource Limit the planning operation to not operate on the
given module, resource, or resource instance and all
of the resources and modules that depend on it. You
can use this option multiple times to exclude more
than one object. This is for exceptional use only.
Cannot be used together with the -target option.
-exclude-file=filename Similar to -exclude, but specifies zero or more
resource addresses from a file.
-var 'foo=bar' Set a value for one of the input variables in the
root module of the configuration. Use this option
more than once to set more than one variable.
-var-file=filename Load variable values from the given file, in addition
to the default files terraform.tfvars and
*.auto.tfvars. Use this option more than once to
include more than one variables file.
Other Options:
-compact-warnings If OpenTofu produces any warnings that are not
accompanied by errors, shows them in a more
compact form that includes only the summary
messages.
-consolidate-warnings=false If OpenTofu produces any warnings, do not
attempt to consolidate similar messages. All
locations for all warnings will be listed.
-consolidate-errors If OpenTofu produces any errors, attempt to
consolidate similar messages into a single item.
-detailed-exitcode Return detailed exit codes when the command
exits. The detailed exit codes are:
0 - Succeeded but no changes proposed
1 - Planning failed with an error
2 - Succeeded and changes are proposed
-generate-config-out=path (Experimental) If import blocks are present in
configuration, instructs OpenTofu to generate
HCL for any imported resources not already
present. The configuration is written to a new
file at PATH, which must not already exist.
OpenTofu may still attempt to write
configuration if planning fails with an error.
-input=false Disable prompting for required input variables
that are not set some other way.
-lock=false Don't hold a state lock during the operation.
This is dangerous if others might concurrently
run commands against the same workspace.
-lock-timeout=duration Duration to retry a state lock, such as "5s"
to represent five seconds.
-no-color Disable virtual terminal escape sequences.
-concise Disable progress-related messages.
-out=path Write a plan file to the given path. This can be
used as input to the "apply" command.
-parallelism=n Limit the number of concurrent operations.
Defaults to 10.
-state=statefile A legacy option used for the local backend only.
Refer to the local backend's documentation for
more information.
-show-sensitive If specified, sensitive values will not be
redacted in te UI output.
-json Produce output in a machine-readable JSON
format, suitable for use in text editor
integrations and other automated systems.
-json-into=out.json Produce the same output as -json, but sent directly
to the given file. This allows automation to preserve
the original human-readable output streams, while
capturing more detailed logs for machine analysis.
-deprecation=module:m Specify what type of warnings are shown.
Accepted values for "m": all, local, none.
Default: all. When "all" is selected, OpenTofu
will show the deprecation warnings for all
modules. When "local" is selected, the warns
will be shown only for the modules that are
imported with a relative path. When "none" is
selected, all the deprecation warnings will be
dropped.
Claims vs evidence — vendor claims reconciled against independent verdictsClaims vs evidence
11 of 14 testable claims verified · 0 contradicted → integrity 79/100
18 distinct capability claims found in OpenTofu’s own claimed-docs/GitHub materials, reconciled against our judge’s independent verdicts.
11
Verified
3
Unverified
0
Contradicted
15
Undersold
Verified (13)
“Acts as a drop-in replacement for Terraform, keeping existing workflows and configs”
Migrate an existing Terraform-format codebase and its state into this toolfullproof ↗
“`tofu plan` generates an execution plan showing proposed infrastructure changes before applying”
Preview exactly what will change — creates, updates, and destroys — before applyingfullproof ↗
“Destroy mode creates a plan to tear down all managed remote objects, leaving an empty state”
Tear down an entire environment cleanly with a destroy operationfullproof ↗
“Refresh-only mode updates state/output values to match real-world changes made outside OpenTofu”
Detect drift between my declared configuration and the actual cloud resourcesfullproof ↗
“`tofu import` brings existing resources under OpenTofu management”
Import existing cloud resources under management and generate matching configuration codepartialproof ↗
“Supports encrypting state and plan files at rest, locally and in remote backends, using AES-GCM”
Encrypt state at rest so credentials and sensitive values are not readable in plaintext state filesfullproof ↗
“Encryption also extends to data read via the terraform_remote_state data source”
Encrypt state at rest so credentials and sensitive values are not readable in plaintext state filesfullproof ↗
“-exclude flag lets you selectively skip resources during plan/apply operations”
Target or exclude specific resources in a plan or applyfullproof ↗
“Ecosystem of 3,900+ providers and 23,600+ modules for managing infrastructure across clouds”
Manage resources across all major clouds and SaaS providers through a broad provider ecosystemfullproof ↗
“-out=FILE saves a generated plan to disk, which can later be applied via `tofu apply`”
Run plan and apply non-interactively in CI using saved plan artifacts and approval flagsfullproof ↗
“.tofu files take precedence over .tf files, letting modules support both OpenTofu and Terraform”
Migrate an existing Terraform-format codebase and its state into this toolfullproof ↗
“Backwards-compatible so existing code continues to work across versions”
Rely on documented compatibility promises and upgrade guides between releasespartialproof ↗
“As part of the Linux Foundation, OpenTofu guarantees it will remain truly open source”
Rely on an open license and open governance so the tool cannot be relicensed out from under my companyfullproof ↗
Unverified (3)
“`tofu test` runs configuration tests against real infrastructure, checking assertions then tearing it down”
Write automated tests for my infrastructure code and run them without touching productionpartialproof ↗
“Dynamically generate provider configurations with for_each for multi-region/multi-environment setups”
Manage per-environment configuration (dev, staging, prod) as separate stacks or workspacespartialproof ↗
“Centralized module version variables let you update all modules programmatically in one change”
Consume and publish reusable modules or components from a public registrypartialproof ↗
Undersold (15)
Run the product headlessly / in CI for automationfullproof ↗
Drive the product through a documented public APIpartialproof ↗
Set up automations that run autonomously in the backgroundpartialproof ↗
Test against a sandbox environment without touching production datapartialproof ↗
Perform bulk operations across many items at oncepartialproof ↗
Export all of my data in open formats and leavepartialproof ↗
Get machine-readable plan output (JSON) that an agent can parse to reason about a proposed changefullproof ↗
Have an agent author an infrastructure change, run a plan headlessly, and present the diff for my approvalfullproof ↗
Let an agent plan and apply with least-privilege credentials and review gates so it cannot make unapproved changespartialproof ↗
Pass secrets and sensitive configuration into deployments without exposing them in code or logspartialproof ↗
Safely inspect and modify state — moving, removing, or renaming resources — when refactoringpartialproof ↗
Claims outside our story set (2)
Real capability claims found in OpenTofu’s own materials, but no story in this arena’s taxonomy covers them yet — that’s feedback on the taxonomy, not a mark against the product.
“Speculative plans let developers verify change effects before submitting for code review”
source ↗“Builds a dependency graph and parallelizes creation/modification of non-dependent resources”
source ↗
Business model
MPL-2.0 open-source fork of Terraform under the Linux Foundation; no paid product — development is funded by supporting companies pledging engineering time.
pricing ↗Score trend
How this product’s scores have moved as evidence and verdicts are re-derived — a point per change, not per day.
Try Experimental
Run it in the microterminal →Recorded agent sessions — and a live MCP handshake where the vendor ships one.
Flag
⚑ Flag a verdictThink a verdict is wrong? Opens a prefilled GitHub issue — or use the ⚑ next to any verdict above.
For agents
