Infrastructure-as-Code tooling has a long-running output problem: the CLI is designed for humans, but the automation around it wants structured events. For years, the best you could do was pick one of two bad options:
- Parse human output (fragile, version-dependent, error-prone).
- Use JSON-only mode (stable, but destroys the human-readable UX and forces you to rebuild common summaries).
OpenTofu’s latest nightly builds introduce a third option: -json-into. It keeps stdout/stderr in the familiar human format while streaming machine-readable events into a file or pipe you control. That’s the kind of tiny flag that ends up changing a lot of downstream tooling.
What -json-into actually does
In OpenTofu, many long-running commands support -json. That switches the output mode entirely into a documented event format. Great for tooling; annoying for humans.
-json-into is the compromise that should have existed all along:
- Humans still see the normal plan/apply output (including the summary lines they rely on).
- Automation gets an appendable stream of JSON events that can be parsed reliably.
- Tool authors don’t have to maintain regex-based parsers or fight UX regressions.
Example workflow from the OpenTofu blog: run tofu plan -json-into=plan.json, then use jq to generate your own summary of planned changes. The key point is that this summary can be tailored for a CI system or policy workflow, without removing the default CLI output developers expect.
Why this matters for platform engineering
Platform teams don’t just “run tofu” anymore. They wrap it in:
- Pull request automation (drift checks, speculative plans, comment bots).
- Policy engines (OPA/Conftest, Sentinel-like guardrails, custom rules).
- Security controls (credential scanning, secret detection, approval gates).
- Observability (tracking change volume, high-risk resources, cost deltas).
All of those workflows benefit from event streams. But developers still want the CLI to feel like a CLI. Dual-stream output is a DX improvement that also improves correctness: structured events reduce mis-parses that can lead to incorrect policy outcomes.
Concrete use cases you can implement quickly
1) PR comments that are actually useful
Instead of dumping thousands of lines into a GitHub check, you can parse events and emit a PR summary:
- Top 10 resources created/changed/destroyed
- Any IAM/network perimeter changes highlighted
- Cost-impact resources detected (heuristics)
2) Policy as a first-class pipeline stage
Because the JSON stream is versioned and documented, policy checks can target stable fields. That’s vastly better than screen-scraping.
3) Auditable change telemetry
Ship selected JSON events into a logging system (or attach them as CI artifacts). You’ll be able to answer questions like: “Which repo produces the most destructive changes?” or “Which teams are constantly churning security groups?”
Operational considerations
- Nightly availability: today it’s in nightly builds. Plan for adoption once it lands in a stable release.
- Artifact hygiene: JSON streams can get large; rotate artifacts and store summaries, not everything.
- Redaction: ensure your event stream handling does not leak sensitive values into logs or PR comments.
Why OpenTofu is leaning into this
The OpenTofu ecosystem is built around open tooling and integrations. A dual-output stream is a classic example of designing for downstream developers: it makes “wrappers” and “platform products” easier to build without constantly breaking when the CLI output changes.
In the long run, expect better third-party tooling (formatters, plan reviewers, drift dashboards) built on the machine-readable stream—while keeping the CLI friendly for day-to-day work.
Leave a Reply