Documentation · Use it

Day-2 operations

Running an estate after the first apply: renaming and removing resources, recording effects the cloud cannot report, and working with other people.

Sharing values between estates

data "terraform_remote_state" is admitted, but a live root writes no state file, so it goes stale once the producer adopts markers. Reading a value from another estate has the pattern that stays current.

Plan, review, apply

plan -out=FILE writes stock’s own plan file, and apply FILE reads it as an approval rather than as an instruction. A live root keeps no prior state, so the apply never replays what the file describes. It re-reads the live system and plans against what is there now, then compares that fresh plan against the approved one, down to the values each change writes.

Where the two agree, the apply runs without asking again, because the file was the approval. Where they differ, nothing changes. The apply prints The approved plan no longer matches the live system with the rows that moved, and exits 3. That status is neither an ordinary failure nor -detailed-exitcode’s 2, so a pipeline can route the run back to review instead of paging somebody about a broken step. The way through is the two commands you already ran: plan over the world as it is now, approve that, then apply it.

Compatibility reference has what the two plans are compared on and which saved-plan invocations stay refused. Running an estate from CI has a pipeline built on it, gate and all.

#74 is the history here. It had chosen a plan fingerprint, a digest printed at plan time for the apply to check against its own fresh plan, and #878 shipped a comparison of the two plans instead, so that a refusal can name the address and the attribute that moved. Claim 15 is the runnable version, and the gauntlet’s plan_approval stage measures both halves of it on every estate: the matched file that applies and the moved world that refuses. See the stage table.