Terrantula is a typed, constraint-enforced, audited model of fleet-shaped infrastructure that changes things by opening pull requests — never by running Terraform.
The problem it solves. You stamp the same Terraform many times — a stack (usually several) per customer, a workspace per tenant, an account per team. Terraform describes each instance precisely, but nothing above it decides where the next one lands, enforces the capacity ceiling, or tears one down cleanly when it goes away. Those are fleet decisions, and today they live in runbooks, spreadsheets, and one engineer's head.
The model. You describe the fleet once: entities (typed, stateful records — a tenant, a cluster, a database), cells (groups with placement policies and capacity limits), relationships (typed connections with cardinality), and Actions (workflows that validate, place, and emit the change). An entity spans everything that makes up one instance — the VPC, database, and API stacks of one tenant are a single entity — so two hundred tenants become two hundred entities you can count, query, and constrain, however many stacks each one holds.
The boundary. When an Action changes infrastructure, it opens a pull request against your repository; your CI reviews and applies it exactly as it does today. Terrantula sits above whatever runs your Terraform — TFC, Atmos, Atlantis, OpenTofu, or plain GitHub Actions with state in S3 — and never runs terraform apply, never holds your cloud credentials. The dashboard is a read-only projection of your Terraform-derived state.
One line of folklore captures the split: Terraform names your pets; Terrantula herds your cattle. The full argument is in Why Terrantula.