HKUDS
[Feature Request]:Workspace-Level Document Isolation and Retrieval Separation
Do you need to file a feature request?
- [x] I have searched the existing feature request and this feature request is not already filed.
- [x] I believe this is a legitimate feature request, not just a question or bug.
Feature Request Description
Description
We are using LightRAG to support multiple business units (or multiple client workspaces) inside a single deployment. Currently, the platform does not provide a clear or enforced way to isolate documents by workspace/tenant. As a result, documents uploaded for one business can influence retrieval results of another business, causing cross-tenant data leakage. To avoid this, we are forced to run completely separate LightRAG instances for each business, which increases operational overhead, maintenance cost, and complexity. We would like to request a built-in, first-class feature to support workspace-level document and retrieval isolation, both in the backend APIs and in the UI.
What We Need (Clear Requirements)
-
Workspace selection in the UI There should be a visible and mandatory Workspace selector in the LightRAG UI where a user chooses which workspace they are currently working in. Example: A dropdown or switch such as: Workspace: Client_A | Client_B | Client_C
-
Workspace-scoped document uploads
When uploading documents through the UI or API:
- A user should explicitly select the workspace they want to upload documents into.
- LightRAG should internally store documents, vector embeddings, graph nodes, and metadata within that workspace only.
- Workspace-scoped retrieval / querying When running queries in the UI or using the API:
- Retrieval should automatically happen only from the selected workspace.
- Documents belonging to another workspace must not be retrieved unless explicitly configured.
- Strong backend enforcement Even if the UI is removed, the backend should enforce:
- Workspace-specific storage partitions (directories, collections, tables, prefixes, etc.)
- Workspace filtering at retrieval time
- Isolation for vector DB, document store, graph DB, and document status tracking
- Documentation Clear documentation should explain:
- How to use multiple workspaces
- How documents are isolated at each storage backend
- How to migrate from a single-workspace setup to multi-workspace
- How developers should initialize and query with workspace context
Additional Context
Motivation / Use-Case (Revised)
- Many organisations host multiple clients or internal teams on the same infrastructure.
- To maintain data privacy and correctness, document ingestion and retrieval must be workspace-isolated.
- Although LightRAG currently allows passing a workspace parameter at initialization, in practice the workflow still requires different instances to achieve true isolation.
- A UI-level workspace selector plus enforced backend partitioning would enable LightRAG to be used in multi-tenant SaaS or enterprise scenarios without deploying multiple servers.
If I may suggest an additional requirement:
Non-admin user accounts created for use with the frontend UI should be optionally restricted to only to work with certain workspaces. This is to prevent users from interfering with workspaces they should not have access to.
A more granular permissions system could add additional capabilities like allowing/disallowing specific actions (insert, query, create, delete, etc.) On a per user+workspace combination basis. For example, userA may have full control over workspaceA but only query permissions on workspaceB. userB may have no permissions on workspaceA but have insert and query permissions on workspaceB.
Solid idea. PR #2369 has addressed the underlying technical challenges for implementing multi-workspace support in the LightRAG Server. Currently, only the implementation of a LightRAG instance pool at the server level and routing based on the LIGHTRAG-WORKSPACE request header is required.
