Terraform Pull Request Automation 101

Pre-Merge Applies

So, you run a terraform plan. Looks good. You merge. Then, terraform apply blows up. We've all been there, right? That S3 bucket name that wasn't actually unique? Yeah, that. Applying changes before merging is key to keeping your main branch clean and reflecting what's actually deployed. If something goes sideways, you fix it in the PR, not in a panic post-merge. Atlantis really popularized this idea for Terraform.

Atlantis: The OG of Terraform PR Automation

Atlantis. Not the lost city, but the open-source tool that brought Terraform automation to the pull request. It’s been a big deal.

How It Works

Pretty simple, really.

1. Open a PR with your Terraform changes.
2. Comment atlantis plan.
3. Atlantis runs the plan, dumps the output back in the PR.
4. Team reviews. Looks good?
5. Comment atlantis apply. Atlantis runs the apply. Done. All in the PR.

The Good Parts

• Devs love it: Git workflows they already know. No fiddling with CI/CD pipelines for this bit.
• Quick feedback: See the plan, right there, right away.
• Collaboration: All the chat about the changes happens in one place.
• Visibility: Everyone sees what’s about to happen.

Where It Gets Tricky

But, as teams grow and infrastructure gets more complicated, Atlantis can start to show its limits.

• DIY Headaches: It's open source, so you're hosting it, maintaining it, securing it. That’s work.
• Governance Gaps: Need fancy policies with OPA? Or tight role-based access? That’s extra work, custom integrations.
• Scaling Pains: Lots of repos, lots of deploys? A single Atlantis might not keep up.
• State & Locking: Getting state locking right across many operations needs careful setup.
• Audit Trails: Compliance folks happy? Might need more tooling.

These are the kinds of things that make people look for something more.

Scalr: Taking PR Automation to the Next Level

And then there's Scalr. It’s built for Terraform and OpenTofu, and it nails that Atlantis-style PR workflow but wraps it in a whole lot more.

Getting the Atlantis Vibe with Scalr

Scalr uses VCS-driven workspaces. Link a workspace to a repo branch, and Scalr gets notified of PRs and merges. It’ll do a dry run (terraform plan) for every PR automatically. And it supports two main GitOps flows:

1. Merge-Before-Apply: Plan on PR, review, merge, then Scalr applies from the main branch. Classic.
2. Apply-Before-Merge: This is your Atlantis style. Plan and apply right from the PR, before it hits main. Super useful for dev environments or just really wanting to be sure.

Want to run plans and applies from PR comments, just like Atlantis? Easy.

Need to approve a run that’s waiting?

/scalr approve -workspace-id=ws-xxxxxxxxxx

Got multiple workspaces for one repo? Target one:

/scalr apply -workspace-id=ws-xxxxxxxxxx

Apply changes (if you have permission, of course):

/scalr apply

See the plan:

/scalr plan

And the feedback comes right back into the PR.

More Than Just Comments: Smart PRs

Nobody likes a noisy PR. Scalr gets this. If a plan is clean, you get a quick summary. If there are errors, OPA violations, or scary destructive changes, the PR comment gets loud and detailed. You see a summary of all changes for a PR in one spot, and you can dig into per-workspace reports. It’s about getting the right info to you without overwhelming you.

Safety First: Controlled Applies

Applying from a PR is powerful. So, you need guardrails.

• Branch Smarts: Scalr warns you if you’re trying to mess with state from a branch with unmerged PRs. It also stops auto-applies if the branch isn’t the workspace’s main one. No accidental stomping on state.
• No Unmergeable Applies: You can set it so /scalr apply only works after a PR is approved and passes branch protection. Keeps things compliant.
• Skip Post-Merge Apply: Already applied from the PR? Add [skip scalr] or [skip ci] to your merge commit message. Scalr won’t run it again.
• RBAC is Key: Not just anyone can /scalr apply. You need the runs:apply permission.

This combo of easy PR commands and solid safety features means you can trust this workflow, even in big, serious environments.

Beyond the /apply: What Else Scalr Brings

Getting the Atlantis flow is cool. But Scalr is a whole platform.

Making Workflows Your Own: Custom Hooks

Scalr lets you inject your own scripts at different points in a run: pre-init, pre-plan, post-plan, pre-apply, post-apply. Think linting, security scanning, cost checks, notifications, updating your CMDB. You can even create a central Hooks Registry for standard hooks that all your workspaces can use.

Here’s a quick example of a pre-plan hook to run tflint:

1. In Scalr:
   • Set interpreter to bash.
   • Point to your script in VCS.
   • Set phase to Pre-plan.

The Script (run_tflint.sh):

#!/bin/bash
echo "--- Running TFLint ---"
# Make sure tflint is there, or install it.
# On a Scalr self-hosted agent, you'd probably bake this into your custom image.
if ! command -v tflint &> /dev/null
then
    echo "TFLint not found, trying to install to /tmp/bin..."
    mkdir -p /tmp/bin
    # This is just one way to grab it; adjust as needed for your environment.
    curl -s https://raw.githubusercontent.com/terraform-linters/tflint/master/install_linux.sh | TFLINT_INSTALL_PATH=/tmp/bin bash
    export PATH="$PATH:/tmp/bin"
fi

# Run tflint. Assumes your .tflint.hcl is in the right spot.
if [ -f ".tflint.hcl" ]; then
    echo "Using local .tflint.hcl"
    tflint --config=.tflint.hcl --recursive .
else
    echo "No local .tflint.hcl, running tflint with defaults."
    tflint --recursive .
fi
# If tflint finds issues, it exits non-zero, and Scalr will usually stop the run.

Keeping Things in Check: OPA Policies

Scalr has deep Open Policy Agent (OPA) integration. Write your policies in Rego, store them in Git. Scalr checks them pre-plan (using run metadata) and post-plan (using the actual plan JSON). Violate a pre-plan policy that denies the run? You don't even get billed for that run. Policies can be advisory (just a warning), soft-mandatory (needs approval to proceed), or hard-mandatory (stops the run cold).

Example: A simple OPA policy to flag big cost increases.

package terraform

import input.tfrun as tfrun

# This policy denies if the estimated monthly cost delta is over $100.
deny[reason] {
    # Scalr puts cost estimates in tfrun.cost_estimate
    cost_delta := tfrun.cost_estimate.delta_monthly_cost
    
    max_allowed_cost_delta := 100.00
    
    cost_delta > max_allowed_cost_delta
    reason := sprintf("Heads up! Cost increase is $%.2f. We allow up to $%.2f.", [cost_delta, max_allowed_cost_delta])
}

Your State, Your Way: Backend Freedom

This is a big one. Terraform Cloud locks you into their backend. Scalr? Use theirs, or stick with S3, Azure Blob, GCS – whatever Terraform supports. Huge if you have data residency rules or just don’t want to move your existing state files. And state is always encrypted.

Run It Anywhere: Self-Hosted Agents

Use Scalr's shared runners, or deploy self-hosted agents in your own network. This is great for:

• Hitting private resources (repos, secret stores, internal APIs).
• Total control over the execution box (OS, specific tool versions, custom Docker images).
• Keeping everything inside your network for security or compliance.

Organizing the Chaos: The Hierarchy

Scalr uses an Account -> Environment -> Workspace model.

• Account: Top level. Central platform teams manage global stuff here (VCS links, cloud creds, module registry, OPA policies, agent pools).
• Environment: Groups of workspaces (think apps, business units, dev/staging/prod). They inherit from the Account.
• Workspace: Where the Terraform actually runs. Inherits from its Environment. This means you can set standards (policies, variables, tags) high up, and they flow down. DRY principles in action.

Not Just Terraform: Broader Tool Support

Scalr plays nice with Terraform, OpenTofu, and Terragrunt. So, your teams can use the tool that fits, all under one management umbrella.

The Showdown: Atlantis vs. Spacelift vs. Terraform Cloud vs. Scalr

How do these tools stack up? Here's a quick look:

Wrapping It Up: The Future of Your PRs

Automating Terraform through pull requests? It's a game-changer. Speeds things up, cuts down on mistakes, gets teams talking. That Atlantis style is popular for a reason—it just makes sense for developers.

But, as your IaC practice grows up, you need more than just PR comments that run terraform apply. You need solid governance, real security, workflows you can actually customize, and something that can scale with you. Choosing your IaC automation platform is a big deal. It affects how fast your devs can go, how stable your ops are, and your overall security.

Tools like Scalr show you can have that slick Atlantis experience and a whole ecosystem of grown-up features. Flexible GitOps, choice of state backend, powerful custom hooks, deep OPA policies, a smart org model, and support for the tools your teams actually use (Terraform, OpenTofu, Terragrunt)—it’s a strong package. It lets platform teams build safe, standard ways for everyone to do IaC, while developers get the smooth workflows they want. When you're looking at these tools, think about the whole picture – not just the PR commands, but everything you need for a solid, future-proof IaC setup.