Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-21 01:25:28 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #5408] [FEAT]: Implementation of Workspace-level Admin Roles and Resource Limits (Multi-tenancy support) #5072

New Issue
Open
opened 2026-06-05 14:51:51 -04:00 by yindo · 0 comments
yindo commented 2026-06-05 14:51:51 -04:00
Owner
Copy Link
Copy Source

Originally created by @iFernandoSousa on GitHub (Apr 11, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5408

What would you like to see?

[Feature Request] Multi-tenancy: Workspace-level Admin Roles and Resource Quotas

🧩 Problem Description

Currently, AnythingLLM's permission system is globally scoped. If a user is granted "Manager" or "Admin" privileges, they gain visibility and control over all workspaces in the instance.

This architecture makes it difficult to use AnythingLLM in a B2B or multi-departmental context, where a host needs to provide isolated environments for different clients. There is no way to delegate workspace management (files, users, settings) to a specific client without exposing other clients' data.

💡 Proposed Solution

I suggest implementing a Multi-tenant management layer with the following capabilities:

1. Workspace-Specific Admin Role

  • Allow assigning a user as an Admin/Manager of a specific workspace only.
  • This user should have full control over documents, workspace settings, and local user management but must be restricted from seeing or accessing any other workspace in the instance.

2. Resource Quotas & Limits

To ensure fair usage and prevent system abuse, add the ability to set limits per workspace:

  • Storage Limit: Maximum disk space (MB/GB) for document storage.
  • Document Count: Maximum number of uploaded files allowed.
  • User Seat Limit: Cap the number of users that can be invited to a specific workspace.
  • Vector/DB Limit: Limit the number of vectors/embeddings allowed per workspace.

3. Child Workspaces (Optional but Recommended)

  • Allow a "Parent" workspace to manage its own "Child" workspaces, facilitating a hierarchy for large organizations.

🎯 Use Case

Managed Service Provider (MSP) Scenario:

"I want to create a dedicated environment for Client A. I want to appoint a member of Client A's team as their local Manager. This person should be able to upload their own proprietary PDFs and manage their team members, while being completely isolated from Client B's workspace on the same server."

🚀 Impact

This feature would position AnythingLLM as a powerful enterprise-grade tool for service providers and large corporations needing strict data isolation and resource management.

  • I have checked existing issues to see if this has been proposed before.
  • This is a request for a new feature and not a bug report.
Originally created by @iFernandoSousa on GitHub (Apr 11, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5408 ### What would you like to see? # [Feature Request] Multi-tenancy: Workspace-level Admin Roles and Resource Quotas ## 🧩 Problem Description Currently, AnythingLLM's permission system is globally scoped. If a user is granted "Manager" or "Admin" privileges, they gain visibility and control over all workspaces in the instance. This architecture makes it difficult to use AnythingLLM in a **B2B or multi-departmental context**, where a host needs to provide isolated environments for different clients. There is no way to delegate workspace management (files, users, settings) to a specific client without exposing other clients' data. ## 💡 Proposed Solution I suggest implementing a **Multi-tenant management layer** with the following capabilities: ### 1. Workspace-Specific Admin Role - Allow assigning a user as an **Admin/Manager of a specific workspace only**. - This user should have full control over documents, workspace settings, and local user management but **must be restricted** from seeing or accessing any other workspace in the instance. ### 2. Resource Quotas & Limits To ensure fair usage and prevent system abuse, add the ability to set limits per workspace: - **Storage Limit:** Maximum disk space (MB/GB) for document storage. - **Document Count:** Maximum number of uploaded files allowed. - **User Seat Limit:** Cap the number of users that can be invited to a specific workspace. - **Vector/DB Limit:** Limit the number of vectors/embeddings allowed per workspace. ### 3. Child Workspaces (Optional but Recommended) - Allow a "Parent" workspace to manage its own "Child" workspaces, facilitating a hierarchy for large organizations. ## 🎯 Use Case **Managed Service Provider (MSP) Scenario:** > "I want to create a dedicated environment for **Client A**. I want to appoint a member of Client A's team as their local Manager. This person should be able to upload their own proprietary PDFs and manage their team members, while being completely isolated from **Client B**'s workspace on the same server." ## 🚀 Impact This feature would position AnythingLLM as a powerful enterprise-grade tool for service providers and large corporations needing strict data isolation and resource management. --- - [x] I have checked existing issues to see if this has been proposed before. - [x] This is a request for a new feature and not a bug report.
yindo added the enhancementfeature request labels 2026-06-05 14:51:51 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label enhancement feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#5072
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?