Workspace resource limit and allocation

[chrstnglmtc]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Hello,

I would like to inquire about workspace storage allocation in the Community Edition.

Is there currently a feature that allows a workspace administrator to allocate and limit the total resources and storage usable by the entire workspace?

Based on the documentation, workspace resource usage appears to be unlimited by default. I would like to confirm whether there is any built-in mechanism that enables administrators to define and enforce workspace-level storage or resource caps, accessible exclusively to administrative roles.

If this functionality is not currently supported, is it planned for a future release or available through configuration in self-hosted deployments?

2. Additional context or comments

No response

[dosubot[bot]]

Hi @chrstnglmtc! I'm Dosu and I’m helping the dify team.

Hi! Based on my research, Dify Community Edition does not currently include built-in workspace-level resource limits or storage allocation features.

Here's what I found:

Current State:

• There are no hardcoded limits for team members, apps, documents, knowledge storage size, or requests per unit time in the self-hosted Community Edition. All limits are determined by your infrastructure capacity (database/storage) rather than by Dify itself.
• Dify does implement global file upload size limits (configurable via environment variables like UPLOAD_FILE_SIZE_LIMIT), but these apply across all workspaces, not per-workspace.

Feature Request Status:

• A similar feature request (#24444) for workspace-level resource management was declined by maintainers. They indicated that such capabilities may only be provided in the business/Enterprise version, not the Community Edition.

Alternatives:

• For self-hosted deployments, the recommended approach is to manage resources at the infrastructure layer (e.g., Kubernetes resource limits) rather than within Dify itself.
• The Enterprise Edition includes multi-workspace support and advanced permission controls, which may include more granular resource management.

Cloud Edition (for reference):

• The SaaS version does have workspace-scoped quotas tied to subscription plans (team members, apps, API calls), but this is billing-driven and not available in self-hosted Community Edition.

If you need workspace-level resource caps for your deployment, you would need to implement them at the infrastructure level or consider the Enterprise Edition.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[chrstnglmtc]

Hello @dosu

Hello, thank you again for the clarification regarding Community Edition not supporting built-in workspace-level resource limits.
We would like to further clarify the intended scope of the requested feature before proceeding with any architectural proposal.

Based on our investigation and understanding of Dify Community Edition:

• There are currently no workspace-level quota mechanisms.
• File upload size limits can be configured globally via environment variables.
• Resource limits are enforced only at the infrastructure layer.

We would like to confirm the following to properly define scope:
1️⃣ Storage-Based Restriction Scope
A. Should the restriction apply only to Knowledge file uploads, since this is the primary storage-consuming component?

B. When referring to restricting storage usage, do you mean:

• A maximum file size per upload?
• A cumulative storage cap per workspace (e.g., total 1GB across all Knowledge uploads)?
• Both?

C. If cumulative storage cap is intended:

• Should the calculation include only raw uploaded file sizes?
• Or should embeddings and metadata storage also be included?

2️⃣ Administrative Control
A. Should the restriction value be:

• Configurable by workspace administrators via UI?
• Or defined as a fixed system-level configuration?

B. Should administrators be able to:

• View current usage vs. maximum allowed?
• Adjust limits after workspace creation?

C. Should non-admin users see remaining available storage?

3️⃣ Additional Restriction Types
Beyond Knowledge storage, should the restriction also apply to:

• Maximum number of applications?
• Maximum number of datasets/documents?
• API request limits per workspace?
• Token usage or runtime processing caps?
• Or is the requirement strictly limited to storage usage control?

4️⃣ Implementation Layer Expectation
Since Community Edition does not provide native quota support:

• Is infrastructure-level restriction (e.g., Kubernetes volume limits) acceptable?
• Or is the expectation to implement this as an application-layer feature within Dify, managed per workspace by administrators?

Thank you

[dosubot[bot]]

Hello! Thank you for the detailed scoping questions. I've researched Dify's architecture and existing implementations to help clarify the intended scope. Here's what I found:

Current State Context

Before answering your questions, some key context:

• Maintainers have explicitly stated they don't plan to add workspace-level resource management to Community Edition, expecting infrastructure-level tools instead
• However, existing quota patterns in the codebase (TenantCreditPool, LimitationModel) could serve as implementation references if a community contribution were accepted

---

1️⃣ Storage-Based Restriction Scope

A. Knowledge uploads are indeed the primary storage consumer, but files are also stored for workflow file uploads and attachments.

B. Regarding what "storage usage" means:

• Currently only per-file size limits exist via UPLOAD_FILE_SIZE_LIMIT (default 15MB)
• Cloud edition calculates storage as: raw file size + chunk size + embedding vector storage
• Cumulative workspace caps don't exist in Community Edition

C. For cumulative caps:

• Cloud edition includes embeddings and metadata in storage calculation
• This is complex because embeddings are stored in external vector databases (Milvus, Qdrant, etc.) which don't expose precise per-tenant storage metrics
• A simpler approach would track only raw file sizes via the existing UploadFile.size field

---

2️⃣ Administrative Control

A. Current patterns suggest:

• Cloud/Enterprise use external API-driven configuration, not UI-configurable per workspace
• Community Edition uses environment variables for global settings
• The Tenant model has a custom_config JSON field that could store per-workspace settings

B. Usage visibility:

• Cloud edition shows usage/limits via billing API responses displayed in the frontend
• No such visibility exists in Community Edition currently

C. Non-admin visibility:

• Not implemented; would be a design decision for any proposal

---

3️⃣ Additional Restriction Types

The existing FeatureModel (Cloud edition) tracks:

• Workspace members, apps, vector space
• documents_upload_quota
• API rate limits and trigger events

These are billing-driven in Cloud and not exposed in Community Edition. Any Community Edition proposal would need to define its own scope.

---

4️⃣ Implementation Layer Expectation

Given maintainer position:

• Infrastructure-level restriction (Kubernetes) is the expected approach for Community Edition
• Application-layer workspace quotas are reserved for Enterprise/Cloud editions
• A community PR adding this would likely need strong justification and maintainer buy-in given their previous rejection

---

Implementation Reference

If you wanted to propose this feature, the existing patterns show:

1. A storage tracking model similar to TenantCreditPool
2. Enforcement via decorators/middleware like the billing decorators in file upload paths
3. Configuration via environment variables or admin API

Would you like me to research any specific aspect in more detail?

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[chrstnglmtc]

Hello @dosu dosubot[bot], I would like to confirm the password policy implementation in Dify Community Edition v1.11.1.

We are investigating whether the existing password validation satisfies our required policy and whether it is consistently enforced across all account-related flows.

---

Required Password Policy

Our requirement is:

• Password must contain letters and numbers
• Password must be at least 8 characters long

---

Current Implementation Found

In the Community Edition codebase, password validation appears to be implemented in:

api/libs/password.py

Using the function:

valid_password(password)

Which validates passwords using the regex:

^(?=.[a-zA-Z])(?=.\d).{8,}$

This appears to enforce:

• At least one letter
• At least one number
• Minimum 8 characters

---

Investigated Account Flows

We checked the following scenarios in Community Edition v1.11.1:

1. Password Change

Function:

AccountService.update_account_password()

This function calls:

valid_password(new_password)

---

2. Invitation-Based Account Creation

Flow:

Settings → Members → Invite user → User registers via invitation link

Function path:

RegisterService.register()
↓
AccountService.create_account()
↓
valid_password(password)

---

3. Owner Account Creation During Initial Setup

During the initial setup (/install), the first owner account is created using:

AccountService.create_account()

Which also calls:

valid_password(password)

---

Questions

For Dify Community Edition v1.11.1, could you please confirm:

1. Is valid_password() in api/libs/password.py the central password validation logic used by the Community Edition backend?
2. Is this validation consistently applied across all account creation and password update flows, including:
   • Invitation-based registration
   • Initial owner setup (/install)
   • Password changes?
3. Are there any additional password policy validations elsewhere in the Community Edition backend that extend or override this behavior?

Thank you!