Your terragrunt (or terraform) plan is 4,000 lines. Only two of them matter.

Ilya Rubinchik — Mon, 10 Aug 2026 21:18:23 +0000

You know the ritual.

terragrunt run --all -- plan

Then you scroll. Past forty units of Refreshing state…. Past the ninth
identical count instance. Past a tags_all.LastModified that changes on every
single run because your CI stamps a timestamp into it. Somewhere in there are
the two lines you actually needed to see — probably the # forces replacement
on a database.

You scroll back up. You lose it. You pipe it to a file and grep for must be replaced. You approve anyway, because it's 6pm.

I got tired of that, so I wrote tgsieve.

What it does

It runs the plan for you, reads the structured output instead of the prose,
throws away the noise you declared as noise, collapses everything that repeats,
and prints what's left.

DESTROY / REPLACE (1)
  envs/prod/a
    ± aws_db_instance.main
        engine_version  "14.7" → "15.3"   forces replacement

UPDATE (5)
  5 units  envs/dev/a, envs/dev/b, envs/prod/a, +2 more
    ~ null_resource.pin
        triggers.region  "eu-central-1" → "us-west-2"

SUMMARY  ±1 replace  ~5 update
  severity: 1 high, 5 medium
  hid 214 attributes across 3 rules (--explain to see them)

That's five units of a real terragrunt plan — the same run terraform prints as
several hundred lines.

The report nests three deep — where, then what, then which fields:

UPDATE (5)
  envs/prod/c                            ← the unit, said once
    ~ aws_s3_bucket.this                 ← the resource
        tags_all.entity  "tgb" → "tgc"   ← the attributes that changed

A change that's identical across units replaces the directory with the set it
covers, so the first column always answers the same question: where.

It doesn't scrape text

This matters, because the obvious implementation is fragile garbage.

You might reach for terragrunt run --all -- plan -json. It doesn't work:
terragrunt forwards terraform's own NDJSON straight through, so lines from units
running in parallel interleave with no way to tell them apart.

So tgsieve asks terragrunt for machine-readable artifacts and reads those:

What	Flag it passes	What it gets
per-unit plans	`--json-out-dir`	one `tfplan.json` per unit — the full `terraform show -json` document
live progress	`--log-format json`	NDJSON events tagged with `working-dir`, so failures surface the moment they happen
run report	`--report-file/--report-format json`	per-unit result and duration, including units that failed before producing a plan

From each plan it computes a real attribute-level diff — flattening
before/after/after_unknown into dotted paths, honouring replace_paths,
sensitivity, and unknown subtrees. No regexes over ~ resource "aws_...".

OpenTofu works too — terragrunt defaults to tofu, and --tf-path /
TG_TF_PATH picks explicitly.

Nothing is hidden until you say so

The whole tool is one .tgsieve.yaml, looked up from the working directory
upwards and merged, nearer files winning. tgsieve init writes a starter one.

version: 1

extends: [builtin/aws-tags]   # curated rule sets, opt-in

hide:
  unchanged_units: true   # units with nothing left to say become a count
  reads: true             # data sources resolved during apply: they create nothing

ignore:
  - name: tag churn
    attrs: ["tags.LastModified", "tags.git_commit", "tags_all.*"]

  - name: waiting on the provider fix
    type: aws_ecs_service
    attrs: ["capacity_provider_strategy.*"]
    expires: 2026-12-01     # after this date the rule stops hiding, loudly

  - name: dev is not interesting
    unit: "envs/dev/**"
    attrs: ["*"]

never_hide:
  actions: [delete, replace]

Three things I'd want to know before trusting a tool that hides my
infrastructure changes:

A resource only disappears when every one of its attributes was hidden. One survivor keeps the whole resource on screen.
An attribute that forces replacement is never hidden, whatever the rules say. Destroys and replacements can't be silenced by default either.
--explain shows every hidden attribute and the rule that hid it, and the footer always states how much was hidden. The counts count real resources, not rendered blocks.

Suppressions that expire

That expires: 2026-12-01 is my favourite line in the config. Past that date
the rule stops hiding anything and the report names it:

1 rule expired and no longer hides anything: waiting on the provider fix

It fails open, on purpose. A suppression that quietly outlives its reason is
exactly the failure this tool exists to prevent. So the lapse restores the
changes rather than silently continuing to swallow them.

The small readability things

These are the ones that made me realise how much terraform's renderer was
costing me.

Sets are compared by members, not positions. Terraform renders sets as
arrays, so a set that comes back in a different order looks like every index
changed at once. tgsieve says what actually happened:

input.cidrs  reordered (4 items, same members)

input.cidrs  - "10.0.2.0/24"
input.cidrs  + "10.0.9.0/24"

Objects inside a collection get matched by an identity field (id, name,
key, cidr_block, a few others) when every member carries one and it's
unique. So an edited security group rule reads as an edit:

ingress["web"].to_port  80 → 8080

rather than one object leaving and a nearly identical one arriving.

Long values are trimmed around the difference, not from the start. Two
values sharing a 200-character prefix would otherwise print that prefix twice
and hide the part that changed. A string that's itself a JSON document — an IAM
policy, say — is shown as that document rather than as an escaped string.

Repeated failures get counted, not repeated. A removed provider
configuration produces one diagnostic per orphaned resource, which terraform
prints as forty paragraphs. The count is the news:

FAILED (1)
  ✗ infra/networking  ×38
      Error: Provider configuration not present: To work with module.peering-… (orphan)

Same at stack level. One expired credential hits every unit; you get it once,
with the list:

FAILED (5)
  ✗ 5 units, same error
      envs/dev/a, envs/dev/b, envs/prod/a, +2 more
      Error: no valid credential sources found

Folding never drops where the problem is — diagnostics sharing a message but
naming different lines list those lines.

Drift is a finding, not work

Nothing in drift changes when you apply. So it's counted rather than listed, and
a plan whose only findings are drift reports what terraform reports — no
changes:

SUMMARY  no changes
  3 resources drifted outside terraform, none of them addressed by this plan (--drift to list)

--drift lists them, split by what the plan intends to do:

DRIFT — this plan puts it back (2)
DRIFT — this plan leaves it (1)

The second is the one that bites — an attribute under ignore_changes, or a
resource the config no longer governs, stays drifted after the apply. Drift
never trips --fail-on or --detailed-exitcode, because those describe what an
apply will do.

`tgsieve apply` applies the plan you reviewed

Not a fresh plan made after you answered.

tgsieve apply --all

apply 9 changes across 5 units? [yes/no] yes
4 resources will be destroyed or replaced — type 'destroy' to confirm: destroy

The second question only appears when something will be destroyed or replaced,
and it wants that word rather than another "yes" — those are the changes that
running the tool again won't undo. Outside a terminal it refuses rather than
assuming; --auto-approve is how you say you meant it in CI.

Review now, apply later:

tgsieve plan  --all --keep-plans ./plans --out-dir ./plans
tgsieve apply --all --plans ./plans

And when the apply finishes — or stops — the report says what terraform
actually did, which after a failure is the one question the plan can't answer:

APPLY FAILED
  stopped after 15m45s — the report above is what was planned, not what landed
  ✗ Error: updating EKS Node Group (…) config: operation error EKS
  terraform changed 4 resources · 1 did not finish · slowest first
    ✗ terraform/live/ctrl/tests/eks module.eks…aws_eks_node_group.this — modifying, did not finish after 15m2s
    ✓ terraform/live/ctrl/tests/eks aws_security_group_rule.node created in 3s
  run tgsieve plan to see where things actually stand

Living with a heavy stack

If your stack takes twenty minutes, you need more than a pretty report.

You can see what's happening. A window that updates in place instead of
scrolling:

  envs/prod/a  aws_db_instance.main     modifying… 1m12s
  envs/prod/b  aws_instance.web[3]      creating… 22s
  envs/dev/a   null_resource.deploy     done 4s
⠴ applying · 7/12 applied · 1m30s

The denominator comes from terragrunt find, so it's known before the first
unit starts. Outside a terminal it collapses to a heartbeat line every 30
seconds, so CI logs still show liveness.

Ctrl-C behaves. It forwards the interrupt so terraform can release its state
locks, prints the report for whatever finished, lists the rest under NOT RUN,
and exits 130.

--resume picks up where an interrupted run stopped:

tgsieve plan --all --keep-plans ./plans          # 40 units, Ctrl-C at 31
tgsieve plan --all --keep-plans ./plans --resume # runs the missing 9

Reusing a plan is only sound if the code hasn't moved under it, so a run records
the commit plus a fingerprint of uncommitted changes, and --resume refuses to
mix generations:

the plans in ./plans were made at 1cb275fd, the working tree is now at 4a91e0c2
  re-run without --resume to plan the stack fresh, or pass --force to mix generations

That check also covers where each unit's code comes from. A remote module
pinned to a branch — or to a tag someone can move — reads identically before and
after the code it names changes, so each remote ref gets resolved to a commit
with git ls-remote (one call per distinct repo+ref, not per unit;
--no-resolve-refs for air-gapped runs).

--fast skips the refresh, which on a heavy stack is the single biggest
speed-up available. The summary says so every time, because a plan that never
looked at reality can report "no changes" for a stack that has drifted:

state was not refreshed: anything changed outside terraform is invisible here

Plus: plan directories are locked while a run writes to them (--lock-wait 2m
for CI pipelines racing each other), and unit durations are remembered per
directory with a two-week TTL, so --timings stays meaningful across resumes.

In CI

--format decides the shape: tty (default), md, json or github.

Markdown for pull request comments — destructive changes stay open,
everything else folds into <details>, output is capped so GitHub doesn't
reject it, and every report starts with  so a bot can update
its own comment instead of adding a new one each run.

With Atlantis, a custom workflow:

workflows:
  tgsieve:
    plan:
      steps:
        - init
        - run: tgsieve plan --all --format md --fail-on high
    apply:
      steps:
        - run: tgsieve apply --all --auto-approve --format md

--fail-on high turns the plan step red only when something is destroyed or
replaced — a pipeline can stop for a replacement without stopping for a new log
group.

JSON is a versioned document with its own types, not the internals of the
sieve:

tgsieve plan --all --format json | jq -r '.changes[] | select(.action=="replace") | .address'

Sensitive values never appear in it — an attribute terraform marked sensitive is
reported as "sensitive": true with no before or after. A machine-readable
report is the easiest place for a secret to end up somewhere it shouldn't.

GitHub Actions annotations, so failures land on the diff rather than only in
the job log:

::error file=modules-vpcs.tf,line=72,title=infra/networking::Error: Unsupported attribute…

And the exit codes distinguish the three ways a run can be unhappy:

code	meaning
`0`	ran fine
`1`	tgsieve itself failed
`2`	changes survived the sieve (`--detailed-exitcode`, or `--fail-on` was met)
`3`	one or more units failed to plan
`130`	interrupted with Ctrl-C

No terragrunt? Still works

A root module big enough to be unreadable has the same problem as a stack, minus
the queue:

tgsieve plan  --engine terraform
tgsieve apply --engine terraform

Same rules, same collapsing, same formats. The flags that only mean something
with a queue behind them say so rather than being quietly ignored:

--all needs terragrunt: the terraform engine plans one root module

Try it

brew install imcitius/tap/tgsieve

go install github.com/imcitius/tgsieve@latest

Then, in a stack you already have:

tgsieve plan --all

No config needed to start — with an empty .tgsieve.yaml, nothing is hidden and
you still get the nesting, the collapsing, the folded failures and the honest
summary. Add rules once you've seen which noise is your noise:

tgsieve init            # starter config at the project root
tgsieve rules           # what config is in effect, and from where
tgsieve plan --all --explain   # every hidden attribute and the rule that hid it

It's MIT, written in Go, single binary, no daemon, no account.

👉 github.com/imcitius/tgsieve

I'd genuinely like to know what noise it doesn't catch on your stack — that's
the feedback that turns into the next preset. Issues, or just reply here.

DEV Community: Ilya Rubinchik