When should Terraform apply run — before or after merging code?
It's one of the longest-running debates in Infrastructure as Code (IaC). And for good reason — each approach has trade-offs, and what works best depends on what you're optimizing for.
Over the years, we've seen dozens of teams evolve their Terraform workflows. In this post, we'll break down:
With this model, Terraform runs plan and apply inside the pull request (PR) — before merging. This is often implemented with tools like Atlantis.
Strengths:
main
branchWeaknesses:
main
→ poor audit trailHere, Terraform runs plan during PR, but only applies after merging to main
— similar to app deployments.
Strengths:
main
always matches live infra → clear audit trailWeaknesses:
After years of seeing Terraform patterns across dozens of companies — and running them ourselves — we strongly recommend apply-after-merge as the simpler, safer long-term path.
Here's why:
Avoid False Stability Apply-before-merge often gives a false sense of correctness — because infra changes are applied in incremental steps within the PR. But when finally applied post-merge in a single step — dependency cycles and broken patterns surface.
Prevent Dependency Cycles Terraform dependency cycles love to hide in iterative applies. Apply-after-merge forces a single apply — surfacing problems early.
Eliminate CI/CD Security Risks Apply-before-merge forces you to give full cloud admin to your CI/CD — a huge attack surface. Apply-after-merge can use tightly scoped deploy pipelines.
Keep main
as Source of Truth
If you apply in PRs, your live infra can change before the change exists in main
— making it harder to debug.
Apply-after-merge ensures every infra change is tied to a commit.
Enable Better Lifecycle Testing A good Terraform process should include plan → apply → destroy tests. Apply-before-merge often leaves unclean state and orphaned resources. Apply-after-merge is cleaner and more repeatable.
If you're leveraging GitHub Enterprise, GitHub Organization Rules, Repository Rules, or Branch Protections — there's another key reason apply-after-merge is the safer path:
Most GitHub governance features assume apply happens after merge.
Here's why:
main
— and downstream environments should deploy from main
.main
→ environment deploys are allowed — which matches apply-after-merge.Put bluntly: It's very hard to enforce strong governance if Terraform is applying before merge — because pull requests can bypass many of GitHub's controls.
And while preview environments (for app workloads) are great to deploy from PRs — for infrastructure, your critical environments should only apply from main
.
Let's be blunt: the most critical part of any Terraform workflow is surfacing failures early — not when you apply.
For apply-after-merge to be successful, you must have:
There's no one-size-fits-all. For some orgs:
...apply-before-merge can work — just be aware of the long-term risks around cycles, state drift, governance gaps, and CI/CD attack surface.
But if you're building a mature, multi-team platform — or working in a regulated environment — apply-after-merge is the safer default.
At the end of the day, the goal is safe, reliable infrastructure delivery — with clear visibility into what changed and when.
In our experience, apply-after-merge:
And with the right guardrails — drift detection, testing, rollback — it gives teams the confidence to move fast without breaking things.
Talk to an engineer — we're happy to help assess your Terraform workflow and recommend patterns that work.