Learn
Reference
Examples
Learn
Reference
Examples

Use-cases

Find yourself in one of these. Each is a real cattle-shaped problem Terrantula was built for.

Tenant placement across a cluster fleet

Maya runs platform for a multi-region SaaS. Customers route to per-tenant clusters spread across regions, and each cluster has a hard ceiling — "we cap at 50 tenants per cluster." Today that limit lives in a runbook, placement is a spreadsheet, and onboarding a new tenant means someone manually finding a cluster with room.

With Terrantula: clusters are entities with a tenant-count metric and a max: 50 constraint; the production fleet is a cell with placementPolicy: least-loaded and an aggregate ceiling. An OnboardTenant Action picks the right cluster automatically, enforces the cap, opens a PR with the tenant's IaC, and your CI applies. The fleet view shows capacity at a glance.

→ See cattle-saas-tenants (Terraform Cloud) and the Advanced Quick Start.

Templated per-customer stacks

Devon leads platform at a vertical SaaS where every customer gets an isolated stack — a namespace, a database, an IAM boundary. The Terraform is templated, but provisioning each customer is hand-driven and inconsistent, and deprovisioning when a customer churns is an afterthought nobody owns.

With Terrantula: the customer stack is modeled once as an entity type with a lifecycle (pending → provisioning → active → deprovisioning). An Action templates the per-customer files and opens a PR; another Action drives clean deprovisioning in the right order. Constraints and cardinality keep the fleet consistent. Provisioning becomes a single command that produces a reviewable PR.

→ See the Examples gallery and Wire an Action.

Fleet visibility on Terraform sprawl

Riley is a platform engineer with Terraform spread across many accounts and repos — and no fleet-wide view. There's no "cattle problem" yet, just sprawl: nobody can answer "what do we actually have, and how does it connect?" Riley spans both worlds — a large company with TF sprawl, and a small team running boring Terraform with GitHub Actions and S3 state.

With Terrantula: this is the visibility on-ramp. Point terrantula import terraform at your state, run terrantula dashboard, and get a graph of the fleet in under five minutes — no blueprint, no server, no signup. Orchestration is there when you grow into it; for now you just get to see the fleet.

→ Start with the Quick Start and the bare-TF on-ramp.

OSS-first, no SaaS dependencies

Sam leads platform at an OSS-first shop running Atmos and self-hosted CI. The constraint is hard: no SaaS dependencies allowed. Any tool that requires subscribing to something is a non-starter.

With Terrantula: the entire cattle wedge runs on free, self-hostable tooling — Terrantula OSS (Apache 2.0) + Atmos + your own CI = full functionality at $0 SaaS spend. Actions invoke Atmos workflows via a customer-deployed reference runner; nothing routes through a hosted service unless you choose the hosted option. Self-hosting is a first-class path, not a downgrade.

→ See Deploy on Kubernetes and the Atmos on-ramp.

Common thread

All four converge on the same surface: model the fleet once, let Terrantula enforce placement and constraints, and change infrastructure by opening pull requests your existing CI applies. Visibility first, orchestration when you're ready.

Next

ON THIS PAGE