Why Terraplane

Terraform changes should be reviewable, repeatable, and tied to pull requests — not tribal knowledge or ad-hoc laptop runs. Tools like Atlantis proved that model works: comment on a PR, get a plan, apply when ready.

Terraplane keeps that workflow and reshapes the execution model.

One process vs two roles

Most PR-driven Terraform tools are a single process that both:

1. receives webhooks, and
2. runs Terraform.

That’s fine when every target is reachable from wherever that process lives. It gets awkward fast when it isn’t.

Private APIs, internal control planes, VPC-only endpoints, on-prem systems — with a single remote runner you’d either:

• expose those targets (firewall holes, peering, public load balancers), or
• give up on automating them.

Agents dial out

Terraplane splits the job:

Piece	Responsibility
Orchestrator	Webhooks, job state, locks, PR feedback. Can live on the public internet.
Agents	Long-lived workers that connect out over WebSocket and run Terraform where credentials and network already exist.

Agents sit inside the network that can already reach the resources. The orchestrator never needs a path in.

Stacks are routing

Each stack declares which agent should handle it. Multi-account and multi-environment setups become a routing problem — not “stuff every credential into one box,” and not “punch a hole so the control plane can see the private thing.”

Standing on Atlantis’s shoulders

Terraplane would not exist without Atlantis.

Atlantis set the standard for PR-based Terraform: comment-driven plans and applies, locking, and feedback on the PR itself. Terraplane borrows heavily from that UX on purpose. If you’ve used Atlantis, the commands should feel familiar.

Where Terraplane diverges is architecture — remote agents and stack→agent routing — not the idea that Terraform belongs in the pull request.