I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.
Verify Feature Scope
I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
Problem Description
Currently, pipeline valves are global and can only be configured by administrators through the admin panel. This means all users share the same pipeline configuration, which limits flexibility for individual user preferences and use cases.
For example:
In a RAG pipeline, users cannot select which MCP servers/tools they want to use
Users cannot adjust the number of retrieved sources for their specific needs
Temperature settings, top_k, and other LLM parameters cannot be personalized per user
Dynamic configurations (like data source selection via dropdown/checkbox) are impossible
This rigidity forces either:
Creating multiple near-identical pipelines for different configurations
Frequent admin intervention to change settings for individual users
Users being stuck with one-size-fits-all configurations
Desired Solution you'd like
Implement User Valves for Pipelines, similar to the existing user valve functionality for Tools and Functions.
Key Requirements:
Dual Valve System:
Valves (class attribute) - Global admin-configured settings (current behavior)
UserValves (new class attribute) - Per-user configurable settings
User Interface:
Users can access and modify their UserValves directly from the chat interface
Similar UI/UX to existing Tools/Functions user valves (via Controls menu)
Changes saved per-user, persisted across sessions
Backend Implementation:
UserValves instance created per user (stored in database, not just in-memory)
Pipeline instance isolation: Ensure each request uses the correct user's UserValves
Thread/process safety: Verify pipeline instantiation model supports per-user state
API Endpoints (following existing patterns):
GET /api/v1/pipelines/{pipeline_id}/valves/user
GET /api/v1/pipelines/{pipeline_id}/valves/user/spec
POST /api/v1/pipelines/{pipeline_id}/valves/user/update
Example Use Cases:
RAG Pipeline: User selects which MCP servers/tools to include (checkbox/dropdown)
Source Control: User adjusts number of retrieved documents (slider)
LLM Parameters: User sets personal temperature/top_k preferences
Data Sources: User enables/disables specific knowledge bases
Example Pipeline Code:
classPipeline:classValves(BaseModel):# Admin-only global settingsmax_sources:int=10enable_advanced_features:bool=TrueclassUserValves(BaseModel):# Per-user customizable settingsnum_sources:int=5temperature:float=0.7enabled_mcp_servers:List[str]=["server1","server2"]def__init__(self):self.valves=self.Valves()# UserValves instantiated per-user by framework
Alternatives Considered
Multiple Pipeline Instances - Create separate pipelines for each configuration
API (Tools): open-webui/src/lib/apis/tools/index.ts
API (Functions): open-webui/src/lib/apis/functions/index.ts
This proves the architecture can support per-user configuration and provides a blueprint for implementation.
Benefits:
Empowers users without admin intervention
Reduces pipeline proliferation
Enables personalized AI experiences
Maintains admin control via global Valves
Consistent with existing Tools/Functions patterns
Originally created by @hectorc98 on GitHub (Nov 14, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/19179
### Check Existing Issues
- [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request.
### Verify Feature Scope
- [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
### Problem Description
Currently, pipeline valves are global and can only be configured by administrators through the admin panel. This means all users share the same pipeline configuration, which limits flexibility for individual user preferences and use cases.
For example:
- In a RAG pipeline, users cannot select which MCP servers/tools they want to use
- Users cannot adjust the number of retrieved sources for their specific needs
- Temperature settings, top_k, and other LLM parameters cannot be personalized per user
- Dynamic configurations (like data source selection via dropdown/checkbox) are impossible
This rigidity forces either:
1. Creating multiple near-identical pipelines for different configurations
2. Frequent admin intervention to change settings for individual users
3. Users being stuck with one-size-fits-all configurations
### Desired Solution you'd like
Implement **User Valves** for Pipelines, similar to the existing user valve functionality for Tools and Functions.
**Key Requirements:**
1. **Dual Valve System:**
- [Valves](cci:2://file:///Users/hector/workspace/open-webui-oss/pipelines/examples/filters/rate_limit_filter_pipeline.py:8:4-22:52) (class attribute) - Global admin-configured settings (current behavior)
- `UserValves` (new class attribute) - Per-user configurable settings
2. **User Interface:**
- Users can access and modify their UserValves directly from the chat interface
- Similar UI/UX to existing Tools/Functions user valves (via Controls menu)
- Changes saved per-user, persisted across sessions
3. **Backend Implementation:**
- UserValves instance created per user (stored in database, not just in-memory)
- Pipeline instance isolation: Ensure each request uses the correct user's UserValves
- Thread/process safety: Verify pipeline instantiation model supports per-user state
4. **API Endpoints** (following existing patterns):
```
GET /api/v1/pipelines/{pipeline_id}/valves/user
GET /api/v1/pipelines/{pipeline_id}/valves/user/spec
POST /api/v1/pipelines/{pipeline_id}/valves/user/update
```
5. **Example Use Cases:**
- **RAG Pipeline:** User selects which MCP servers/tools to include (checkbox/dropdown)
- **Source Control:** User adjusts number of retrieved documents (slider)
- **LLM Parameters:** User sets personal temperature/top_k preferences
- **Data Sources:** User enables/disables specific knowledge bases
**Example Pipeline Code:**
```python
class Pipeline:
class Valves(BaseModel):
# Admin-only global settings
max_sources: int = 10
enable_advanced_features: bool = True
class UserValves(BaseModel):
# Per-user customizable settings
num_sources: int = 5
temperature: float = 0.7
enabled_mcp_servers: List[str] = ["server1", "server2"]
def __init__(self):
self.valves = self.Valves()
# UserValves instantiated per-user by framework
```
### Alternatives Considered
1. **Multiple Pipeline Instances** - Create separate pipelines for each configuration
- Doesn't scale, maintenance nightmare, code duplication
2. **URL Parameters/Headers** - Pass preferences via request parameters
- No persistence, must be sent with every request, poor UX
3. **External Configuration Service** - Store user preferences separately
- Bypasses the valve system, requires custom implementation per pipeline
4. **User Profiles/Presets** - Admin creates preset configurations users can select
- Still limited, doesn't allow true user customization
### Additional Context
**Technical Considerations:**
- Pipeline instantiation model needs verification: Are pipelines instantiated per-request, per-user, or globally?
- Thread safety: If pipelines are shared, UserValves must be request-scoped
- Storage: User valves should be stored in the database (similar to user preferences)
- Inheritance: UserValves should override Valves defaults but respect admin-set limits
**Reference Implementation:**
The feature already exists for Tools and Functions:
- Frontend: open-webui/src/lib/components/chat/Controls/Valves.svelte
- API (Tools): open-webui/src/lib/apis/tools/index.ts
- API (Functions): open-webui/src/lib/apis/functions/index.ts
This proves the architecture can support per-user configuration and provides a blueprint for implementation.
**Benefits:**
- Empowers users without admin intervention
- Reduces pipeline proliferation
- Enables personalized AI experiences
- Maintains admin control via global Valves
- Consistent with existing Tools/Functions patterns
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @hectorc98 on GitHub (Nov 14, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/19179
Check Existing Issues
Verify Feature Scope
Problem Description
Currently, pipeline valves are global and can only be configured by administrators through the admin panel. This means all users share the same pipeline configuration, which limits flexibility for individual user preferences and use cases.
For example:
This rigidity forces either:
Desired Solution you'd like
Implement User Valves for Pipelines, similar to the existing user valve functionality for Tools and Functions.
Key Requirements:
Dual Valve System:
UserValves(new class attribute) - Per-user configurable settingsUser Interface:
Backend Implementation:
API Endpoints (following existing patterns):
Example Use Cases:
Example Pipeline Code:
Alternatives Considered
Multiple Pipeline Instances - Create separate pipelines for each configuration
URL Parameters/Headers - Pass preferences via request parameters
External Configuration Service - Store user preferences separately
User Profiles/Presets - Admin creates preset configurations users can select
Additional Context
Technical Considerations:
Reference Implementation:
The feature already exists for Tools and Functions:
This proves the architecture can support per-user configuration and provides a blueprint for implementation.
Benefits: