# OpenTofu’s -json-into: Dual-Stream Output That Makes CI and Humans Happy

- Link: https://thestackobserver.com/opentofus-json-into-dual-stream-output-that-makes-ci-and-humans-happy/
- Published: 2026-02-12T08:16:54-05:00
- Author: Stackxx

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.

## Sources

 * [OpenTofu blog: Machine and Human readable command output streams](https://opentofu.org/blog/dual-command-output-streams/)
 * [OpenTofu docs: machine-readable UI format](https://opentofu.org/docs/internals/machine-readable-ui/)