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:

• What each approach looks like
• The real risks teams hit with each
• Why we recommend apply-after-merge for most orgs
• How GitHub governance ties into this decision
• How to surface Terraform failures early — no matter what approach you choose

The Two Competing Approaches

Apply-Before-Merge (Shift-Left Apply)

With this model, Terraform runs plan and apply inside the pull request (PR) — before merging. This is often implemented with tools like Atlantis.

Strengths:

• Catches failures earlier — blocks bad changes from merging
• Faster feedback loop — devs see results right away
• Prevents broken infra from reaching main branch

Weaknesses:

• Requires CI/CD pipelines to have cloud admin access (security risk)
• Live infra can change outside of main → poor audit trail
• Encourages incremental applies → dependency cycles sneak in
• Locks state → can block other teams from applying

Apply-After-Merge (Deployment-Style Apply)

Here, Terraform runs plan during PR, but only applies after merging to main — similar to app deployments.

Strengths:

• Aligns with standard software delivery (post-merge deploys)
• main always matches live infra → clear audit trail
• Reduces Terraform dependency cycles
• No need to give CI/CD cloud admin rights
• Easier lifecycle testing (plan → apply → destroy)

Weaknesses:

• Higher risk if a bad change slips through (requires fast rollback)
• Slower feedback loop (results after merge)
• Requires strong drift detection

Why We Recommend Apply-After-Merge

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:

1. 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.

2. Prevent Dependency Cycles Terraform dependency cycles love to hide in iterative applies. Apply-after-merge forces a single apply — surfacing problems early.

3. 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.

4. 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.

5. 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.

Why Apply-After-Merge Works Better With GitHub Governance

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:

• Branch Protections are designed to ensure only reviewed, approved code lands in main — and downstream environments should deploy from main.
• GitHub Environments are tied to branches — and higher environments (staging, prod) are typically restricted to deploy only from protected branches.
• Secrets are scoped to environments — and sensitive secrets (e.g. production credentials) should never be exposed to pull request builds.
• GitHub Rulesets can enforce that only 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.

How to Surface Failures Early (No Matter What You Choose)

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:

• Automated Drift Detection Catch unexpected changes in live infra before they cause bigger problems.
• Integration Testing Validate that Terraform can plan, apply, and destroy cleanly.
• Fast Rollback Strategies If a bad change is merged, you need a reliable rollback path.

When Might Apply-Before-Merge Still Make Sense?

There's no one-size-fits-all. For some orgs:

• If security is less of a concern (early-stage startup), and
• You value fast feedback in PRs above everything else...

...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.

Final Thought

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:

• Reduces Terraform failures
• Lowers security risk
• Plays better with GitHub governance
• Makes infra more auditable and predictable

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.