Infrastructure & Environments

What this is. The canonical map of BeWith's runtime: the two compute platforms, the four environments, how code actually reaches production, where to look when something breaks, and the AI-assisted deploy + on-call we are building toward. It is both an onboarding guide for engineers and an operational reference the platform's agents work against.

Confidence. Confirmed against the bewith-dev GitHub org (deploy-workflow scan, 2026-06-02) and a live Q&A with the Sela (DevOps) team. Where a claim is not yet verified it is marked unconfirmed.

Last updated: 2026-06-02 · Owner: Sela (DevOps) + Engineering Lead · Source: GitHub bewith-dev org + Sela team Q&A

Live launcher

For the clickable links to every app, API, and migration pipeline across all four environments, use the Environments Portal — the live companion to this reference.

---

1. One-paragraph summary

BeWith runs a cloud-native SaaS platform on AWS across two compute platforms that are not equal. Amazon EKS (Kubernetes) is the primary, actively-developed platform and runs the international product line (withsites.com staging, withapps.io production). Amazon ECS (Fargate) is legacy-but-live: it runs the original Israeli product line on coing.co, and — per the Sela team's current plan — stays on ECS for roughly the next six months before any migration is considered. New investment goes to EKS. Deployment today is tag-triggered and person-dependent (a DevOps engineer pushes a git tag from their own machine); making this orderly, person-independent, and partly AI-driven is the platform's stated direction (§10).

---

2. The two compute platforms

EKS (Kubernetes) — primary, international

• Two clusters, both EKS 1.34:
  • bewith-dev-cluster — eu-west-1 (Ireland) — hosts staging.
  • bewith-prod-cluster — us-east-1 — hosts international production. (Region confirmed: us-east-1, despite a stale Confluence page that says us-west-1 — see §9.)
• Node autoscaling via Karpenter (separate node pools for staging vs prod).
• Workloads deployed GitOps-style (ArgoCD + Helm) — see §4.
• ~37 microservices packaged as Helm charts under Kubernetes-deployments (packages/helm-charts/bewith/*): auth, API gateways, communities, orders, payments, notifications, AI/vector-search, and more.
• Adding / managing a service = a change in the Kubernetes-deployments repo (declarative, reviewable).

ECS (Fargate) — legacy, Israeli line

• eu-central-1 (Frankfurt), serving the Israeli product line on coing.co.
• Two clusters: one production, one staging.
• Initial resource provisioning for a service is done once, manually, in the AWS console by the Sela team — and is undocumented today. After that one-time setup, deploys are identical to everywhere else: tag-driven (fr-* tags → the same pipeline). The console is for standing up a service, not for routine deploys. (A repo-driven model for the provisioning step — like EKS — is an explicit near-term goal, §10.)
• Legacy IaC lives in cdk-infra (AWS CDK, TypeScript), frozen since 2021. Treat it as historical, not current.

---

3. The four environments

Environment	Platform	Region	Cluster	Public domain	Product line
ECS FR Staging	ECS Fargate	eu-central-1 (Frankfurt)	ECS staging cluster	staging.coing.co	Israeli
ECS FR Production	ECS Fargate	eu-central-1 (Frankfurt)	ECS prod cluster	coing.co	Israeli
EKS IR Staging	EKS / Kubernetes	eu-west-1 (Ireland)	bewith-dev-cluster	*.withsites.com	International
EKS US Production	EKS / Kubernetes	us-east-1	bewith-prod-cluster	*.withapps.io	International

Reading the names (this trips people up)

• FR = Frankfurt = eu-central-1 · IR = Ireland = eu-west-1
• Terraform names: staging = dev_euw1 (eu-west-1) · US prod = prod_use1 (us-east-1)
• The (IL) / (US) tags on Confluence refer to the business/product line, NOT the AWS region. The IL line runs in Frankfurt; the international line runs in Ireland + us-east-1.
• The deploy tag prefixes encode this same mapping (§4): fr-* → Frankfurt/ECS, ir-* → Ireland/EKS staging, us-* → us-east-1/EKS production.

Per-environment quick facts

• EKS IR Staging — the primary validation environment for new/international features. Datadog env tag eks-staging. MongoDB cluster with-dev.
• EKS US Production — international production. Grafana available (behind Pritunl VPN). Base node group 3× t2.medium + Karpenter capacity.
• ECS FR Staging / Production — the coing.co (Israeli) line. Production MongoDB cluster WithCluster1.
• All four environments are fully separate (staging/prod × IL/USA) — separate infra, no shared state.

---

4. How code gets deployed

The single most important operational fact: there is no uniform deploy mechanism across repos. The dominant model is tag-triggered, but branch model, tag pattern, and even target platform vary per repo — and the same repo can deploy to ECS in one region and EKS in another. The per-repo truth is in the appendix. Both the inconsistency and the person-dependence are things the platform aims to fix (§10).

The dominant model: tag-triggered

1. PR is opened against a working branch. Most repos use master + tags; management-webapp uses develop; backend-services staging and superco-management staging still lean on a develop branch; the infra/ops repos use main.
2. A git tag matching a recognised glob triggers the CI/CD pipeline, which builds and deploys. The tag is pushed by hand, via a git command from the DevOps engineer's own machine. The source of truth for "what is deployed" is the tags, not a dashboard — this person/machine dependence is the core pain the deploy-platform initiative removes (§10).
3. To deploy production: merge the integration branch → master, then push the prod tag.

Tag convention (the deploy contract)

The org standard is <region>-<stage>-<feature>:

Tag glob	Target	Platform	Region
fr-prod-*	Israeli production	ECS	Frankfurt (eu-central-1)
fr-staging-*	Israeli staging	ECS	Frankfurt
ir-staging-*	International staging	EKS	Ireland (eu-west-1)
us-prod-*	International production	EKS	us-east-1

The Slack notification steps parse this with cut -d'-' -f1/-f2/-f3- (env / stage / feature). Outlier: cognito-lambdas uses bare prod-* / staging-* / develop2-* with no region prefix — the one repo that breaks the convention.

What each tag actually does

• fr-* (ECS): build Docker image → push to ECR → register a new ECS task definition and update the service. Most repos use the shared bewith-dev/aws-ecs-task-definition-creator action; facility-rentals diverged to inline task-def JSON + raw aws ecs CLI.
• us-* / ir-* (EKS): build → push to ECR → call convictional/trigger-workflow-and-wait into Kubernetes-deployments' deploy-env.yaml, which bumps the image tag in values-<env>-nls.yaml and commits. ArgoCD then reconciles the cluster to match Git.
• The ECS↔EKS split is per-region, not per-repo: backend-services, superco-consumer, and organization-dashboard all deploy their fr-* to ECS and their us-*/ir-* to EKS. A single repo therefore targets both platforms.

EKS specifics (GitOps)

• Charts: Kubernetes-deployments → packages/helm-charts/bewith/*. ArgoCD ApplicationSets (configurations/{prod,staging}/argocd) generate one Application per chart per env.
• ArgoCD sync is automated (selfHeal: true, prune: true, CreateNamespace: true) — manual kubectl edits get reverted. To change prod you change Git.
• The running image tag per EKS service is readable from values-<env>-nls.yaml — the cheapest read-only "what's running on EKS" signal.
• Karpenter NodePool/NodeClass under apps/provisioners. Secrets via Pulumi (shared-pulumi-secret chart + pulumi/).

ECS specifics (Israeli line)

• One-time resource provisioning is manual (AWS console, undocumented); routine deploys are tag-driven (fr-* → Docker→ECR→task-def), identical to the rest of the org.
• "What's running" lives in the ECS task definition (image tag), not in a repo — no values.yaml to read. A read-only signal here is an open item (§ open items).

Cross-cutting deploy facts

• No partial deploy today — deploys are effectively all-or-nothing. Independent per-service deploy is a wanted capability (§10).
• No deploy ordering needed — every service has retry + blue/green deployment, so inter-service order is not load-bearing.
• Rollback has no special machinery: take the commit you want live, tag it, and the deploy runs. There is no maintained "last-good" branch — you point the tag at the commit you want.
• Approval gate: only Aviad, Baruch, and Shimon can approve a merge and trigger a deploy.
• Slack on deploy is wired on most ECS/EKS backend+frontend pipelines; absent on cognito-lambdas, superco-management, with-calendar, leaders-app, migrations-tool, and the infra repos.
• Mobile is not tag-CI: leaders-app deploys via manual workflow_dispatch (builds signed Android AAB/APK + unsigned iOS, attaches to a GitHub Release, env via dart_define_env); consumer-mobile has no workflows — a manual build.sh. Mobile deploy is being automated in parallel; its dedicated doc will come from the leaders-app repo.
• No CI deploy / no workflows: with-agents-platform and crm-integration are CI-only (build/test, no deploy); superco-management-17, bewith-consumer-frontend, bewith-website, loki-cloudwatch-forwarder have no workflows (frontends likely deploy via an external host); assistant-ai is an empty repo.
• See also the CI-gate survey in Uniform CI.

---

5. Version management (current state + gap)

• Versions are managed manually against the last version, and a version is not always set at all — no system tracks "what version is where", and there are no consistent release notes.
• EKS: derivable today by reading image tags in Kubernetes-deployments values-*.yaml.
• ECS: lives in the task definition; not currently readable from a repo. (Stop-gap already in flight: support-tool now prints its commit SHA in the browser console — a first step toward making the running version visible.)
• Desired state (§10): a clear, automated SemVer bump + release notes on every prod deploy, with that version threaded through the stack (startup log, /version endpoint, console.log, request headers) and persisted as a queryable record — so "what version is where" and "which backend is this app talking to" become answerable for debugging and dependency management. Plus the person-independent deploy/rollback platform (any version, full or partial, any env, any app) with a progress UI. See §10 for the proposed shape.

---

6. Infrastructure as Code

• IAC-Terraform (main) is the Terraform repo: environments/{dev,production}/infrastructure/ numbered by concern (1.vpc … 11.cloudfront), plus modules/. State in S3 with versioning, isolated per env/project. Existing AWS resources were imported into state rather than recreated.
• It does have apply pipelines: two manual workflow_dispatch workflows (terraform-dev, terraform-prod) that run terraform plan/apply per environment.
• But the Sela team's nuance matters: routine infra change is not driven by these. "Adding a server" is done in USA via the Kubernetes-deployments repo and in IL manually via the AWS console; service deploys are driven by tags. Treat IAC-Terraform primarily as the imported state-of-record; verify any infra claim against the live cluster + Terraform rather than assuming the apply pipeline is the routine operational path.
• Two older IaC repos — with-terraform (2023) and cdk-infra (2021) — are legacy; do not treat as current.
• The DevOps function is internally called the "Sela" team.

---

7. Cross-cutting infrastructure

• Edge: Cloudflare — WAF, DDoS mitigation, CDN, TLS termination.
• Load balancing: AWS ALBs in front of the gateway services.
• Databases: Aurora / RDS (relational); MongoDB Atlas (with-dev for IR staging, WithCluster1 for the Frankfurt prod line); S3 (object/static); ElastiCache (cache).
• Identity/auth: Amazon Cognito (+ cognito-lambdas) — auth, MFA, SSO-compatible flows.
• DB migrations: migrations-tool — one manual workflow_dispatch workflow per env (fr-prod, fr-staging, ir-staging, us-prod) running a Node migration CLI; LocalStack for local testing.
• Observability: see §8 — mid-migration Datadog → Grafana/Loki.

---

8. Observability — where to look when something breaks

State: mid-migration from Datadog to Grafana Cloud (Loki). The destination differs by platform right now — know which one to query.

Signal	EKS (international)	ECS (Israeli)
Logs (today)	Datadog (stdout → Datadog HTTP API). Grafana/Loki has no EKS log data yet (in progress).	stdout JSON → CloudWatch → Lambda subscription (transform + enrich) → Grafana Cloud / Loki. The JSON→Loki path is ECS-only today.
Metrics	Datadog	Datadog / CloudWatch
Infra alerts	Grafana (being set up)	CloudWatch
App alerts	Datadog (not yet migrated to Grafana)	Datadog

• loki-cloudwatch-forwarder (main, new May 2026) is the AWS Lambda doing the CloudWatch→Loki forwarding with structured-label promotion.
• No on-call rotation today. Alerting = a CloudWatch alert monitor + application alerts in Datadog (to be migrated to Grafana). Filling the on-call gap is what the Sentinel agent is for (§10).
• Migration end-state: consolidate on Grafana/Loki; no committed timeline — actively in progress. Until EKS logs land in Loki, EKS log investigation still requires Datadog.
• Practical rule: EKS issue → start in Datadog. ECS issue → Grafana/Loki (logs) + CloudWatch (alarms). Verify the platform of the affected env first (§3).

Recurring incident types (seed list — to grow)

• Tenant subdomain misconfiguration — a customer's custom subdomain not wired correctly. Diagnosed with a dig check + endpoint indications. A strong candidate for an automated per-tenant health probe (§10). (More incident types will be added by the team over time.)

---

9. Known documentation drift (verify before trusting older docs)

1. ADR-001 (docs/adrs/adr-001-aws-ecs.md, 2024) still records ECS Fargate as the primary platform ("small team, <20 services"). Reality: EKS is primary, ~37 services. Should be marked superseded.
2. Customer-facing "Client-Facing Security, Login & Infrastructure Overview" (Confluence, Mar 2026) describes the app layer as "AWS ECS Application Services." This is the most sensitive drift — it's shared externally while international production runs on EKS. (It is correct for the Israeli line, which is genuinely ECS — but it should distinguish the two.)
3. Confluence "Environments links" page uses confusing (eu-west-1)(US) / (eu-center-1)(IL) labels and lists US prod region as us-west-1. Confirmed correct region: us-east-1 (Terraform prod_use1). Page should be corrected.
4. For balance: the SSDLC Confluence doc is already correct ("deployed on AWS EKS"). Documentation is a mix of fresh and stale — verify the platform claim against Terraform + the live cluster, not a single page.

---

10. Where we're going — AI-assisted deploy + on-call

Two initiatives, both with human-in-the-loop where it matters:

A. A person-independent deploy / version platform

Replace "a tag pushed from one engineer's machine" with an orderly system that can:

• deploy or roll back any version, full or partial, to any environment (IL / USA), for any app;
• show a UI of pipeline progress, surface which stage failed, and re-run from the failed stage (even though retries exist);
• bring the Israeli/ECS line onto a repo-driven model (like EKS today), so IL is no longer maintained by hand in the console — IL stays on ECS for ~6 months, full EKS migration is a possible later step;
• send status notifications (Slack / email, group or personal).
• Builds on the existing "tag-on-success + Slack notify" workflows already present in several repos, and on the Kubernetes-deployments deploy-env.yaml trigger as the EKS apply primitive.

B. "Sentinel" — an AI on-call agent

A continuously-listening agent that ingests Datadog metrics + logs + ClickUp, automatically triages by severity/service, and acts:

• opens a ClickUp bug,
• updates a Slack on-call channel,
• applies known auto-fixes.

Sentinel fills the current no-on-call gap. New detectors and fixes are meant to ship as single PRs — cheap to extend as the team feeds in more incident types.

C. Versioning & release-notes standard (proposed)

Layered on top of the existing tag-driven deploy — the deploy mechanism does not change. The goal: every prod deploy has a SemVer version and release notes, and that version is visible and queryable everywhere.

1. Version source — automated SemVer + release notes. Conventional Commits drive an automated release tool (e.g. release-please / semantic-release / changesets) that, on merge to the prod-bound branch, bumps the SemVer and generates CHANGELOG.md + a GitHub Release. Tool choice TBD (lean on what already works in practice).
2. Build-time stamping. Each build injects version, commit, builtAt, env into the artifact (build arg → runtime config).
3. Expose it via standard contracts:
   • Backend: log version at startup + a GET /version (or extend the health endpoint) + a structured service.version log field.
   • Frontend: a version.json + a console.log banner (already started in support-tool) + visible in an About/footer.
   • Mobile: already carries v<version>+<build>; log it.
   • Cross-talk: clients send an X-Client-Version header; the backend logs both client.version and its own service.version — so logs in Loki/Datadog are filterable by version, and "which app is talking to which backend" is answerable.
4. Persist it (the durable, reusable record). An append-only deployment record — {service, env, version, commit, time, actor} — kept where it can be queried (a manifest in Kubernetes-deployments, a small ledger repo, or a datastore). This becomes the single answer to "what version is where", covers the ECS/IL visibility gap (the deploy workflow writes the record instead of relying on the console), and feeds the deploy-platform UI + Sentinel.

Rolled out repo-by-repo (uniform-CI style), piloted where momentum already exists (support-tool, backend-services).

The AI's operating boundary (Sela team decision, current phase)

• ✅ Read everything (logs, metrics, repos, endpoints).
• ✅ Open PRs — including PRs that bump an image tag in values-*.yaml.
• ❌ No creating tags, no deploys at this stage. A human (Aviad / Baruch / Shimon) reviews and triggers the tag/deploy.
• Cluster access is not granted now; logs + endpoints cover most needs. More capabilities (read-only ArgoCD sync status, read-only CloudWatch alarms) can be added later as the need is shown.

---

11. Keys & accounts the AI platform needs

Read-only access to the signals — no deploy/tag credentials.

Capability	What's needed	Status	Notes
Logs/metrics — Grafana/Loki	Grafana API key (read)	Offered	Covers ECS logs + infra; EKS logs not yet in Loki
Logs/metrics — Datadog	Datadog API + App key (read)	Offered	Required for EKS logs/alerts until Loki migration completes
Source / config read	GitHub read on bewith-dev	✅ Have	Repo scan, values-*.yaml, workflows
PR creation	GitHub write (PR only)	✅ Have	No tag/deploy permission — by design
ClickUp	API token (read + create task)	Have (MCP)	Sentinel: open bugs, triage
Slack	Bot token (post to on-call channel)	Have (MCP)	Sentinel + deploy notifications
(later) ArgoCD sync/health	Read-only API/token	Deferred	Confirm a deploy succeeded / detect drift
(later) CloudWatch alarms	Read-only IAM	Deferred	Primary alert signal today
(later) ECS "what's running"	Read-only ECS / task-def export	Open	No repo-readable source for IL image tags today

---

12. Key repositories

Repo	Role	Default branch
IAC-Terraform	Terraform infra (state-of-record + manual plan/apply workflows)	main
Kubernetes-deployments	EKS GitOps — ArgoCD, Helm charts, Karpenter, Pulumi secrets; deploy-env.yaml apply primitive	main
loki-cloudwatch-forwarder	CloudWatch → Grafana Loki log shipping (Lambda)	main
migrations-tool	Per-env DB migration pipelines (manual dispatch)	master
cdk-infra	Legacy ECS infra (frozen 2021)	master
with-terraform	Legacy Terraform (2023)	master
backend-services	Main NestJS/Node backend monorepo (ECS for fr-*, EKS for us-*/ir-*)	master
superco-consumer	PHP (Yii2) consumer app — Israeli line (ECS + EKS split)	master
superco-management / -17	Angular management apps (-17 has no workflows)	master
management-webapp, organization-dashboard, support-tool-frontend, bewith-consumer-frontend	React/Next frontends	develop / master
consumer-mobile, leaders-app	Flutter mobile apps (deploy manual today — being automated)	master
assistant-ai, with-agents-platform, crm-integration	Python services (CI-only / empty)	master
cognito-lambdas	Cognito auth Lambdas (SAM; non-standard tag globs)	master

---

Appendix — deploy mechanism per repo

Source: scan of each repo's .github/workflows, 2026-06-02. Archived/template repos omitted.

Repo	Default branch	Deploy trigger	Staging vs prod	Target platform	Auto-tag / Slack
backend-services	master	push: tags fr-prod-* fr-staging-* us-prod-* ir-staging-*	per-env workflow, tag prefix selects	fr-* → ECR+ECS; us-*/ir-* → EKS via K8s deploy-env.yaml	Slack on every workflow
superco-consumer	master	push: tags fr-prod-* fr-staging-* us-prod-* ir-staging-*	per-region workflow	fr-* ECS; us-*/ir-* EKS; runs Yii migrations	Slack on deploy
superco-management	master (staging fires on develop)	prod push: tags fr-prod-*/us-prod-*; staging push: branches: develop	prod=tag, staging=branch	static: npm build → S3 + CloudFront invalidation	none
superco-management-17	master	—	—	—	no workflows
management-webapp	develop	push: tags fr-prod-* fr-staging-* us-prod-*	per-env workflow	Docker→ECR + ECS task-def (creator action)	Slack on build+deploy
organization-dashboard	master	push: tags fr-prod-* fr-staging-* us-prod-* ir-staging-*	per-env workflow	fr-* ECS; us-* EKS via K8s	Slack on deploy
support-tool-frontend	master	push: tags fr-prod-* fr-staging-* us-prod-* ir-staging-*	per-env workflow	Docker→ECR + ECS task-def	Slack on deploy
bewith-consumer-frontend	master	—	—	likely external host (Vercel?)	no workflows
consumer-mobile	master	— (manual build.sh)	—	Flutter mobile	no workflows
leaders-app	master	workflow_dispatch (manual)	env via dart_define_env input	Flutter — signed AAB/APK + iOS → GitHub Release	creates v<version>+<build> tag; no Slack
with-agents-platform	master	push: [main, develop] + PR (path agent-runtime/**)	none — CI only	docker build local, no push	none
assistant-ai	master	—	—	—	empty repo
crm-integration	master	push/PR on master — pytest	none	CI only	none
sqs-consumer	master	push: tags fr-prod-* fr-staging-* ir-staging-*	per-env workflow	Docker→ECR + ECS task-def (creator action)	Slack on deploy
cognito-lambdas	master	push: tags prod-* staging-* develop2-* (+ euw1/use1 variants)	per-env workflow	AWS Lambda via SAM	none
with-calendar	master	push: branches: master + workflow_dispatch	none	npm publish → GitHub Packages (Changesets)	auto-creates v<semver> tag; no Slack
facility-rentals	master	push: tags fr-prod-* fr-staging-* (euc1/euw1/use1)	per-env/region workflow	Docker→ECR + ECS (inline task-def JSON + aws ecs CLI)	Slack on deploy (webhook from Secrets Manager)
bewith-website	master	—	—	likely external host	no workflows
loki-cloudwatch-forwarder	main	—	—	TS Lambda (esbuild); no in-repo CD	no workflows
migrations-tool	master	workflow_dispatch (fr-prod/fr-staging/ir-staging/us-prod)	one manual workflow per env	Node migration CLI on self-hosted runner	none
Kubernetes-deployments	main	workflow_dispatch (deploy-env.yaml, called by app repos)	env passed as input	bumps Helm values-<env>-nls.yaml image tag, commits → ArgoCD applies (EKS)	none
IAC-Terraform	main	workflow_dispatch (terraform-dev/terraform-prod)	per-env workflow	terraform plan/apply against AWS	none

Deploy models (grouped)

• A. Tag → ECR → ECS (direct task-def): management-webapp, support-tool-frontend, sqs-consumer, facility-rentals, + the fr-* legs of organization-dashboard / superco-consumer / backend-services. Dominant pattern; most use the shared aws-ecs-task-definition-creator action (facility-rentals is the exception — inline JSON).
• B. Tag → ECR → EKS (via Kubernetes-deployments): the us-*/ir-* legs of backend-services, superco-consumer, organization-dashboard. Build+push then trigger-workflow-and-wait into deploy-env.yaml.
• C. Tag → Lambda (SAM): cognito-lambdas (non-standard tag globs).
• D. Tag → S3/CloudFront (static): superco-management (prod).
• E. Branch-push deploy: superco-management staging (develop→S3); with-calendar (master→npm). Inconsistent with the tag norm.
• F. Manual workflow_dispatch: leaders-app, migrations-tool, IAC-Terraform, Kubernetes-deployments.
• G. CI-only (no deploy): with-agents-platform, crm-integration.
• H. No workflows: superco-management-17, bewith-consumer-frontend, consumer-mobile, bewith-website, loki-cloudwatch-forwarder; assistant-ai is empty.

Inconsistencies to be aware of

• Three default-branch conventions: most master; management-webapp is develop; the three infra repos are main.
• develop lingers in two places only: backend-services staging pins reusable workflows @develop, and superco-management staging fires on a develop push. Everywhere else it's master + tags.
• ECS↔EKS split inside one repo (backend-services, superco-consumer, organization-dashboard) — region prefix decides the platform, not the repo.
• Tag-glob outlier: cognito-lambdas (prod-*/staging-*, no region prefix).
• Task-def mechanism drift: shared action (most) vs inline JSON + CLI (facility-rentals).
• Slack coverage is partial — missing on cognito-lambdas, superco-management, with-calendar, leaders-app, migrations-tool, infra repos.

---

Open items

Genuine information gaps — not proposals to change anything. The deploy patterns above are documented as-is; they are the established, repeatable process and stay that way.

1. ECS "what's running" read path — for EKS the running image tag is readable from values-*.yaml; for IL/ECS the running version lives only in the ECS task definition inside AWS. Is there any source outside the AWS console to read "which version is running in IL"? If not, IL version-visibility waits on a read credential or the repo-driven model.
2. Recurring incident types — the seed list (§8) will grow as the team feeds in more; each becomes a Sentinel detector.

Mobile deploy is being automated in parallel (work in progress). Its deployment doc will be authored from the leaders-app repo itself, not reverse-engineered here.