Blame
|
1 | # Multi-Tenancy |
||||||
| 2 | ||||||||
|
3 | Multi-Tenancy describes how AeThex separates organizations, teams, projects, users, and resources across shared infrastructure. |
||||||
|
4 | |||||||
|
5 | <div class="docs-section-heading"> |
||||||
| 6 | <h2>Tenant boundary</h2> |
|||||||
| 7 | <p>The tenant boundary protects one organization or project context from another.</p> |
|||||||
| 8 | </div> |
|||||||
|
9 | |||||||
|
10 | AeThex systems should assume that users may belong to multiple organizations, teams, and projects. Every protected resource needs a clear ownership context and a permission check against that context. |
||||||
| 11 | ||||||||
| 12 | ## Tenant-aware resources |
|||||||
| 13 | ||||||||
| 14 | - [[Organizations]] |
|||||||
| 15 | - [[Teams]] |
|||||||
| 16 | - [[Projects]] |
|||||||
| 17 | - API credentials and integrations |
|||||||
| 18 | - Billing, audit, and operational records |
|||||||
| 19 | - Game, studio, or lab environments |
|||||||
| 20 | ||||||||
| 21 | ## Design requirements |
|||||||
| 22 | ||||||||
| 23 | 1. Store tenant context explicitly. |
|||||||
| 24 | 2. Validate tenant access on every protected request. |
|||||||
| 25 | 3. Avoid relying on client-provided organization IDs without server-side checks. |
|||||||
| 26 | 4. Keep audit logs tenant-aware. |
|||||||
| 27 | 5. Make cross-tenant administration rare and traceable. |
|||||||
| 28 | ||||||||
| 29 | <div class="docs-grid"> |
|||||||
| 30 | <a class="docs-card" href="/Organizations">Organizations</a> |
|||||||
| 31 | <a class="docs-card" href="/Teams">Teams</a> |
|||||||
| 32 | <a class="docs-card" href="/Permissions">Permissions</a> |
|||||||
| 33 | <a class="docs-card" href="/Security-Model">Security Model</a> |
|||||||
| 34 | </div> |
|||||||