Use-cases
Find your shape. Each pattern below is a fleet Terrantula was built to run.
A deployment per customer
Every customer gets an isolated deployment — usually several Terraform stacks: the network, the database, the application, the IAM boundary. The Terraform is templated, but provisioning each customer is hand-driven, and deprovisioning when one churns is an afterthought nobody owns.
Model the customer deployment once as an entity type — one entity, however many stacks it spans — with a lifecycle (pending → provisioning → active → deprovisioning). One Action templates the per-customer files and opens a PR; another drives teardown across every stack in the right order. Provisioning becomes a single command that produces a reviewable PR.
→ Examples gallery · Wire an Action
Tenants placed across a cluster fleet
Customers route to clusters spread across regions, each with a hard ceiling — "50 tenants per cluster" — that lives in a runbook. Placement is a spreadsheet, and onboarding means someone manually finding a cluster with room.
Make clusters entities with a tenant-count metric and a max: 50 constraint; make the production fleet a cell with placementPolicy: least-loaded. An OnboardTenant Action picks the cluster, enforces the cap, and opens the PR. The fleet view shows capacity at a glance.
→ cattle-saas-tenants · Advanced Quick Start
Hundreds of vended cloud accounts
You vend AWS accounts, Azure subscriptions, or GCP projects through an account factory — AFT, lz-vending, a project factory. The vending works; everything after it doesn't: rolling a change across the fleet takes days, failures are silent per-account, and there's no dashboard, no lifecycle, no decommission story.
Model each account as an entity and each OU or management group as a cell. Terrantula gives the vended fleet what the factory doesn't: one view of every account and its state, capacity and policy constraints checked before vending, and Actions that emit changes as PRs into the vending repo you already run.
→ Import your TF state · Examples gallery
A stamped deployment per data team
Every data domain gets its own stamped deployment — a Databricks workspace, a Snowflake database, a data landing zone with its buckets and IAM, often across several stacks. The stamping is Terraform; keeping dozens of them consistent, placed, and cleanly retired is manual.
Model each data product's infrastructure as a single entity, however many stacks it spans; let cells carry the per-platform ceilings; provision and retire through Actions that open PRs your platform team reviews.
→ Core Concepts · Examples gallery
Visibility on Terraform sprawl
No fleet problem yet — just sprawl. Terraform across many accounts and repos, state files in S3 buckets and workspaces, and nobody can answer "what do we actually have, and how does it connect?"
Point terrantula import terraform at your state and run terrantula dashboard: a graph of everything in under five minutes, with no blueprint, no server, no signup. Orchestration is there when you grow into it.
→ Quick Start · bare-TF on-ramp
Zero SaaS dependencies
Your shop is OSS-first: Atmos or bare Terraform, self-hosted CI, and a hard rule that tooling must not require a subscription.
The entire model runs on free, self-hostable tooling — Terrantula OSS (Apache 2.0) + your CI = full functionality at $0 SaaS spend. Actions invoke Atmos workflows through a customer-deployed reference runner; nothing routes through a hosted service unless you choose it.
→ Deploy on Kubernetes · Atmos on-ramp
Next
- FAQ — the questions that come up next.