Atmos Pro + release engineering for app repos using app-on-ecs-v2 template

[jaguer0]

Context

We already have Atmos Pro working on our infra repo. Now that workload Terraform lives in source code repos per the app-on-ecs-v2 pattern, we need to figure out how Atmos Pro and release engineering should tie together for these repos.

We created our repo from the app-on-ecs-v2 template yesterday and have wired up profiles, backends, and dependencies — deploys are working. We're on OpenTofu 1.11.2, Atmos v1.213.0, and using native CI (all from the latest template defaults).

The template ships with feature-branch.yml, main-branch.yaml, and release.yaml workflows for Docker build → test → deploy.

Questions

1. Same setup as infra? Is it just a matter of following the same Atmos Pro setup docs / copying what we did for our infra repo? Or is there anything additional we need to modify in the existing feature-branch/main-branch/release workflows?

2. Existing GHA for this? Are there existing GHA workflows designed for release engineering + Atmos Pro together, or is that something we need to wire up ourselves?

3. Atmos profiles — The template ships with a single github profile. We'll need to create separate github-plan and github-apply profiles for Atmos Pro, correct?

---

Side follow-up: multi-region

When we approach multi-region deployments, will the native CI just work? We plan on using environment names that match our infra repo convention (e.g. plat-use2-dev, plat-use2-staging, plat-use2-prod).

I noticed several places with hardcoded region references:

• Stack defaults — backend references for region in _defaults
• Dependencies — e.g. terraform/stacks/deps/vpc.yaml
• OIDC provider in atmos.yaml — region is set directly:

  providers:
    github-oidc:
      kind: github/oidc
      region: us-east-2
      spec:
        audience: sts.amazonaws.com

[milldr]

We haven't set up or validated Atmos Pro for the ECS app yet. That said, you're welcome to give it a shot — the approach should be the same as with the Terraform components: add the settings.pro configuration to your stacks to tell Atmos Pro which workflows to dispatch for each event.

The key difference here is that the workflows themselves would be different. Rather than dispatching Terraform plan/apply workflows, you'd be pointing to the ECS app workflows — feature-branch.yml on pull request events, main-branch.yml on merge, and release.yml on release. The inputs would also differ depending on what those workflows expect.

We haven't validated this yet, but if you'd like to give it a shot, we'd be happy to discuss it at a workshop.

[osterman]

I think we can knock out an example for this next week sometime. I was planning to add an example of this as well.

[jaguer0]

Thanks for the atmos-pro-with-ecs example repo, Erik! I'll close this out for now and give it a spin tomorrow.

[osterman]

@jaguer0 just a heads up, it's not fully fleshed out yet. There is something I haven't solved, which is how a label could be used conditionally to trigger a preview deployment. Definitely feel free to use this as a place to start off, but it's not yet something you can just take and run with.