Skip to content
Flowright Docs

Multi-tenant SaaS

The most involved starter: a multi-tenant SaaS with a WAF at the edge, blue/green ECS deploys, a shared Aurora pool for small tenants plus per-tenant RDS silos for the big ones, an EventBridge bus, and secrets supplied at apply.

The shape

Section titled “The shape”
  1. WAF → ALB → ECS at the front, with blue/green deploys driven by a pipeline.
  2. A shared Aurora cluster (the pool) for the long tail of tenants.
  3. Per-tenant RDS silos for tenants that need isolation — this is where typed sockets earn their keep: each silo is wired to the service on its own port, so the generated Terraform references the right database for the right tenant, never “the first one it finds”.
  4. An EventBridge bus for cross-service events.
  5. Secrets (DB credentials, API keys) are wired as ${var.x} references — never stored, supplied at terraform apply from your vault.

Why this is the disambiguation test

Section titled “Why this is the disambiguation test”

With several IAM roles and several databases, type-by-name resolution breaks. Flowright’s typed named sockets bind each reference to a specific node, which is exactly what keeps a per-tenant silo topology correct through the byte-perfect round-trip.

Environment isolation

Section titled “Environment isolation”

Export this as a directory-per-environment project: shared modules/ for the topology, and environments/{dev,staging,prod}/ each with its own backend and state. An apply in prod can never touch dev. Attributes that vary by environment (instance sizes, tenant lists) are lifted to per-env variables.

environments/prod/main.tf
module "platform" {
  source            = "../../modules/platform"
  ecs_desired_count = 6
  aurora_instances  = 3
  enable_waf        = true
}

Next

Section titled “Next”