Skip to main content
Now that you’ve written your Terraform configs, initialized the working directory, and reviewed the plan, the final step is terraform apply. Apply is the execution phase: Terraform reconciles your configuration with real-world infrastructure by calling provider APIs to create, modify, or destroy resources. Everything up to this point has been preparation and preview; apply is where infrastructure-as-code becomes actual infrastructure. In this article you’ll learn:
  • What terraform apply does under the hood
  • Key operational behaviors to expect during apply
  • Common ways to run apply (interactive, saved plan, automation)
  • Practical best practices to use apply safely

​
What terraform apply actually does

  • Runs a planning step that compares the recorded state with the desired configuration and produces a proposed set of changes.
  • By default, displays that plan and prompts you to confirm before making changes (you must type yes to proceed).
  • Executes the proposed changes by calling provider APIs and updates state as resources are created/updated/destroyed.

​
Key operational behaviors during apply

  • State locking: Terraform attempts to acquire a lock on state before applying changes when the backend supports locking (for example, Terraform Cloud or AWS S3 with a DynamoDB lock). This prevents concurrent modifications and reduces the risk of state corruption. Note: the local backend has limited locking semantics and some backends do not support locks.
  • Incremental state updates: State is written incrementally as each resource operation succeeds rather than only at the end. If an apply fails partway through, the state reflects the resources already processed.
  • No automatic rollback: Terraform does not automatically undo resources that were successfully created if a later resource fails. After a failed apply you must fix the cause and re-run apply (Terraform will continue from the current state), or manually destroy partial resources if appropriate.
  • Dependency graph: Terraform respects resource dependencies and processes resources in the correct order. Independent resources may be handled in parallel when the provider supports it.
The image provides an overview of Terraform apply operations, explaining state locking, state updates, and the absence of automatic rollback when applying changes to infrastructure.

​
How to run terraform apply

ModeCommand / WorkflowWhen to use
Interactive defaultterraform applyManual changes when you want to review the final plan before execution.
Saved plan fileterraform plan -out=myplan.tfplan then terraform apply myplan.tfplanCI pipelines or when you want to review and store the exact plan to apply later.
Non-interactive / automationterraform apply -auto-approve or terraform apply -input=false -auto-approveAutomation and CI/CD where human interaction is not possible (use with caution).
Details and examples: Default interactive apply 
terraform apply
This runs an implicit plan (refreshing state as needed), prints the proposed changes, and waits for you to confirm by typing yes. It’s the safest manual workflow. Apply a saved plan file
  1. Create and save a plan:
terraform plan -out=myplan.tfplan
  1. Apply the saved plan:
terraform apply myplan.tfplan
Applying a saved plan skips the planning step and applies exactly what was saved. Note: applying a previously saved plan does not refresh real-world state before execution — if the infrastructure changed since the plan was created, the apply may fail. Non-interactive / automation flags
  • Skip the confirmation prompt:
terraform apply -auto-approve
  • For CI/CD pipelines (disable prompts and auto-approve):
terraform apply -input=false -auto-approve
Use these flags only in automated contexts. -auto-approve removes the safeguard of human confirmation; -input=false prevents Terraform from prompting for input.
When running Terraform in CI, generate and save the plan (terraform plan -out=myplan.tfplan) and then apply that exact plan file in the pipeline so the applied changes match what you reviewed.
Avoid -auto-approve for manual or production changes. Skipping confirmation increases the risk of unintended destruction or replacement of resources.

​
Best practices before and during apply

  • Always run and review terraform plan separately, especially for production or complex changes. Carefully check for unexpected replacements or deletions.
  • Ensure you are in the correct working directory, using the intended backend and workspace before applying.
  • Test changes in development or staging environments before applying to production.
  • Be patient for long-running resources (databases, complex networking). Terraform waits for provider operations to complete; slow progress typically means the cloud provider is still provisioning.
  • After a successful apply, verify resources were created/updated as intended and commit configuration changes to version control with clear messages that reflect the infrastructure changes.
  • Use access controls and code review workflows for changes that modify critical infrastructure.

​
Summary

terraform apply is the execution step that converts configuration into real infrastructure. It uses state locking (when supported), updates state incrementally, honors dependency ordering, and does not automatically roll back failed operations. Prefer interactive planning and careful review for manual changes; in automation use saved plans and non-interactive flags with appropriate safeguards.

Watch Video