Security architecture

Terrantula is designed so that adopting it does not widen your blast radius. This page is the canonical statement of the guarantees the rest of the site links to.

The data flow

your state file / stacks dir          your IaC repository
        │ (read-only import)                  ▲
        ▼                                     │ (pull request)
   ┌─────────────────────────────────────────────┐
   │  Terrantula control plane                   │
   │  entity graph · cells · lifecycle · audit   │
   └─────────────────────────────────────────────┘
                                              │
                                              ▼
                            your CI runs terraform apply
                            (webhook confirms the merge)

Terrantula reads your Terraform state (or Atmos stacks) to build the graph, and emits changes as pull requests against your repository. Your existing pipeline reviews and applies them. Nothing else moves.

The four guarantees, and their mechanisms

Never runs terraform apply. There is no execution path for it. Actions emit change intent to an execution surface you configure — a pull request, a repository_dispatch, a TFC or Atmos run, a webhook — and your own system executes. Placement and constraint checks happen before the PR opens; the PR is the reviewable, auditable change.

Never holds your cloud credentials. Terrantula has no store for AWS/Azure/GCP credentials and no API that accepts them. The credentials that apply infrastructure stay where they are today: in your CI.

Read-only import; read-only view. terrantula import-terraform reads state — it never writes to it, and never needs write access to your cloud. The dashboard is a projection of that state: infrastructure changes cannot be made from the UI. The UI writes only its own metadata (saved views, pinned positions) and Terrantula-owned catalog intent.

Self-hostable end-to-end. The backend is Apache 2.0 and runs with zero SaaS dependencies — your Postgres, your CI, your network boundary. For regulated environments, nothing has to leave your infrastructure. Worst case, you keep running the code you already have, forever.

Secrets and tokens

API tokens are prefixed (terr_…) and stored as SHA-256 hashes — only the prefix is retained for display. Columns holding third-party credentials (for example an OIDC client_secret) are encrypted at rest with a key you control (ENCRYPTION_KEY). Token and secret values are never logged.

The hosted product

Terrantula Cloud hosts the same control plane — the entity graph, catalog, and audit surfaces — as a managed service. It holds what the self-hosted control plane holds: your fleet model and its history. It does not hold your state files, your runners, or your cloud credentials; those never route through Terrantula in either deployment. See Cloud.

Status

Terrantula is pre-1.0. SOC 2 has not yet been pursued; for security review before then, this page plus a self-hosted deployment inside your own boundary is the intended path. Questions or reports: open an issue or contact the maintainer via GitHub.

ON THIS PAGE

#Security architecture

#The data flow

#The four guarantees, and their mechanisms

#Secrets and tokens