Summary

Adds a new infra-aws-staging-v2 Pulumi stack for the fresh staging-composio AWS account (351395891307). The stack is documented in stacks/aws-staging-v2/README.md and currently deploys:

• two-AZ us-east-1 VPC foundation with public/DMZ, application-private, and database subnet tiers
• two NAT gateways and public routing for allowlisted RDS access
• private ECR repositories for Apollo, Thermos, and Mercury
• Aurora PostgreSQL clusters for apollo-staging, thermos-staging, and workerdb-staging
• IAM database authentication enabled on all Aurora clusters
• AWS-managed master passwords and generated admin/writer/reader password secrets per cluster
• Pulumi-managed VPC bootstrap Lambda that creates/updates PostgreSQL users and grants
• Apollo ECS foundation and public ALB, service disabled until an Apollo ECS image is available
• Thermos ECS Fargate service behind a public HTTP ALB allowlisted to static IPs only
• Thermos Datadog logging via FireLens, datadog-agent, and a Fluent Bit log_router sidecar
• Mercury VPC-attached Lambda using the copied mercury-staging:latest ECR image
• narrow Doppler Secrets Manager sync roles for Thermos and Mercury only

Live deployment notes

This stack has been applied to staging-composio using aws:profile: staging-composio.

Images copied into the new account:

• Thermos: 351395891307.dkr.ecr.us-east-1.amazonaws.com/thermos-staging:latest
• Mercury: 351395891307.dkr.ecr.us-east-1.amazonaws.com/mercury-staging:latest

Thermos is deployed with task definition family stg_v2_thermos_orchestrator. The live service is steady with one running task and uses the Datadog sidecars.

Datadog logging:

• API-key secret path: datadog/staging/api-key
• The ECS task execution role can read only the configured app/runtime secrets plus this Datadog secret.
• Thermos and datadog-agent use FireLens secretOptions for the Datadog apikey, so the key is not stored in the task definition as plaintext.
• Replace the secret value with the new staging Datadog API key when available.

Doppler role ARNs:

• Thermos: arn:aws:iam::351395891307:role/thermos-staging-doppler-secrets-manager-role
• Mercury: arn:aws:iam::351395891307:role/mercury-staging-doppler-secrets-manager-role

Database users

Each Aurora cluster now has exactly three non-master Secrets Manager entries:

• apollo-staging/admin-user, apollo-staging/writer-user, apollo-staging/reader-user
• thermos-staging/admin-user, thermos-staging/writer-user, thermos-staging/reader-user
• workerdb-staging/admin-user, workerdb-staging/writer-user, workerdb-staging/reader-user

Each secret contains username, password, connection hosts, dbname, sslmode, and a URL-encoded postgresql://... URL for Doppler.

Security/access choices

• RDS instances are publicly accessible by request, but SG ingress allows PostgreSQL only from:
  • 34.233.50.61/32
  • 54.224.131.195/32
  • 103.80.162.245/32
  • the application security group
  • the internal DB bootstrap Lambda security group
• Thermos ALB is public HTTP on port 80, allowlisted only from configured Thermos ALB CIDRs.
• ACM/Cloudflare DNS validation was intentionally removed for now; HTTPS can be added later when Cloudflare credentials/validation are available.
• The previous broad Doppler role was removed; only service-specific narrow roles remain.

How this differs from current staging infra

Current staging is mostly an imported/default-VPC style stack. This PR adds a clean new-account stack instead of mutating the existing staging import.

Key differences:

• VPC model: current staging uses the AWS default-style 172.31.0.0/16 VPC and public default subnets; staging v2 uses a purpose-built 10.42.0.0/16 VPC.
• Subnet tiers: current staging mixes workloads into default/public subnets and later-added Lambda private subnets; staging v2 has explicit public, application-private, and database tiers.
• AZ mode: staging v2 is intentionally two-AZ in us-east-1a and us-east-1c.
• NAT/egress: current ECS services commonly use assignPublicIp: true; staging v2 puts ECS/Lambda workloads in private app subnets with NAT egress.
• Databases: current staging references composio-rds-subnet-group and has mixed/imported RDS resources; staging v2 creates three purpose-named Aurora clusters with IAM auth, managed master secrets, generated admin/writer/reader users, and static-IP-only public access.
• Apollo placement: current Apollo is Vercel-hosted; staging v2 prepares Apollo for ECS Fargate behind a public ALB, with the service disabled until an image exists.
• Thermos placement: current Thermos uses ECS in default VPC public subnets; staging v2 runs Thermos in private app subnets behind an allowlisted public ALB.
• Thermos observability: current staging had a Datadog sidecar; staging v2 now uses the same sidecar pattern but keeps the Datadog API key in Secrets Manager and injects it through ECS secret references.
• Mercury placement: staging v2 models Mercury as a VPC-attached Lambda with an ECR-backed container image.
• Secrets: staging v2 creates first-class Secrets Manager bundles for Apollo, Thermos, Mercury, Redis, DB users, Thermos Doppler token, and Datadog log intake.
• Account portability: staging v2 avoids the many hardcoded existing staging account resource IDs in the imported stack and is designed to deploy into the new AWS account.

Validation

• npx tsc -p stacks/aws-staging-v2/tsconfig.json --noEmit passes in the main workspace.
• pulumi up --stack dev --yes --non-interactive has been run successfully after image bootstrap, DB user bootstrap, and Datadog sidecar addition.
• Live ECS check confirms Thermos task definition revision :9 has thermos, datadog-agent, and log_router containers, with Thermos and Datadog Agent using awsfirelens.