Terraform CI/CD Pipeline — Automate Plan, Review, and Apply
Running Terraform from your laptop works until it does not — when someone applies without pulling the latest code, when state gets corrupted by concurrent applies, or when a change goes to production without review. A Terraform CI/CD pipeline eliminates these risks by automating the plan/apply workflow, enforcing code review, and providing guardrails that prevent costly mistakes.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
Why Every Terraform Project Needs a Pipeline
Manual Terraform workflows have a predictable failure mode. Developer A runs terraform plan on Monday, gets a clean plan. On Tuesday, Developer B applies a change. On Wednesday, Developer A runs terraform apply using their stale plan — and the apply does something unexpected because the state changed since their plan. A CI/CD pipeline eliminates this by running plan and apply as an atomic operation on the latest code and state.
The pipeline also enforces the review process. Without it, anyone with cloud credentials can run terraform apply from their machine and bypass code review entirely. With a pipeline, the only way to apply changes is through a merged pull request. This gives you an audit trail of every infrastructure change: who proposed it, who reviewed it, what the plan showed, and when it was applied.
Security scanning is the other critical function. Tools like Checkov, tfsec, and KICS can catch misconfigurations — public S3 buckets, overly permissive security groups, missing encryption — before they reach production. Running these in the pipeline means every PR gets scanned automatically, and security issues block the merge.
Pipeline Architecture
We build the pipeline in GitHub Actions, GitLab CI, or your preferred CI system. The workflow has four stages:
Validate: Runs terraform fmt -check to enforce style, terraform validate to catch syntax errors, and tflint to catch provider-specific issues. This stage runs in seconds and catches the most common mistakes.
Security Scan: Runs Checkov and/or tfsec against your code. Findings are posted as PR annotations so you see the exact line with the issue. Critical findings block the merge. Informational findings are reported but do not block.
Plan: Runs terraform plan -out=tfplan and posts the plan output as a PR comment. The plan file is saved as a pipeline artifact so the exact same plan is used for apply — no drift between plan and apply. Infracost runs alongside to estimate cost changes.
Apply: Triggered on merge to the main branch (for staging) or via manual approval (for production). Uses the saved plan file to apply exactly what was reviewed. Post-apply, the pipeline sends a notification (Slack, Teams, email) with the results. If apply fails, the pipeline records the error and the team investigates — there is no automatic retry that could make things worse.
For monorepos with multiple Terraform root modules, we detect which directories changed in the PR and only plan/apply those directories. This prevents unnecessary plans and reduces pipeline runtime.
What You Get
A production-ready Terraform CI/CD pipeline:
- PR validation — format check, validation, and linting on every push
- Security scanning — Checkov/tfsec with PR annotations and configurable severity thresholds
- Plan on PR — plan output posted as a PR comment with cost estimation via Infracost
- Apply on merge — automated apply for staging, manual approval for production
- Saved plan files — the exact plan that was reviewed is the plan that gets applied
- Monorepo support — change detection runs only affected Terraform directories
- Notifications — Slack/Teams alerts on plan results and apply outcomes
- Credentials management — OIDC federation for AWS/GCP (no long-lived keys in CI)
Why Anubiz Engineering
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.