Skip to main content

Environments and infrastructure repos

Verified 2026-08-19 from GitHub Actions run history, ArgoCD manifests in the repos, and commit dates. Re-verify with the commands at the bottom before trusting it — the deprecations below happened weeks apart.

The four deployed environments

EnvironmentGitHub envPlatformRegion / accountQueue defined inEnv var lives inLast deploy seen
FR stagingdevelopECS Fargateeu-central-1 / 356419207885nothing — hand-createds3://coing-ecs-files/backend-service-libs/dev/services/.env and sqs-consumer/dev/.env2026-08-18
FR productionprodECS Fargateeu-central-1 / 356419207885nothing — hand-createdthe prod/ copies of the same two files2026-08-18
IR stagingstagingEKS / ArgoCDeu-west-1 / 440238706581IAC-Terraform environments/dev/…/9.sqs/conf-values-staging-nls.yaml on the staging branch2026-07-22
US productionuse1-prodEKS / ArgoCDus-east-1 / 890742586475IAC-Terraform environments/production/…/9.sqs/conf-values-prod-nls.yaml on main2026-08-18

Which pipeline goes where, from backend-services/.github/workflows: build-init-develop (tag fr-staging-*) and build-init-prod (fr-prod-*) call the ECS deploy-services-* reusable workflows; build-init-euw1-staging (ir-staging-*) and build-init-use1-prod (us-prod-*) dispatch Kubernetes-deployments/deploy-env.yaml instead, with ref: staging and ref: main respectively. sqs-consumer mirrors this with four deploy workflows of its own.

Two ArgoCD branches — the biggest trap

Kubernetes-deployments is not one config: ArgoCD reads each EKS environment from a different branch.

ApplicationSettargetRevisionValue filesServes
configurations/staging/argocd/argo-appset.yamlstagingvalues-staging-nls.yaml, conf-values-staging-nls.yamlIR staging
configurations/prod/argocd/argo-appset.yamlmainvalues-prod-nls.yaml, conf-values-prod-nls.yamlUS production

main and staging have diverged (208 / 94 commits apart) and both carry both conf-values files, so editing conf-values-staging-nls.yaml on main changes nothing in IR staging. Every env-var change therefore needs two PRs, one per branch — the pattern PRs #411 (main) and #412 (staging) follow. That same pair is also SKILL.md's pulumi cautionary tale: right on the Helm side, wrong on where the queue itself was declared (pulumi/infra/config/*.json instead of IAC-Terraform) — one PR, two lessons.

deploy-env.yaml only bumps image.tag in values-<env>-nls.yaml on the branch it was dispatched against, then pushes; ArgoCD does the rest.

Repo status

RepoStatusEvidence
IAC-Terraformlive — the only SQS owner. environments/{dev,production}/infrastructure/9.sqs/9.N.<name>/applies ran 2026-08-03 and 2026-08-05; 12 queue modules, every queue added this year
Kubernetes-deploymentspackages/helm-charts + configurationslive. Helm values + ArgoCD ApplicationSets for both EKS environmentsdeploy-env.yaml: 58 runs on main (latest 2026-08-18), 2 on staging (latest 2026-07-22)
Kubernetes-deploymentspulumi/deprecated, and a zombie. Deleted from main on 2026-08-03 (3c7c036ff), still present on the staging branch, still collecting dependabot PRs (#1–#5)its create_env.yaml workflow had 0 runs ever; state last written 2024-09-11 (prod) / 2024-04-10 (dev)
Kubernetes-deployments — localstack envdormant. localstack_pipeline.yaml last ran 2025-12-21; backend-services build-init-localstack.yml last ran 2025-12-21skip it; the docker-compose stack in sandbox is the local environment people actually use
with-terraformdead. A partial ECS-service definition (aws_ecs_service service-management-webapp, cluster cluster-dev)last push 2023-05-16, no CI runs; CI now rewrites those task definitions, so its state is pure drift
cdk-infradead — never used. The unmodified cdk init scaffold ("This is a blank project for TypeScript development with CDK")created and last pushed the same day, 2021-12-28
infrastructuredead. Earlier CDK attempt at EKS configlast push 2023-07-09, no CI runs
deploymentdead. docker-compose / apache / fluentd from the pre-cloud eralast push 2022-01-11
sandboxlive, local only. localstack/init-sqs.sh creates the docker-compose stack's queues

ECS queue names follow their own convention. eu-central-1 uses camelCase plus a DEV/PROD suffix — smsQueueDEV.fifo, emailQueuePROD.fifo, notificaitonsCampaignsProd.fifo — nothing like the bewith_dev_* / bewith_prod_* of the Terraform accounts. Which file each task definition reads is discoverable: aws ecs describe-task-definition --task-definition <family> --query 'taskDefinition.containerDefinitions[0].environmentFiles'. The AWS_TASK_ENVIRONMENT_VARIABLES_FILES GitHub secret holds the same list, but it is a secret and cannot be read — go through ECS.

ECS has no live IaC. The FR cluster, its services and its S3 env files are click-ops plus the bewith-dev/aws-ecs-task-definition-creator action in each app repo's deploy workflow. bewith-docs/.claude/agents/devops-infra.md still says ECS is managed "via CDK (cdk-infra) + some Terraform (with-terraform)" — both are dead by the evidence above; treat that line as stale.

Re-verifying

gh run list --repo bewith-dev/IAC-Terraform --limit 10 \
--json createdAt,workflowName,displayTitle,conclusion # applies, and against which project_path
gh run list --repo bewith-dev/Kubernetes-deployments --workflow deploy-env.yaml --limit 60 \
--json headBranch,createdAt --jq 'group_by(.headBranch)[] | "\(.[0].headBranch): \(length) runs, latest \(max_by(.createdAt).createdAt)"'
gh api repos/bewith-dev/<repo> --jq '"\(.name) pushed=\(.pushed_at) archived=\(.archived)"'
git -C Kubernetes-deployments show origin/main:configurations/prod/argocd/argo-appset.yaml | grep -E 'targetRevision|values'

A stale local clone hides all of this: pulumi/ looked alive here purely because the checkout predated its removal. git fetch first, and read origin/main rather than the working tree.