terraformdevopsplatform-engineeringgitopsdelivery-velocitydrift-detectionsecurity

Terraform Apply: Before or After Merge?

Erik Osterman
byErik OstermanCEO & Founder of Cloud Posse
Jan 31 2025

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.

Erik Osterman
Erik Osterman
CEO & Founder of Cloud Posse
Founder & CEO of Cloud Posse. DevOps thought leader.

Share This Post