Multi-Tenant Setup

MaxAI Multi-Tenant Architecture Documentation

This document outlines the architecture, deployment strategy, configuration, and operational considerations for setting up and maintaining a multi-tenant environment for the AnswerRocket platform, as discussed during the 2025/04/25 planning session.

The shift from single-tenant-per-VM to multi-tenant-per-VM/container aims to optimize infrastructure efficiency while preserving tenant-level data and configuration isolation.

---

Architecture

Single-Tenant Model

• Each client runs on a dedicated VM.

• One deployment per VM.

• Full environment isolation (URL, data, config).

• Straightforward but resource-intensive.

Multi-Tenant Model

• Single VM with container set shared by multiple tenants.

• Routing-based tenant segregation using domain or subdomain (e.g. pmi.canar.com, audi.canar.com).

• Tenants configured via a JSON-based config system, particularly tenant_url_overlay_map.

Configuration

Directory Structure

/config/
  └── tenants/
      ├── bmw/
      │   └── system_config.json
      ├── audi/
      │   └── system_config.json

Tenant Configuration Includes:

• tenant_url_overlay_map for domain-based routing

• Display names

• Upload limits

• Pipeline settings

• Skill studio access control

Routing & Domain Mapping

Requests are routed by subdomain:

• bmw.canar.com → tenant=bmw

• audi.canar.com → tenant=audi

Mapping is handled via:

"tenant_url_overlay_map": {
  "bmw.canar.com": "bmw",
  "audi.canar.com": "audi"
}

SSL/TLS Considerations

• Prefer handling certificates at the Load Balancer (e.g., Azure Application Gateway).

• Offloading simplifies certificate and domain management.

Data Isolation & Security

• MongoDB stores are isolated per tenant, ensuring strict data segregation.

• Skills, documents, and queries within one tenant are not visible to others.

Skill Execution & Agent Isolation

• Skills and assistants (soon referred to as agents) are scoped to tenants.

• Upcoming features may allow shared skill repos, reducing maintenance duplication.

• Each tenant can point to the same Git repo for common skills while maintaining unique configurations.

Performance & Scaling Guidelines

Base Recommendations

Sizing Factors

• Concurrency (users active at the same time)

• Skill complexity (processing & transformation)

• Query size (volume of rows, e.g., 20k rows per request)

• Cache locality (identical vs. disparate queries)

High memory often yields better performance than increasing vCPUs alone.

Deployment & Maintenance Considerations

Pros

• Reduced infrastructure footprint

• Easier VM management

• Centralized container deployment

Cons

• Operational Risk: A crash or misconfiguration can affect all tenants.

• Increased need for:

  • Monitoring

  • Quality assurance

  • Alerting and failover mechanisms

👉

Recommendation: Treat production multi-tenant environments with strict CI/CD guardrails and safety checks.

Document and Skill Access Considerations

• Document visibility is scoped within a tenant.

• Multi-agent scenarios (copilots) within a tenant may still result in shared document access.

• Cross-tenant document access is not allowed by default.

• Dev environments with multiple tenants on one VM may require extra safeguards to avoid bleed-over.

Deployment Process Remains the Same

• Skills and assistants still require:

  • Export/import

  • Per-tenant replication

  • Custom configuration if needed