↓Skip to main content
  1. All Posts/
  2. Tech Logs/

Part 6: Scaling Execution — The Case for TACOS

·517 words·3 mins
Terraform Tacos Gitops Cicd Automation Devops
Siyad Salam
Author
Siyad Salam
Table of Contents

This is Part 6, the final installment of my series on Production-Grade Terraform Patterns. In Part 5, I closed the loop on updates. But one question remains: When you merge a PR, who actually runs terraform apply?

In valid “GitOps”, humans should never touch the cloud console. And ideally, they shouldn’t even run terraform apply from their laptops.

The Evolution of Execution
#

Stage 1: Crypto-ClickOps (The Dark Ages)
#

You run terraform apply from your laptop.

  • Risk: You have AdministratorAccess keys on your disk.
  • Bug: You forgot to git pull before applying. You just overwrote your colleague’s changes.

Stage 2: Generic CI (Jenkins/GitHub Actions)
#

You put terraform apply in a pipeline that runs on merge to main.

  • Benefit: Centralized, audited execution.
  • Friction: You only see the failure after you merge. “Fixing broken main” becomes a daily ritual.

This is where many teams land first. It works until PR-time plan review and locking start to matter.

Stage 3: TACOS (Terraform Automation and Collaboration Software)
#

This is the modern standard. TACOS tools move plan and apply into the Pull Request, so you review infrastructure changes before they touch the cloud.

The Workflow
#

sequenceDiagram participant Dev as Developer participant Git as GitHub PR participant TACOS as TACOS participant Cloud as AWS Dev->>Git: Open Pull Request Git->>TACOS: Webhook Event TACOS->>TACOS: Plan TACOS->>Git: Comment: "Plan: 3 to add" Dev->>Git: Comment: "apply" Git->>TACOS: Webhook Event TACOS->>Cloud: Apply Changes TACOS->>Git: Comment: "Apply Successful" TACOS->>Git: Merge PR (Optional)

TACOS in the wild
#

The category includes many products. Below are the ones worth knowing, with official links only.

PR-native and self-hosted
#

  • Atlantis: Open-source PR automation server.
  • OpenTaco: Successor to Digger. Atlantis-style automation on your existing CI runners.
  • Burrito: Kubernetes operator for Terraform PR/MR workflows and drift detection.

Orchestration and platform
#

  • Terramate: Stacks, orchestration, CI/CD integration, and observability.

Managed platforms
#

  • HCP Terraform (formerly Terraform Cloud) / Terraform Enterprise: HashiCorp’s managed offering.
  • Spacelift: Multi-IaC orchestration platform.
  • Env0: Cloud governance and IaC automation.
  • Scalr: Terraform Cloud alternative with PR-native GitOps.

Digger rebranded to OpenTaco. Same category, new name. If you evaluated Digger in the past, start with OpenTaco.

Pick based on team size, existing CI, and whether you want self-hosted or SaaS. I have not deployed any of these in my reference repos. Treat this as a starting point, not a recommendation.

Why You Need This
#

If you have more than 3 engineers, locking is essential. TACOS provide:

  1. State Locking: Prevents race conditions.
  2. Plan Review: The plan output is right there in the PR comment, immutable and searchable.
  3. Gatekeeping: You can require “1 approval” before the apply command is allowed to run.

Conclusion
#

That closes the series. A complete platform looks like this:

  1. Split Repos (Part 1) isolate failure domains.
  2. Modules (Part 2) provide reusable logic.
  3. Release Please (Part 3) versions those modules reliably.
  4. Git Tags (Part 4) wire the live repo to versioned modules.
  5. Renovate (Part 5) keeps dependencies fresh.
  6. TACOS (Part 6) automate the final mile: plan and apply in the PR, with locking and review.

You have now graduated from “running scripts” to building a Product.