IaC Layout

Foundry uses OpenTofu and splits infrastructure into two layers: a shared control plane with reusable modules in foundry-iac, and per-repo app-edge stacks in each service's ci/iac/.

foundry-iac — shared modules + control plane

foundry-iac holds reusable OpenTofu modules and the control-plane stack that provisions the always-on platform (VPC, ECS cluster + Fargate services, RDS, ALB, CloudFront + WAF, bastion, OIDC roles). Module categories include:

modules/
  vpc/  ec2/  ssh-key/  security-group/
  ecs/ecs-cluster/  ecs/ecs-service/  ecr/  cloudmap/
  rds/  lambda/
  alb/  cloudfront/  waf/  acm/  route53/

The control-plane composition (e.g. prod/) wires these modules together, keeps its state in S3, and is applied independently of any single app.

Per-repo ci/iac — app edge

Each deployable repo carries its own OpenTofu stack under ci/iac/<stack> for the infrastructure unique to that app — typically a static site's S3 bucket and CloudFront distribution. A typical stack:

ci/iac/<stack>/
  providers.tf      # aws + aws.us_east_1 (for CloudFront/ACM certs)
  backend.tf        # remote state
  bucket.tf         # S3 bucket
  certificate.tf    # ACM certificate
  cloudfront.tf     # CloudFront distribution
  dns.tf            # Route 53 records
  iam.tf            # the tofu-runner role CI assumes
  outputs.tf        # bucket_name, distribution_id, ...

How they connect to a deploy

The central manifest points each service at its app-edge stack via deploy.iac.stackPath and names the outputs to read (bucketOutput, distributionIdOutput). The orchestrator plans/applies that stack (smart IaC), reads those outputs, and uses them to publish the build. The shared foundry-iac control plane is applied separately and consumed by the modules themselves.