choudoufu

The OpenTofu fork from the team behind terragucci, set with binary: choudoufu.

Works

• One record per resource in an S3 bucket you own, each write conditional, with no lock table
• Applies to different resources of one estate run at the same time; a killed apply leaves nothing to release
• A live check on every push, and the slowest provider calls in the report

Differs

• terragucci does not read a root's required_version as a choudoufu release.
• Record history needs the ListBucketVersions permission on the record store bucket; a local or kubernetes record store keeps none.

First step

Choose your binary: choudoufu

Proof

choudoufu, on Forgejo

• Plan and review1provenPlan and review, choudoufu1 check, proven.
  • the generated workflow for a choudoufu estate fails a resource that live-check refuses and names it
  42 other checks run the same code on every binary and are not re-run here.
• Approve and apply6provenApprove and apply, choudoufu6 checks, all proven.
  • each wave goes out only once approved
  • with apply.when: pull-request, a comment on an open and approved pull request applies its head in waves and then merges it with apply.merge: auto
  • with binary: choudoufu a gated wave killed after its approved apply of one resource returned is found by terragucci resume, and the wave run again applies only the other resource under the same approval, with no new one
  3 more on the validation page.47 other checks run the same code on every binary and are not re-run here.
• Locks and safety9provenLocks and safety, choudoufu9 checks, all proven.
  • a plan that waits for a state lock another plan holds shows the wait as a State lock wait span, in its report and its trace
  • with binary: choudoufu two tf-apply waves of one estate that change different resources run at once, both reach their record write together and both apply, with no lock wait and no lock object
  • with binary: choudoufu two tf-apply waves of one estate, each adding a resource whose apply takes 60 seconds, finish both resources in under 90 seconds: the second wave starts while the first is applying and does not wait for it
  6 more on the validation page.27 other checks run the same code on every binary and are not re-run here.
• Policy2provenPolicy, choudoufu2 checks, all proven.
  • a tf-apply wave whose plan the policy denies applies nothing, and its report keeps the changes of the denied root with the denial and the warnings
  • with cost.approve_above set, a wave whose monthly change is over the amount waits for an approval under gate: never, its log naming the change, the amount and the commit read, and the plan note of a pull request sets the change of each wave against the amount at base
  14 other checks run the same code on every binary and are not re-run here.
• Drift2provenDrift, choudoufu2 checks, all proven.
  • with binary: choudoufu and the roots under live resource markers, drift is a config error: init and stage tf-drift exit 2 naming the roots, before any plan
  • with binary: choudoufu a queue changed outside choudoufu on a root under live resource markers is drift: tf-drift plans the root in full, its report and one drift issue name the root and the attribute, and a run with no change closes the issue
  9 other checks run the same code on every binary and are not re-run here.
• Chat and notify1provenChat and notify, choudoufu1 check, proven.
  • with notify naming a generic webhook and its key, a wave that waits posts a terragucci.notify/v1 event signed with HMAC-SHA256 over its body, carrying the outcome, digest and approve command
  5 other checks run the same code on every binary and are not re-run here.
• Reports and visibility8provenReports and visibility, choudoufu8 checks, all proven.
  • the report is JSON and HTML, and links every root to its full plan
  • with binary: choudoufu the report lists the slowest provider calls of a root, each with its method, provider and resource type, from the provider call spans choudoufu sends
  • with binary: choudoufu past its span budget the report lists the timings choudoufu summed by resource type, and the note of the root says it summed them
  5 more on the validation page.36 other checks run the same code on every binary and are not re-run here.
• Modulessame codeModules, choudoufuNot re-run on choudoufu. These 13 checks run the same code on every binary; on OpenTofu, 13 are proven.
  • a module version rolls out one pull request per wave
  • changed modules are published at a new version
  • with modules.attest each release is signed, attested and recorded in the release ledger with its tag
  10 more on the validation page.
• State and migration3provenState and migration, choudoufu3 checks, all proven.
  • with binary: choudoufu one tf-apply wave applies two estates into one record store bucket, each under its own prefix and estate tag, and the next plan of both shows no change
  • with binary: choudoufu a migration moves a resource between two estates by rewriting its ownership tags: proved by both plans, approved by digest, after which the next plan of both shows no change and the move is on chant/lifecycle
  • with binary: choudoufu a migration adopts a root on s3 state into an estate: proved against the live system, approved by digest, its resources stamped with no change, and its old state left as the version it was
  20 other checks run the same code on every binary and are not re-run here.
• Agents and pull request environmentssame codeAgents and pull request environments, choudoufuNot re-run on choudoufu. These 10 checks run the same code on every binary; on OpenTofu, 10 are proven.
  • a /terragucci agent comment pushes the commit of the stand-in agent to the branch of the pull request, which re-plans it and is linked in the reply, and a forbidden path, a non-writer and a fork push nothing
  • with review.agent on, the review workflow of the default branch runs on pull_request_target after the plan, and its review job runs a stand-in reviewer on the pull request, its plan and the instructions of the default branch, with the key of the model and no forge token, and the note it posts flags a destroy the description does not mention and approves nothing
  • with respond.description: check the plan job flags a destroy the pull request description leaves out, at the top of the note and in the report, and writes intent.json
  7 more on the validation page.
• Setup and runtime3provenSetup and runtime, choudoufu3 checks, all proven.
  • the example boots and deploys locally
  • with binary: choudoufu a role granted one estate by its ownership tag applies a change to that estate, and IAM refuses it a change to an instance of another estate
  • in a Terragrunt repo with binary: choudoufu the jobs run in the choudoufu image with Terragrunt installed beside it, and every unit plans with choudoufu through TG_TF_PATH
  38 other checks run the same code on every binary and are not re-run here.

• proven passes, and fails with the feature cut out
• same code not re-run on this binary; its checks run the same code on every binary

Every check runs on OpenTofu on Forgejo. Runs on Terraform, choudoufu and github.com are expensive, so they re-run only the checks where the binary or forge changes what happens.

Open a cell for the checks behind it. Recorded: example checks, last full run Oct 8, 2026; per-forge checks Oct 7 to Oct 9, 2026; github.com Oct 10, 2026.

You can count on

• A plan note on every pull request
• Gated applies of the plans you approved
• No overlapping or stale applies
• Re-plan from a comment
• Scheduled drift checks
• OIDC roles, one to plan, one to apply
• Policy on every plan
• An audit trail in your bucket
• Secrets kept out of notes and logs
• Your state backend, as is
• Your own runners
• Your forge's sign-in and permissions

Then read

Tasks

Choose your binaryWatch a choudoufu wave

Background

Locking with choudoufu

Details

Traces and metrics