# Shared CloudFormation stacks

Apps do not write their own infrastructure from scratch. They pick an
**archetype** — the deployment policy envelope defined in aws-bootstrap
that bounds what the deployer may provision in the account — and compose
**fragments**, the published templates in Switchboard's catalog, shipping
artifacts into their shape. Archetype and fragment are different axes and
are never used for each other.

| Stack | Owner | What it provides |
|---|---|---|
| connection template | Switchboard | per-account access: `SwitchboardAccess`, the permission boundary, the event forwarder, a conditional GitHub OIDC provider, and — in a devops account — the artifact buckets |
| `data-plane-core` | Switchboard | per-environment plumbing: config store, event bus, KMS — installed when the environment is provisioned |
| archetypes (`api-lambda-dynamo`, `s3-cdn`, `stackset`, `atlas-lakehouse`, …) | aws-bootstrap | the policy envelope the deploy runs under: its carrier fragment creates the `cfn-svc-{archetype}-{env}` stack role the deploy is passed |

Conventions your stack must follow:

- **Tags are the interface.** Instance resources carry `awsApplication`
  (so they group in myApplications) and the `swb:tenant / swb:env /
  swb:app / swb:scope` tags on exec roles (workload identity scope comes
  from tags). Public surfaces carry `swb:endpoint` — see
  [endpoints](/endpoints).
- **Outputs are read back.** Component versions (`landedPins`) and
  anything a custom resource produces surface as stack outputs; the
  deploy read-back records them on the instance.
- **Custom resources carry the odd jobs.** Anything the old deploy
  workflows did that is not CloudFormation belongs in a custom resource —
  the Zuplo gateway and dev portal deploy through `Custom::ZuploProject`
  in the app's own CDK.

Templates and their locations are catalogued per repo in the
console's Repositories page; the construction-phase plugin will carry the
per-archetype how-to.