Terraform vendors sell plan and apply on pull requests, approvals, policy, drift checks and an audit trail, run on their servers with your cloud credentials. terragucci is those pipelines, ready to run in your own CI on GitHub, GitLab or Forgejo, with state and reports in your own bucket. There’s no account to create and no platform to log into, and it’s Apache-2.0.

choudoufu is optional. It’s OpenTofu that tags each resource with its owner, so the state file becomes a cache and locking goes per resource. It runs on AWS and Kubernetes under MPL-2.0, and since the cache is a stock state file, going back to stock is a copy.

What you’d pay a SaaS for

What you’d pay a Terraform SaaS for, and the terragucci page that does each one in your own CI

State and locking

State and locking, terragucci with stock Terraform or OpenTofu against terragucci with choudoufu

Sources at the end links every cell to its doc.

Kill an apply

kill -9 an apply right after it creates a VPC, then run it again. choudoufu tags the VPC in the create request, so the next plan finds it by that tag and the re-run binds it instead of building a second one. Stock Terraform and OpenTofu record the VPC only after the create call returns, so a kill in that window leaves one the re-run doesn’t know about. The ten types that take no tags at create keep that window under choudoufu too.

A plan that costs its change

plan -cone plans only the changed resources, what they depend on and what depends on them. It’s opt-in for pull requests and approved with the plan. A change that touches providers, the lock file or more than 30% of the estate gets a full plan instead.

A plan across state files

A root that reads another root’s state plans on that root’s planned outputs, so it’s checked against what the merge will build. This covers terraform_remote_state and Terragrunt dependency blocks. Between choudoufu estates it works the same way.

A value only known after the upstream applies, like a new network’s ID, can’t be planned. terragucci plans the reader again once its upstream has applied. choudoufu refuses to plan on it. A failed wave leaves the earlier waves applied and plans again on what’s there.

The detail

Each state and locking claim in full, for stock Terraform or OpenTofu and for choudoufu

Most rows are backed by a smoke claim named on the locking page. The glossary defines wave, root and forge.

Prove it to yourself with your own agent

Paste into a coding agent · read only · emulator only 
Read https://lex00.github.io/posts/tf-vendor-power-without-the-saas/

For each row of "What you'd pay a SaaS for", open the page listed for it under Sources and say whether it does what the row says.

For each row of "The detail", give three verdicts, each with a source link:

- terragucci: does the doc listed for it under Sources support the cell as written? Find the smoke claim behind it in https://github.com/INTENTIUS/terragucci (stack/smoke.sh, docs-site/src/data/smoke.json) and say whether its latest result passes.
- choudoufu: the same, in https://github.com/INTENTIUS/choudoufu (live/smoke/claims/).
- The industry, as of today: which Terraform state backends, TACOs and hosted Terraform platforms document the same capability? Quote their current docs and give the date you read them.

Mark a cell unverified when you can't find a source, rather than inferring one.

Then run the post's "Kill an apply" test if you have Docker: against a local AWS emulator, once with stock OpenTofu and once with choudoufu, and report how many VPCs exist after each re-run. Never run it against a real cloud account.

Read more

Sources

What you’d pay a SaaS for:

State and locking, and the detail: