porc vs astro vs terragrunt - hyperfocus/porc GitHub Wiki
Terraform Orchestration Tool Comparison: PORC vs Terragrunt vs Astro
High-Level Comparison Table
| Feature / Dimension | Terragrunt | Astro (Uber) | PORC (TD Bank) |
|---|---|---|---|
| Type | Open-source CLI wrapper | Open-source Terraform orchestrator | Internal TD-built Terraform orchestrator |
| Terraform Execution | Local or via TFE (remote) | Local execution orchestrated centrally | Remote only via TFE API, triggered via PINE/PORC APIs |
| Module Source | Remote modules (Git, registry) | Remote modules (via Git + Astro DAG) | Remote pre-approved modules only (no .tf in blueprint repos) |
| Inputs & Configuration | HCL (terragrunt.hcl) |
JSON/JSONNet (declarative + programmable) | JSON (terraform.tfvars.json generated by PORC) |
| Dependency Graphing | dependencies block (manual order) |
Full DAG (auto-wired from JSONNet config) | Explicit graph defined in PORC server (dependencies handled via API workflows) |
| DRY & Reuse | include, locals, shared HCL patterns |
JSONNet libraries, shared includes | Paved-path templates enforced via PORC templates + variables |
| Parallelism / Concurrency | Limited to run-all in folders |
Native DAG-level concurrency | Server-managed (PORC orchestrates DAG across modules with plan/apply APIs) |
| State Management | Terragrunt-managed, usually remote backend | Astro-managed | Always remote in TFE, configured by PORC |
| Policy Enforcement | Via Terraform Enterprise (Sentinel) | Centralized validation logic in Astro | Sentinel enforced in TFE; runs initiated only through PORC |
| Self-service UX | CLI only | CLI + Uber-specific tooling | PINE CLI + GitHub Checks UI + GitHub repo automation |
| Change Promotion (envs) | terragrunt.hcl per environment |
Declarative JSONNet configs per env | GitOps-style: blueprint per environment with overlays + APIs |
| Platform Governance | Good (shared inputs, locked modules) | Very strong (Uber-defined flows + validation) | Strong (platform-controlled run engine + module enforcement via PORC templates) |
| Extensibility / Hooks | Pre/post hooks supported | Controlled via JSONNet + Astro binary | API-first, webhooks, future extensibility planned via policy plugins |
| Intended Audience | Teams using Terraform with reuse needs | Uber infra teams managing 1000s of Terraform modules | TD engineering teams consuming pre-approved templates |
Summary by Use Case
| Use Case | Terragrunt | Astro (Uber) | PORC (TD Bank) |
|---|---|---|---|
| DIY IaC reuse | Excellent | Overkill | Not intended |
| Paved paths w/ governance | Good | Excellent | Excellent |
| Tight control / Remote runs | With TFE | Yes (DAG execution) | Yes (TFE + PORC only) |
| Team onboarding simplicity | Medium | Low (high learning curve) | High (PINE + GitHub integration) |
| CI/CD and GitHub integration | CLI-based | Custom | Native (GitHub Checks, GitOps) |
| Multi-team module enforcement | Good | Excellent | Excellent |
PORC: Pivot or Continue?
Recommendation: Continue building PORC — but enhance the following:
1. Paved Path UX Enhancements
- Add
porc summaryor GitHub PR annotations - Add
pine init appblueprint scaffolding - Pre-fill GitHub Actions workflows from blueprint metadata
2. Policy Extensibility
- Add optional pre-run hooks (validate schema, restrict dangerous patterns)
- Introduce plugin model for custom policy validation (e.g., OPA-lite)
3. Observability & Feedback
- Provide run summary UI (or GitHub Checks)
- Add DAG visualization and PR result dashboards
4. Developer Experience
- Backstage plugin (optional)
- Better error messages and preflight checks in
pine
5. Governance & Flexibility Balance
- Allow override flags for power users
- Module version pinning with constraints (
ref=~>v1.0)
When to Consider Terragrunt Instead
| Reason to Pivot | PORC Response |
|---|---|
| Need rapid bootstrap for small teams | PORC setup cost is higher |
| Teams should fully own IaC flows | PORC enforces paved paths centrally |
| Policy enforcement is not required | PORC adds governance automatically |
| GitHub Checks or APIs not important | PORC specializes in these flows |
Why Not Astro
Astro is powerful but:
- High operational complexity (JSONNet, internal Uber infra assumptions)
- Hard to integrate cleanly with GitHub-first workflows
- Doesn’t fit well unless you rebuild your entire control plane
PORC gives you a purpose-built platform layer that bridges Terragrunt’s reuse and Astro’s orchestration — with GitHub-native UX and TFE integration. The investment is worth it.