This article describes the proposed architecture where a single Fly.io application serves all groups, with tenant resolution middleware determining which group's database and storage to use per request.
\nflowchart TD\n D1@{ icon: "ngx:user", label: "group-a-ramblers.org.uk", pos: "b", h: 48 }\n D2@{ icon: "ngx:user", label: "group-b-ramblers.org.uk", pos: "b", h: 48 }\n DN@{ icon: "ngx:user", label: "...up to 500 domains", pos: "b", h: 48 }\n\n D1 --> CF\n D2 --> CF\n DN --> CF\n\n CF@{ icon: "ngx:cloudflare", label: "Cloudflare DNS", pos: "b", h: 48 }\n CF --> FLY\n\n subgraph FLY["Fly.io Application - 2 to 4 instances"]\n TM["Tenant Resolution Middleware<br/>Host header to groupCode"]\n CACHE["Domain-to-group cache<br/>refreshed periodically"]\n DBR["Database Router<br/>groupCode to mongoose.useDb"]\n TM --> CACHE\n TM --> DBR\n end\n\n DBR --> MDB1@{ icon: "ngx:mongodb", label: "Group A DB", pos: "b", h: 48 }\n DBR --> MDB2@{ icon: "ngx:mongodb", label: "Group B DB", pos: "b", h: 48 }\n DBR --> MDBN@{ icon: "ngx:mongodb", label: "Group N DB", pos: "b", h: 48 }\n\n MDB1 --> S3\n MDB2 --> S3\n MDBN --> S3\n\n S3@{ icon: "ngx:aws", label: "Single S3 Bucket<br/>/{groupCode}/images/", pos: "b", h: 48 }\n\n style FLY fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143\nYes, this is technically feasible. Fly.io (and most reverse proxies) support binding multiple custom domains and TLS certificates to a single application. The server would inspect the Host header on each request to determine which group context to use. This is a well-established pattern (multi-tenant SaaS).
A user navigating to group-a-ramblers.org.uk vs group-b-ramblers.org.uk would see completely different branding, events, members, and content — unaware they hit the same server.
At 500 groups: Fly.io supports hundreds of custom certificates per app. TLS termination is handled at their edge, so this scales.
\nsequenceDiagram\n participant Browser\n participant Fly as Fly.io Edge\n participant MW as Tenant Middleware\n participant Route as Route Handler\n participant DB as MongoDB (Group A)\n participant SPA as Angular SPA\n\n Browser->>Fly: GET https://group-a-ramblers.org.uk/events\n Fly->>MW: TLS terminated, Host: group-a-ramblers.org.uk\n MW->>MW: lookup("group-a-ramblers.org.uk") to "group-a"\n MW->>MW: req.groupCode = "group-a"\n MW->>MW: req.db = mongoose.useDb("group-a")\n MW->>MW: req.s3Prefix = "group-a"\n MW->>Route: GET /api/database/events\n Route->>DB: Query events (Group A DB only)\n DB-->>Route: Group A events\n Route-->>Browser: JSON response\n Browser->>SPA: Render with Group A config\n SPA->>Route: GET /api/database/config\n Route->>DB: Query config (Group A DB)\n DB-->>Route: Group A branding, settings\n Route-->>SPA: Group A config\n SPA-->>Browser: Group A branded UI\nA critical requirement is that the multi-tenant architecture must coexist with the current per-group deployment model — both running from the same codebase simultaneously. This is achievable using a feature-flagged middleware approach.
\nflowchart TD\n subgraph existing["Existing Groups - per-app deployment"]\n E1@{ icon: "logos:fly-icon", label: "Group A app", pos: "b", h: 48 }\n E2@{ icon: "logos:fly-icon", label: "Group B app", pos: "b", h: 48 }\n E3@{ icon: "logos:fly-icon", label: "Group C app", pos: "b", h: 48 }\n E1 --> ED1@{ icon: "ngx:mongodb", label: "Group A DB", pos: "b", h: 48 }\n E2 --> ED2@{ icon: "ngx:mongodb", label: "Group B DB", pos: "b", h: 48 }\n E3 --> ED3@{ icon: "ngx:mongodb", label: "Group C DB", pos: "b", h: 48 }\n end\n\n subgraph multitenant["New Groups - multi-tenant instance"]\n MT@{ icon: "logos:fly-icon", label: "Multi-tenant app", pos: "b", h: 48 }\n MT --> MD1@{ icon: "ngx:mongodb", label: "Group D DB", pos: "b", h: 48 }\n MT --> MD2@{ icon: "ngx:mongodb", label: "Group E DB", pos: "b", h: 48 }\n MT --> MDN@{ icon: "ngx:mongodb", label: "Group N DB", pos: "b", h: 48 }\n end\n\n IMG@{ icon: "logos:docker-icon", label: "Same Docker Image", pos: "b", h: 48 }\n IMG --> existing\n IMG --> multitenant\n\n style existing fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143\n style multitenant fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143\nHow it works:
\nMULTI_TENANT_ENABLED) controls whether the tenant resolution middleware is activeMONGODB_URI, serves one groupHost header, resolves the group, and switches database context per requestMigration path:
\nMULTI_TENANT_ENABLED=true and a shared admin database containing the domain-to-group lookup tableThis approach means there is no big-bang migration — existing groups continue running undisturbed, and the multi-tenant capability is introduced incrementally alongside them.
\nEvery incoming HTTP request must be mapped to a group context based on the Host header:
At 500 groups: The lookup table is small (500 domain to groupCode pairs). An in-memory Map refreshed every 60 seconds from a shared admin database is sufficient.
\nOption A: Single database, collection-level isolation
\ngroupCode fieldgroupCode filterOption B: Shared connection pool, database-per-group (recommended)
\nmongoose.connection.useDb(groupDbName) to route queries per requestAt 500 groups (Option B):
\nuseDb() reuses the existing connection pool — it does not create new connections{groupCode}/images/... — simpler at scale, recommended for 500 groupsAUTH_SECRET but include groupCode in the JWT payloadgroupCode matches the request's resolved groupCodeCurrent: Each of the 13 Fly.io apps runs its own independent cron jobs.
\nProposed: A single scheduler manages jobs for all 500 groups with controlled concurrency.
\nflowchart TD\n SCHED["Job Scheduler"]\n Q["Job Queue<br/>event-sync, email-send"]\n SCHED --> Q\n Q --> W1@{ icon: "logos:fly-icon", label: "Group A sync", pos: "b", h: 48 }\n Q --> W2@{ icon: "logos:fly-icon", label: "Group B sync", pos: "b", h: 48 }\n Q --> W3@{ icon: "logos:fly-icon", label: "Group C sync", pos: "b", h: 48 }\n Q --> WN["... x 500 groups<br/>concurrency: 3-5<br/>staggered schedule"]\n\n style SCHED fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143\n/api/database/config call would return different data based on which domain was accessedAn environment management admin UI already exists at /admin/environment-management/setup. It provides a multi-step wizard for provisioning new groups:
For the multi-tenant model, this wizard would need to be extended to support provisioning groups within the shared instance (database creation + domain-to-group mapping) rather than creating a new Fly.io app. The core onboarding workflow already exists — it just needs a multi-tenant deployment target alongside the existing per-app target.
\n"}