IaC Layout

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

The infrastructure repo — shared modules + control plane

The infrastructure repo 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 control plane in the infrastructure repo is applied separately and consumed by the modules themselves.