-
-
Notifications
You must be signed in to change notification settings - Fork 91
Multi-tenant hosted architecture spec #4783
Copy link
Copy link
Closed
Labels
maintainer-onlyOwner-only work — yields no Gittensor points.Owner-only work — yields no Gittensor points.roadmapOn the Wave-2 agent-layer roadmap board (project 9)On the Wave-2 agent-layer roadmap board (project 9)
Description
Metadata
Metadata
Assignees
Labels
maintainer-onlyOwner-only work — yields no Gittensor points.Owner-only work — yields no Gittensor points.roadmapOn the Wave-2 agent-layer roadmap board (project 9)On the Wave-2 agent-layer roadmap board (project 9)
Projects
StatusShow more project fields
Done
Problem: gittensory has been a self-host-only product until now. A hosted, multi-tenant Rent-a-Loop service needs a tenancy model and a decision about where it actually runs — neither exists today.
Area: Product spec / architecture
Proposal: Define the tenancy model (how one customer's data, credentials, and execution are kept separate from another's) and where the hosted platform itself is operated, at a level concrete enough for #4793–P5 and #4802 to implement against directly.
Deliverables:
Acceptance criteria:
Boundaries:
Part of #4778.
Reconciliation decision (#5669, resolved 2026-07-15): this spec is AUTHORITATIVE for the shared tenancy-boundary pattern. AMS Cloud Readiness's #5215 and #5222 explicitly defer to this spec (#5215's own text: this spec's boundary sets the bar their design is held to) -- they are now natively blocked-by this issue and should be scoped directly from what this spec lands on, not derived independently. Write this spec first; it is the one true bottleneck in the tenancy-reconciliation graph.