Architecture
Multi-Tenant System
How hostname-based tenant resolution works via proxy.js.
Multi-Tenant System
One deployment serves multiple domains (tenants). Each tenant has its own branding, ad configuration, tracking pixels, and content.
Request flow
proxy.js behavior
File: proxy.js (root middleware)
| Path pattern | Action |
|---|---|
/_next/*, static files | Skip — no tenant lookup |
| All other paths | Resolve tenant, attach headers |
Headers set on the request:
x-tenant-id— MongoDB ObjectId of the tenantx-tenant-domain— tenant domain stringx-tenant-subdomain— if configured
Localhost development
On localhost or 127.0.0.1, the proxy uses DEV_TENANT_DOMAIN env var (default: getbestanswers.com) instead of the actual hostname.
Tenant document
Key fields on the Tenant model (models/Tenant.js):
| Field | Purpose |
|---|---|
domain | Primary domain (e.g. getbestanswers.com) |
platformName | Site title in header/metadata |
adConfig | Default ad units, KV values, provider (adx/adsense) |
pixelConfig | Google/Meta pixel IDs and conversion IDs |
taboolaConfig | Taboola publisher settings |
pushAlertConfig | Push notification scripts |
Content scoping
All content models (Category, Article, Questionnaire, etc.) are scoped by tenantId with a compound unique index on (tenantId, slug).
Ad config hierarchy
Tenant adConfig provides defaults. Category and Article adConfig override tenant values. See KV Waterfall.