Stacks of stacks

A management stack can hold the GantryCD setup for a team or platform. Its OpenTofu code uses the GantryCD provider to create the other stacks.

This is similar to the apps-of-apps pattern: one small root points GantryCD at the repositories and directories it should run.

terraform {
  required_providers {
    gantrycd = {
      source = "gantrycd/gantrycd"
    }
  }
}

provider "gantrycd" {}

locals {
  stacks = {
    network = "stacks/network"
    cluster = "stacks/cluster"
    apps    = "stacks/apps"
  }
}

resource "gantrycd_stack" "child" {
  for_each = local.stacks

  name              = each.key
  repository_url    = "https://github.com/example/infrastructure.git"
  working_directory = each.value
  branch            = "main"
  opentofu_version  = "1.11.0"
  managed_backend   = true
}

When this stack runs, the provider uses its stack service account. GantryCD creates a short-lived token for the run and removes it when the run ends. No GantryCD token needs to be stored in the code or stack variables.

An admin must give the management stack’s service account its first role. The stack cannot grant roles to itself. Prefer a custom role limited to the child stack names or authorization labels it owns.

Keep the ownership simple:

• Do not let the management stack manage itself.
• Keep each child stack owned by one management stack.
• Review the management stack’s plan like any other infrastructure change.
• Add access only for the GantryCD resources declared by the code.

The same pattern can manage contexts, cloud integrations, runner groups, and role assignments when they belong to that stack set. Add them only when the management stack needs to own them.