Docs
architectureDeployment topology

Deployment topology

How the platform is deployed across stages and regions.

Hostnames

  • prod: https://<service>.platform.loop.health
  • staging: https://<service>.staging.platform.loop.health
  • dev: https://<service>.dev.platform.loop.health
  • pr-N: https://<service>.pr-<N>.platform.loop.health (only services changed by the PR)

Resolved via @platform/hosts.platformHost({ service, stage }). Never hardcoded.

Per-stage isolation

Each stage has its own:

  • ECS cluster + services
  • Aurora cluster
  • Redis instance
  • EventBridge bus
  • SST Secrets
  • Cloudflare zone subdomain
  • CloudWatch log groups
  • Sentry environment
  • PagerDuty service (prod + staging only)

There is no shared infrastructure between stages. A blast in dev cannot reach prod.

Region

us-east-2 (Ohio) — primary. Chosen to match the legacy Supabase region for the migration period; future expansion to multi-region is on the roadmap.

Blast radius rules

  • One service’s outage shouldn’t take down others (circuit breakers, async events)
  • One stage’s outage cannot affect other stages
  • One brand’s data is logically isolated from others (brand_id filtering)
  • One client’s traffic spike is rate-limited so it can’t starve other clients

What’s NOT isolated per stage

  • CI runners — shared across all stages
  • The Cloudflare zone — platform.loop.health is one zone with subdomains per stage
  • The npm registry (GitHub Packages) — same packages, but stages pull stage-specific tags

Related

OverviewData model