#FAQ

#Does Terrantula runterraform apply?

No. This is the load-bearing rule. Terrantula Actions modify your IaC by opening a pull request against your existing repository — committing or patching the files that describe the change. Your CI applies the merged PR, exactly as it does today. Terrantula never executes terraform apply and never hosts your runners or state.

#Is it self-hostable?

Yes — end-to-end. The backend is Apache 2.0 and runs with zero SaaS dependencies; you bring your own Postgres. The full cattle wedge — entities, cells, relationships, Actions — works self-hosted, and nothing core is gated behind a paywall. See Deploy on Kubernetes.

There's also a hosted offering for teams who'd rather not operate Postgres or who want managed multi-tenancy, SSO/OIDC, and audit out of the box. It adds operations and a polished UI on top of the same OSS API — it doesn't fork it.

#Which substrates does it support?

Terrantula sits on top of whatever runs your Terraform. In priority order:

• Terraform — first-class, via the pull-request trigger and (coming) a Terraform Cloud / HCP Terraform run trigger.
• Atmos — a peer substrate; Actions invoke Atmos workflows via a customer-deployed reference runner. terrantula import-atmos handles the on-ramp.
• OpenTofu — same shape as Terraform.
• Atlantis — commits a PR your Atlantis instance picks up; a typed trigger with run-output capture is coming.
• Bare Terraform + GitHub Actions / GitLab CI + S3 state — the default-shipping integration; a reference workflow template Terrantula triggers via repository_dispatch.
• Any HTTP endpoint — the native webhook trigger.

See the Triggers reference for the details of each.

#Do I have to change how I run Terraform?

No. Whatever runs Terraform for you today keeps doing it. Terrantula orchestrates the fleet around your existing pipeline — it doesn't replace your runner, your state backend, or your CI.

#Can I just get a view of my infrastructure without committing to all this?

Yes — that's the visibility on-ramp. Run terrantula import terraform --state ./terraform.tfstate --config terrantula.yaml and then terrantula dashboard. You get a fleet graph in under five minutes, with no blueprint, no server, and no signup. Orchestration is opt-in later. Start with the Quick Start.

#Can I edit infrastructure in the dashboard?

No. The UI is a read-only projection of state derived from your Terraform. Every infrastructure change — entity properties, lifecycle states, entity-to-entity relationships — flows through an Action → a PR → your CI. The UI only writes its own metadata (saved views, pinned positions) and Terrantula-owned intent like cell membership.

#How is this different from Terraform Cloud or Spacelift?

Those run Terraform — they host runners and state. Terrantula doesn't. It's the fleet layer above whatever runs Terraform: placement, capacity, lifecycle, and audit across hundreds of tenants. You can point Terrantula at TFC and have it trigger runs there.

#How is this different from Atmos?

Atmos is the configuration layer; Terrantula is the fleet layer above it. They compose — Terrantula Actions invoke Atmos workflows for execution. Terrantula doesn't replace Atmos.

#How is this different from a service catalog like Backstage or Port?

A service catalog tracks service metadata with scorecards. Terrantula models live infrastructure with typed states, capacity constraints, and relationship cardinality — and changes it through PRs. Different problem.

#What does the CLI need to run?

Bun (>= 1.0). The CLI binary's shebang is #!/usr/bin/env bun. Install with bun install -g @terrantula/cli or npm install -g @terrantula/cli. See Install.

#Is it production-ready?

Terrantula is pre-1.0 — expect breaking changes. You can self-host today. See the project README for current status.

#Next

• Install — get the CLI.
• Quick Start — import your state and open the dashboard.
• Learn Terrantula — build the mental model.