{"id":"69bb05e83f1c7d8bc1820635","title":"2026 03 18 Single Instance Multi Tenant Exploration","path":"how-to/technical-articles/2026-03-18-single-instance-multi-tenant-exploration","contentMarkdown":"# Single-Instance Multi-Tenant Architecture Exploration\n\n\n\nRamblers head office is in discussions about adopting NGX Ramblers as a solution to roll out to groups nationally. **The primary driver is the Brevo email integration** — Ramblers Head Office wants to offer groups a ready-made email solution (newsletters, walk notifications, booking confirmations) without each group having to set up and manage their own email infrastructure. One of their preferences is that a single NGX instance could serve multiple groups rather than the current model of one deployment per group. **Scale target: up to 500 groups.**\n\n\n## Target Architecture — outlined more detail in the following articles\n\n```mermaid\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
Host header to groupCode\"]\n CACHE[\"Domain-to-group cache
refreshed periodically\"]\n DBR[\"Database Router
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
/{groupCode}/images/\", pos: \"b\", h: 48 }\n\n style FLY fill:#E8F5EE,stroke:#9BC8AB,stroke-width:2px,rx:12,ry:12,color:#404143\n```\n\n\n_____\n\nThis series of articles explores what would be required to re-architect NGX Ramblers so that any number of groups run off a single application instance, while maintaining the same segregated user experience — where navigating to a group's domain shows only that group's branding, members, walks, and content.\n\n\n## Platform Overview\n\nWhat NGX Ramblers provides beyond email — walks, bookings, galleries, CMS, and more\n\n![](https://ngx-ramblers.org.uk/api/aws/s3/site-content/fb7500d8-1a94-4527-a62f-969e5843f960.jpg)\n\n## Current Architecture\n\nHow the per-group deployment model works today — one Docker image, 13 independent apps\n\n![](https://ngx-ramblers.org.uk/api/aws/s3/site-content/fb7500d8-1a94-4527-a62f-969e5843f960.jpg)\n\n## Proposed Architecture\n\nSingle-instance multi-tenant design — tenant resolution, database switching, request lifecycle\n\n![](https://ngx-ramblers.org.uk/api/aws/s3/site-content/fb7500d8-1a94-4527-a62f-969e5843f960.jpg)\n\n## Brevo Email at Scale\n\nThe primary rollout driver — outbound email, deliverability, and multi-tenant email isolation\n\n![](https://ngx-ramblers.org.uk/api/aws/s3/site-content/fb7500d8-1a94-4527-a62f-969e5843f960.jpg)\n\n## Billing and Costs\n\nFly.io free-tier analysis, cost comparison at 500 groups, and billing risk assessment\n\n![](https://ngx-ramblers.org.uk/api/aws/s3/site-content/fb7500d8-1a94-4527-a62f-969e5843f960.jpg)\n\n## Assessment and Recommendation\n\nHonest pros and cons, effort estimates (AI-assisted vs manual), and recommended approach\n\n![](https://ngx-ramblers.org.uk/api/aws/s3/site-content/fb7500d8-1a94-4527-a62f-969e5843f960.jpg)","contentHtml":"

Single-Instance Multi-Tenant Architecture Exploration

\n

Ramblers head office is in discussions about adopting NGX Ramblers as a solution to roll out to groups nationally. The primary driver is the Brevo email integration — Ramblers Head Office wants to offer groups a ready-made email solution (newsletters, walk notifications, booking confirmations) without each group having to set up and manage their own email infrastructure. One of their preferences is that a single NGX instance could serve multiple groups rather than the current model of one deployment per group. Scale target: up to 500 groups.

\n

Target Architecture — outlined more detail in the following articles

\n
flowchart 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\n
\n
\n

This series of articles explores what would be required to re-architect NGX Ramblers so that any number of groups run off a single application instance, while maintaining the same segregated user experience — where navigating to a group's domain shows only that group's branding, members, walks, and content.

\n

Platform Overview

\n

What NGX Ramblers provides beyond email — walks, bookings, galleries, CMS, and more

\n

\"\"

\n

Current Architecture

\n

How the per-group deployment model works today — one Docker image, 13 independent apps

\n

\"\"

\n

Proposed Architecture

\n

Single-instance multi-tenant design — tenant resolution, database switching, request lifecycle

\n

\"\"

\n

Brevo Email at Scale

\n

The primary rollout driver — outbound email, deliverability, and multi-tenant email isolation

\n

\"\"

\n

Billing and Costs

\n

Fly.io free-tier analysis, cost comparison at 500 groups, and billing risk assessment

\n

\"\"

\n

Assessment and Recommendation

\n

Honest pros and cons, effort estimates (AI-assisted vs manual), and recommended approach

\n

\"\"

\n"}