[Epic] Evergreen Tracks for Cloud Anywhere

Context

Evergreen Tracks (#35693) shipped for the dotCMS-managed AWS fleet: 4 prod EKS clusters under ArgoCD GitOps, with a per-cluster windowed reconciler that rewrites the image line on master and lets ArgoCD roll the tenant. That mechanism assumes we own the cluster, the GitOps repo, and the secret store.

Cloud Anywhere customers get none of it. Cloud Anywhere runs dotCMS on EKS inside the customer's own AWS account, outside our AWS Organization. Today that is 2 accounts:

Customer	AWS account	Region	Cluster	GitOps
Junior Achievement	726769512399	us-west-2	dotcms-junior-achievement	none
TRF	(trf profile)	us-east-1	own EKS	none

Why this is filed: the Junior Achievement case

Asked whether we could roll the evergreen reconciler onto JA. Audited it 2026-08-17 (infrastructure/terraform/cloudanywhere/juniorachievement/, kubernetes/cloudanywhere/juniorachievement/). Permissions turned out not to be the blocker — the architecture is:

1. No ArgoCD. JA has no entry under kubernetes/cluster/ — no argocd-install, no argocd-apps. Manifests are applied by hand; jaupdates.txt is literally a hand-maintained list of the two files to kubectl apply. The reconciler would commit an image bump to master and nothing would happen.
2. Zero-downtime gate fails. Neither statefulset sets TOMCAT_REDIS_SESSION_ENABLED. Per the locked spec that is a hard skip-and-report. (replicas: 2 passes.)
3. Secret is cross-account and cross-region. sh/evergreen-tracks-reconciler/github-app lives in the cloud account (948170117212), us-east-1 primary with ca-central-1 / eu-central-1 / ap-southeast-2 replicas. JA is a different account in us-west-2. Closing that gap means either a us-west-2 replica plus a cross-account resource policy, or placing a GitHub App private key with write access to dotCMS/infrastructure-as-code inside a customer-owned AWS account. That is a security decision, not a permission.
4. Not a subscriber. No dotcms.cloud/evergreen-track label; the CX sheet lists only BCBS, Lennox, and Suny Cortland, all on our fleet.

What does already exist in JA and would be reusable: an EKS OIDC provider, EKS_JA_ReadSecretsRole scoped to system:serviceaccount:juniorachievement:*, and a live Secrets Store CSI SecretProviderClass. AWS access is via StrongDM plus IAM keys in Keeper (junior achievement) — obtainable, just not widely held.

Position: Cloud Control is the better long-term answer

I want to be straight about this rather than quietly scoping the work.

Building the reconciler into Cloud Anywhere means, per customer account: standing up a GitOps controller we don't currently run there, replicating or duplicating our GitHub App credential into someone else's account, widening IRSA, and then owning drift across N bespoke environments forever. Every Cloud Anywhere account is a snowflake, and the cost is linear in customers while the benefit is capped by how few of them there are.

Cloud Control already solves the same problem structurally — it is a platform we operate, with central image control and an existing reconciler mechanism, and it is where new environments are being provisioned. Migrating Cloud Anywhere customers onto Cloud Control gets them Evergreen Tracks as a platform feature instead of as per-account plumbing, and retires the snowflakes at the same time.

The honest counter-argument, stated fairly: some customers chose Cloud Anywhere specifically because the workload must live in their account (data residency, procurement, existing AWS commitments). For those, migration isn't on the table and they will need something. That's why option B below exists — as a fallback for a specific contractual constraint, not as the default.

Options

A. Migrate Cloud Anywhere onto Cloud Control (preferred). Tracks come for free. Retires two bespoke environments. Requires confirming Cloud Control can satisfy whatever drove each customer to Cloud Anywhere.

B. Minimal per-account reconciler (fallback). Only if a customer contractually cannot leave their own account. Prereqs, in order: a sync mechanism in-cluster, the Redis session gate met, a credential story that does not put our IaC write key in a customer account (deploy key scoped to a single repo, or invert to pull-based).

C. Explicitly exclude Cloud Anywhere and document it (interim, do this now regardless). Cloud Anywhere customers are not eligible for Evergreen Tracks today. Say so in the docs and the CX sheet rather than leaving it ambiguous.

Recommendation: C immediately, then A. Do not start B without a named customer and a signed constraint.

Open questions

• Does Cloud Control support a customer-owned-account or data-residency-constrained deployment today? If not, that gap — not the reconciler — is the real blocker for A.
• Why did JA and TRF choose Cloud Anywhere? If the reasons are historical rather than contractual, A is straightforward.
• Who decides when an image moves inside a customer-owned account? Evergreen Tracks assumes dotCMS holds that trigger. In Cloud Anywhere the customer may reasonably expect to.
• Are more Cloud Anywhere deals in the pipeline? If yes, this gets more urgent; if no, C may be the permanent answer.

Non-goals

• Not reopening the v1 reconciler scope (IaC#8098) — that stays closed out on the AWS fleet.
• Not the promote engine (#36520, #36160) or the tracks control-plane.
• Not a StatefulSet → Deployment migration.

Related

• Epic #35693 — Release Tracks: per-environment update channel selection
• #36653 — floating-tag drift / cluster reconciler
• IaC#8098 — reconciler v1 sub-epic
• IaC#7990 — Cloud Control context

Start by reviewing infrastructure/terraform/cloudanywhere/juniorachievement/ and kubernetes/cloudanywhere/juniorachievement/, then read the linked Evergreen Tracks and Cloud Control issues. Resolve the customer-account and data-residency constraints, and define whether the outcome is documented exclusion, migration onto Cloud Control, or a specifically scoped fallback.