Terraform names your pets. Terrantula herds your cattle.
Visibility, cascade ordering, and tenant-fleet orchestration — on top of the Terraform runner you already run.
Sits on top of Terraform
The cattle wedge
Terraform is excellent for pets — long-lived infrastructure you curate by hand. It's awkward for cattle: fleets of templated, often-ephemeral resources where the population matters more than the individual. Terrantula adds the missing layer above your runner.
A single fleet view across every tenant, cluster, and stack — derived from the Terraform state you already produce. No more state files scattered across N workspaces with no system-level picture.
Typed relationships with cardinality and lifecycle. Terrantula computes the order things must change in — placement, dependency, deprovisioning — so the fleet stays consistent as it grows.
Define a tenant blueprint once. Terrantula handles placement onto the least-loaded matching cell, capacity enforcement, and lifecycle across hundreds of tenants — using your existing runner.
See it
The Web (Strand) graph view renders your fleet as a living graph — entities, cells, and relationships. It is a read-only projection of your Terraform-derived state: the view never writes infrastructure. All changes flow through Actions → pull requests → your apply.

What's in the box
The model SaaS operators already build by hand, every time — made first-class.
Typed, stateful records of what exists — tenants, clusters, databases — placed into cells with capacity constraints and a placement policy.
Model dependencies with cardinality enforcement. Terrantula derives the cascade order for changes and deprovisioning from the graph.
Actions modify your IaC by opening a pull request against your repository. Terrantula never runs terraform apply — your CI applies the change, exactly as it does today.
Apache-2.0 backend. The cattle wedge runs end-to-end on free, self-hostable tooling — Terrantula + your CI + your state, with zero required SaaS dependencies.
How it works
The first five minutes get you a working graph view against your existing state. Everything after that flows through pull requests into the runner you already run.
Point Terrantula at a .tfstate file (or an Atmos stacks directory) and a starter config. It maps your resources to typed entities — no blueprint required.
terrantula import-terraform \
--state ./terraform.tfstate \
--config aws-multi-accountLearn more: Import your TF state →Launch the local fleet view. It runs entirely on your machine — no signup, no server, no Docker. The graph is a read-only projection of your Terraform-derived state.
terrantula dashboard
# Dashboard ready at http://localhost:54321Learn more: Quick Start (5 minutes) →Describe the fleet in YAML: entity types, cells with capacity constraints, and typed relationships with cardinality. This is the structure the cascade reasons over.
kind: Cell
metadata:
name: prod-clusters
spec:
entityType: TenantCluster
placementPolicy: least-loaded
constraints:
- { metric: tenant-count, aggregate: sum, max: 500 }Learn more: Core Concepts →An Action like OnboardTenant places the tenant onto the least-loaded matching cell and opens a pull request against your IaC repository. Terrantula never applies it for you.
kind: Action
metadata:
name: OnboardTenant
spec:
associatedWith: { entityType: Tenant, scope: collection }
recommendations:
- { name: target-cluster, pool: prod-clusters, sortBy: tenant-count }Learn more: Wire an Action →The PR lands in your existing workflow. Whatever runs Terraform for you today — TFC, Atmos, Atlantis, or a GitHub Actions workflow with state in S3 — keeps doing it, exactly as before.
# Reviewer merges the PR →
# your existing pipeline runs the apply.
# Terrantula syncs the result back into the graph.Learn more: Advanced Quick Start →The backend is Apache-2.0. The cattle wedge runs on free, self-hostable tooling — Terrantula + your CI + your state — with zero required SaaS dependencies. Start local in under five minutes.