Still Running Terraform Locally? Let's Talk.

There’s a good chance you’re deploying your Azure infrastructure from your own machine. Maybe it’s Terraform. Maybe it’s working… most of the time.

But here’s the question I’d pose:

Are you still running terraform apply locally, or have you moved your infrastructure into a pipeline?

And more importantly, why?

Because while running Terraform locally might feel fast and flexible, it can quietly introduce a whole stack of problems that don’t show up until you start scaling.

The Local Workflow Trap

I get it—running Terraform locally feels simple:

1. Make your change
2. terraform plan
3. terraform apply
4. Job done

But what starts as flexibility becomes fragility. Here’s why:

• No approvals: Anyone can deploy anything to any environment.
• No audit trail: Unless you fancy grepping shell history.
• No feedback: Policies, security checks, cost estimates? You’re flying blind.
• No consistency: Drift creeps in, and no two environments are quite the same.

What’s worse? It doesn’t scale. As soon as multiple engineers are working on the same infra, someone breaks something—or someone else spends their Friday fixing it.

Pipelines: Not Just for App Code

It’s 2025. We have version control, CI/CD, and policy-as-code. There’s no reason infrastructure should lag behind.

Moving your Terraform into a build and release pipeline, like Azure DevOps, isn’t about process for process’s sake. It’s about building reliable, repeatable, safe infrastructure delivery.

Here’s how that actually plays out in real life.

Terraform Modules = Infrastructure at Scale

If you’re not using Terraform modules, you’re missing out.

Modules let you:

• Standardize how infra is built across teams.
• Reuse patterns for things like VNets, storage, AKS clusters.
• Abstract the tricky stuff, expose clean variables.

Once you’ve built your golden modules, you can plug them into pipelines and lock them down with versioning. That means:

• Less duplication.
• Easier reviews.
• Less room for error.

It also opens the door to a platform model, where teams consume infrastructure as a product, not a loose pile of scripts.

Approval Gates = Safer Deployments

When you run Terraform through Azure DevOps, you can introduce real controls without slowing anyone down:

• Pre-prod / Prod gates: Want to make sure someone signs off before a live change hits Azure? Done.
• Manual approvals only where needed: Use conditional logic in your pipeline to trigger approvals for critical paths, and auto-approve the rest.
• Environment scoping: Pipelines tied to specific environments and service connections.

It builds trust in the process. And it helps platform teams sleep better.

Where to Start

You don’t have to overhaul everything overnight. Here’s what I’d recommend:

1. Pick one Terraform module you trust: Your dev environment, a VNet, or something low-risk.
2. Build a pipeline around it in Azure DevOps: Use terraform init, plan, apply stages, even add a destroy if needed.
3. Introduce an approval for production: Manual or role-based, just to create structure.
4. Add feedback into the pull request: Show the plan. Add policy checks. Bonus points for cost estimation.
5. Repeat. Improve. Scale.: Turn infra into productized building blocks that anyone can safely consume.

Let’s Make This Practical

So, where are you running Terraform today? Are you still going local, or have you made the leap to pipelines?

What’s worked well for your team? What’s slowed you down?

Drop your experience in the comments. Would love to hear how others are approaching it, especially in Azure-heavy environments.

Want a follow-up piece on how to structure Terraform repos and pipelines in Azure DevOps? Let me know—happy to break that down next.