Terraform Plan Viewer

Color-Coded Review vs. Other Plan-Reading Approaches

Terraform's raw terminal output already has color when run in an interactive shell, so the value of a dedicated viewer is really about the review context, not the coloring itself: CI logs, PR comments, and Slack pastes routinely strip ANSI color codes, leaving reviewers staring at plain text where a destructive -/+ replacement looks identical to a benign in-place ~ update. Pasting that same output into this viewer restores the visual distinction regardless of where the text came from. A more structured alternative is terraform show -json tfplan | jq, which exposes the plan as machine-readable JSON — better for scripting an automated policy check but considerably harder for a human to skim than colored text.

Terraform Cloud and Atlantis both render plans with their own web UI, complete with collapsible resource blocks and policy-check integration — a good option if your team already runs one of those platforms, but overkill for a quick one-off review of output someone pasted into a chat message. This tool sits in the gap between "raw pasted text" and "a hosted platform," useful specifically when you have plan output but not the infrastructure around it.

The Terminal Commands Behind the Curtain

Everything this viewer displays originates from a small set of Terraform CLI commands. terraform plan alone prints the human-readable summary this tool parses. Adding -out=tfplan saves that plan to a binary file so the exact reviewed plan can later be applied verbatim with terraform apply tfplan, avoiding drift between what was reviewed and what actually runs. For programmatic consumption, terraform show -json tfplan converts the same saved plan into structured JSON, which pairs naturally with jq for scripted checks — for instance, terraform show -json tfplan | jq '.resource_changes[] | select(.change.actions[0]=="delete")' lists every resource marked for destruction, useful as an automated pre-merge check that fails a PR if a protected resource type appears in that list. This viewer is a faster substitute for manually scanning the first form of output; it isn't a replacement for the second when you need the plan's structure to be machine-parseable.

Reading Plans When They're Thousands of Lines Long

A plan against a single-module stack might be fifty lines; a plan against a shared root module in a large monorepo touching hundreds of resources can run to tens of thousands of lines, and a human reviewer's ability to spot a stray deletion in that volume of text drops sharply past a few hundred lines regardless of color-coding. Two practical mitigations help at scale: scoping the plan itself with terraform plan -target=module.specific_service when you know exactly which module changed (used sparingly, since overuse causes state drift between targeted and full applies), and splitting a monolithic root module into smaller state files per service or environment so any single plan is naturally bounded in size. When a large plan can't be avoided, the stat bar this tool extracts from the "Plan: N to add, N to change, N to destroy" summary line becomes the first thing worth checking — a plan reporting 400 changes when you expected 4 is a stronger and faster signal that something is wrong than trying to read all 400 changes by eye.

Fixing Common Plan-Review Failures

If terraform plan reports "No changes" when you were expecting some, the most frequent cause is running the command from the wrong workspace or directory — check terraform workspace show and confirm you're pointed at the state file you think you are. If the plan shows unexpected changes to resources you didn't touch, suspect configuration drift: someone or something changed the resource outside of Terraform (a manual console edit, another pipeline, an auto-scaling event), and Terraform is now proposing to revert it back to match your configuration — run terraform plan -refresh-only first to see drift in isolation before deciding whether to accept it into state or update your config to match reality.

If a plan hangs indefinitely, check for a stale state lock from a previous run that crashed or was killed mid-apply — terraform force-unlock clears it, but only after confirming no other apply is genuinely in progress. Provider version mismatches between what a teammate has locally and what's pinned in required_providers are another common source of plans that look different than expected between two people running the exact same configuration — pin provider versions and commit the lock file to catch this before it causes confusion.

Frequently Asked Questions