Saved Plans: The Production Apply Pattern

A saved plan is the production apply pattern. The plan is written to a file, archived, and applied exactly as written. The audit trail is the saved plan. The review is the plan output. The apply is the saved plan.

This lesson teaches the saved plan pattern, the failure modes, and the production test.

The pattern

A saved plan is a two-step process:

# Step 1: Plan and save
terraform plan -out=production.tfplan

# Step 2: Apply the saved plan (later, possibly in CI)
terraform apply production.tfplan

The plan:

• Reads the configuration at the time of plan.
• Reads the state at the time of plan.
• Computes the diff.
• Writes the diff to the file.

The apply:

• Reads the saved plan file.
• Does NOT re-compute the diff.
• Executes the diff from the saved plan.

The saved plan is the contract between the engineer and the CI pipeline.

Why saved plans matter

A saved plan is the operational form of a code review:

• The plan was reviewed by a second engineer.
• The plan was approved.
• The apply is the saved plan.

Without a saved plan:

• The apply is computed at apply time.
• The plan may differ from the review.
• The review is not enforceable.

A saved plan is the production control.

The apply with a saved plan

terraform apply production.tfplan

The output:

aws_instance.web: Creating...
aws_instance.web: Still creating... [10s elapsed]
aws_instance.web: Creation complete after 25s [id=i-0abc123def456789]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

The apply does not show the plan. The apply executes the plan from the file.

What the saved plan contains

The saved plan file is a JSON document. The structure is documented in the Terraform internal docs. The key fields:

• format_version — the plan format version.
• terraform_version — the version that wrote the plan.
• resource_changes — the proposed changes per resource.
• configuration — the configuration root module.
• state — the state at the time of plan.

The saved plan is enough to reproduce the apply. The apply with the saved plan produces the same result as the apply without the saved plan (assuming the configuration and state are unchanged).

The apply without a saved plan

terraform apply

The apply computes the plan at apply time. The plan is displayed. The engineer approves the plan. The apply executes the plan.

This is the interactive form. It is appropriate for local development. It is not appropriate for production.

The failure mode

A saved plan fails if the configuration or state changes between the plan and the apply:

Error: Saved plan is no longer up to date

The given plan is no longer up to date. The plan was created
against a state that has since been modified, so it cannot be
applied without potentially affecting the wrong resources.

The failure is the production control. The apply is rejected because the plan is stale.

The fix is to re-plan:

terraform plan -out=production.tfplan
terraform apply production.tfplan

The new plan is reviewed. The new apply is executed.

The CI/CD pipeline

A CI/CD pipeline uses saved plans:

# Plan stage
- run: terraform init
- run: terraform validate
- run: terraform plan -out=tfplan
- run: terraform show -json tfplan > plan.json
- uses: actions/upload-artifact@v4
  with:
    name: tfplan
    path: tfplan

# Apply stage (after manual approval)
- run: terraform apply tfplan

The plan is uploaded as an artifact. The apply stage is gated by a manual approval. The apply uses the saved plan.

The difference between saved plans and -auto-approve

The two are different production controls:

A saved plan is a reviewable artefact. -auto-approve is not. The two are not interchangeable.

The production pattern is:

# Save and review
terraform plan -out=production.tfplan
# (review)
terraform apply production.tfplan

Not:

# Dangerous: no review, no plan archive
terraform apply -auto-approve

What comes next

The next lesson is targeting — the -target flag and when it is appropriate.

Verification