Permissions

Open WebUI provides a flexible permissions system that allows administrators to configure access controls and feature availability for users. This enables fine-grained control over what users can access and modify within the application.

Administrators can manage permissions in two primary ways:

1. Default Permissions: Set the baseline permissions that apply to all users (including admins) via Admin Panel > Users > Groups > Default Permissions.
2. Group Permissions: Create groups with specific permission overrides via Admin Panel > Users > Groups (e.g., a "Power Users" group with access to image generation).

Users with the Pending role have no access until approved, Admin users have full administrative access, and User accounts are subject to the permission system described below.

RBAC Scope Boundary

RBAC permissions control what users can do inside Open WebUI.

RBAC does not replace provider-side least-privilege design. For OpenAI-compatible providers/proxies (including LiteLLM), configure credentials with the minimum required scope for your deployment.

Permission Logic

Permissions in Open WebUI are additive.

• A user's effective permissions are the combination of Global Defaults and all their Group Memberships.
• True takes precedence over False: If any source (Global Default or any single Group) grants a permission, the user will have that permission.
• No "Deny" ability: You cannot use a specific group to "take away" a permission that is granted by another group or by the global defaults. To restrict a feature, it must be disabled in the Global Defaults and disabled in all groups the user belongs to.

Best Practice: Principle of Least Privilege

Since permissions are additive, the recommended security strategy is to start with Restriction:

1. minimize Global Default Permissions: Configure the default permissions (Admin Panel > Users > Groups > Default Permissions) to include only what absolutely every user should have.
2. Grant via Groups: Create specific groups (e.g., "Creators", "Power Users") to explicitly grant advanced features like Image Generation or File Uploads.

This approach ensures that new users don't accidentally get access to sensitive features, while allowing you to easily promote users by simply adding them to the relevant group.

Permission Categories

Permissions are organized into five main categories: Workspace, Sharing, Chat, Features, and Settings.

1. Workspace Permissions

Controls access to the "Workspace" section where users create and manage resources. Some permissions are dependent on others (e.g., you cannot import models if you cannot access the Models workspace).

Permission	Description
Models Access	(Parent) Access the Models workspace to create or edit custom models.
Import Models	(Requires Models Access) Ability to import models from JSON/files.
Export Models	(Requires Models Access) Ability to export models to files.
Knowledge Access	Access the Knowledge workspace to manage knowledge bases.
Prompts Access	(Parent) Access the Prompts workspace to manage custom system prompts.
Import Prompts	(Requires Prompts Access) Ability to import prompts.
Export Prompts	(Requires Prompts Access) Ability to export prompts.
Tools Access	(Parent) Access the Tools workspace to manage functions/tools. Hidden, along with its Import and Export sub-toggles, when ENABLE_PLUGINS is false, since the Tools workspace does not exist in that case.
Import Tools	(Requires Tools Access) Ability to import tools.
Export Tools	(Requires Tools Access) Ability to export tools.
Skills Access	(Parent) Access the Skills workspace to create and manage reusable instruction sets.
Import Skills	(Requires Skills Access) Import skills into the Skills workspace.
Export Skills	(Requires Skills Access) Export skills from the Skills workspace.

⚠️ Tools Access = Root-Equivalent Access

Treat the Tools Access permission as root-equivalent access. Granting a user access to create or import Tools is equivalent to giving them shell access to your server, because Tools and Functions execute arbitrary Python code. Only grant this permission to users you would trust with direct access to your server. If you enable this permission for untrusted users, you are accepting the risk of arbitrary code execution on your host. For full details, see the Plugin Security Warning.

2. Sharing Permissions

Controls what users can share with the community or make public.

Permission	Description
Models Sharing	(Parent) Ability to share models (make them accessible to others).
Models Public Sharing	(Requires Models Sharing) Ability to make models publicly discoverable.
Knowledge Sharing	(Parent) Ability to share knowledge bases.
Knowledge Public Sharing	(Requires Knowledge Sharing) Ability to make knowledge bases public.
Prompts Sharing	(Parent) Ability to share prompts.
Prompts Public Sharing	(Requires Prompts Sharing) Ability to make prompts public.
Tools Sharing	(Parent) Ability to share tools.
Tools Public Sharing	(Requires Tools Sharing) Ability to make tools public.
Skills Sharing	(Parent) Ability to share skills.
Skills Public Sharing	(Requires Skills Sharing) Ability to make skills public.
Notes Sharing	(Parent) Ability to share Notes.
Notes Public Sharing	(Requires Notes Sharing) Ability to make Notes public.
Folders Sharing	Ability to share a chat folder (and the chats inside it) with specific users or groups, with read or write access. Subfolders inherit the share, and folders cannot be shared publicly. Admins are always exempt.
Chats Public Sharing	(Requires Allow Chat Share) Ability to make a chat share link reachable by every signed-in user of the instance. Opening the link still requires logging in. When disabled, users can still share chats with specific users or groups via the access-control selector, but the "Public" option is hidden for non-admins. Admins are always exempt.
Chats Open Sharing	(Requires Allow Chat Share) Ability to make a chat share link readable without signing in, by anyone on the internet who has the link. This is the only permission that exposes content outside the instance, it grants read access only, and it applies to chats alone. Off by default. When disabled, the "Open" option is hidden for non-admins and open grants are stripped from update payloads. Admins are always exempt. See Open links.
Calendars Public Sharing	(Requires Features > Calendar) Ability to make a calendar publicly readable or writable by every user with the Calendar feature. When disabled, wildcard access grants are stripped from calendar create/update payloads; owners can still share with specific users or groups. Admins are always exempt.
Allow Sharing With Users	Ability to share a resource with specific individual users (USER_PERMISSIONS_ACCESS_GRANTS_ALLOW_USERS). When disabled, individual-user grants are stripped from create/update payloads; group and public sharing are unaffected. Admins are always exempt.
Allow Sharing With Groups	Ability to share a resource with groups (USER_PERMISSIONS_ACCESS_GRANTS_ALLOW_GROUPS). When disabled, group grants are stripped from create/update payloads; individual-user and public sharing are unaffected. Admins are always exempt.

Every toggle in the panel's Sharing Permissions section is off unless you turn it on, and a public toggle is only drawn once the parent permission named in its row is on. The two Allow Sharing With ... rows sit in a separate Access Grants section and are on by default.

Re-check Tools and Notes public sharing after an upgrade

On instances upgraded from a release that predates Tools Public Sharing and Notes Public Sharing, the admin panel used to draw both switches as on while the backend still refused the action. Saving any permission on that page then persisted them as enabled, granting public tool and note sharing that was never configured. The panel and the enforcement now agree, but a value already written to the database is not rolled back.

If you saved default permissions on an affected release, open Admin Panel > Users > Groups, edit Default permissions and confirm both switches read the way you intend. Group-level overrides are worth the same check.

3. Chat Permissions

Controls the features available to the user inside the chat interface.

Permission	Description
Allow Chat Controls	(Parent) Access to advanced chat settings. Required for Valves, System Prompt, and Parameters.
Allow Chat Valves	(Requires Allow Chat Controls) Access to model-specific configuration "valves".
Allow Chat System Prompt	(Requires Allow Chat Controls) Ability to edit the system prompt for a conversation.
Allow Chat Params	(Requires Allow Chat Controls) Ability to adjust LLM parameters (e.g., temperature, top_k).
Allow File Upload	Ability to upload files to the chat.
Allow Web Upload	Ability to attach a web page to a chat by URL, using Attach Webpage in the message input's attach menu (USER_PERMISSIONS_CHAT_WEB_UPLOAD). On by default. When disabled, the option is greyed out and the attach is refused. Admins are always exempt.
Allow Chat Delete	Ability to delete entire chat conversations (USER_PERMISSIONS_CHAT_DELETE). On by default. When disabled, the delete controls are hidden from non-admins rather than shown and refused: the sidebar chat menu, the Shift+hover delete icon on a sidebar row, the chat's own top-bar menu, the search results, the per-chat delete in Settings > Archived Chats and Delete All Chats in Settings > Data Controls. The Delete chat keyboard shortcut stops doing anything, and archiving is unaffected. Deleting a folder that still holds chats needs this permission too, and that menu entry is not hidden, so it is refused rather than absent. Admins are always exempt.
Allow Delete Messages	Ability to delete individual messages.
Allow Chat Edit	Ability to edit messages.
Allow Continue Response	Ability to use the "Continue" feature for truncated responses.
Allow Regenerate Response	Ability to regenerate an AI response.
Allow Rate Response	Ability to thumbs up/down responses.
Allow Chat Share	Ability to generate a share link for a chat.
Allow Chat Export	Ability to export chat history.
Allow Chat Import	Ability to import chats (upload a previously exported chat back into Open WebUI) and to fork a chat, which copies an existing conversation into a new one (USER_PERMISSIONS_CHAT_IMPORT). On by default. When disabled, Import Chats in Settings > Data Controls, the Fork chat action under an assistant response and the /fork entry in the chat input's / menu are all hidden from non-admins. Admins are always exempt.
Allow Speech to Text	Ability to use voice input.
Allow Text to Speech	Ability to use voice output.
Allow Call	Ability to use the real-time audio call feature.
Allow Multiple Models in Chat	Ability to select multiple models for a simultaneous response.
Allow Temporary Chat	(Parent) Ability to toggle "Temporary Chat" (incognito mode/history off). Note: Backend document parsing is disabled in this mode for privacy.
Enforce Temporary Chat	(Requires Allow Temporary Chat) Restricts the user to always use temporary chat (history disabled).

4. Features Permissions

Controls access to broad platform capabilities.

Permission	Description
API Keys	Ability for non-admin users to generate Personal Access Tokens (API Keys) in User Settings.
Notes	Access to the "Notes" feature.
Channels	Access to the "Channels" feature.
Folders	Ability to use folders for organizing chats.
Web Search	Ability to use Web Search integration.
Image Generation	Ability to use Image Generation tools. On backends that keep only one image model loaded at a time, this also allows changing the instance's active image model; see the note below.
Code Interpreter	Ability to use the Python Code Interpreter.
Direct Tool Servers	Ability to connect to custom Tool Servers in settings.
Memories	Access to the Memories feature for persistent user context. Taking it away hides the Personalization settings tab, blocks the memory API endpoints, withholds the memory tools from the model and stops stored memories being injected into the chat's system context. The injection check runs server-side on every chat request, so a client that still asks for memory does not get it. Admins are always exempt.
Automations	Ability for non-admin users to access the Automations page and create, edit, run, pause, or delete their own scheduled automations.
Calendar	Access to the Calendar feature for creating calendars, managing events, and viewing shared calendars.
User Webhooks	Ability for users to set their own personal webhook URL (under Settings > Account) for notifications. Disabled by default.

Image Generation and the Active Model

Some image backends, such as Automatic1111, keep a single image model loaded and generate with whichever one is active, so selecting a model is the same action as switching the loaded one.

On Automatic1111 that switch is restricted to administrators. A non-admin with Features > Image Generation cannot change the instance-wide model: their model selection is ignored and the image is generated on the currently configured checkpoint. Only an administrator's request changes the active model, and when it does, it changes it for everyone until it is changed again.

Backends that accept a model with each request are not affected: a user's choice applies only to their own generation.

Automations Permission Scope

For Automations access:

1. Permission Check for Non-Admins: Users with the user role need Features > Automations (features.automations).
2. Admins Are Exempt from features.automations: Users with the admin role can access Automations without that specific permission.

Default permission can be configured via USER_PERMISSIONS_FEATURES_AUTOMATIONS.

Calendar Permission Scope

For Calendar access:

1. Permission Check for Non-Admins: Users with the user role need Features > Calendar (features.calendar).
2. Admins Are Exempt from features.calendar: Users with the admin role can access Calendar without that specific permission.

Default permission can be configured via USER_PERMISSIONS_FEATURES_CALENDAR.

5. Settings Permissions

Controls access to user settings areas.

Permission	Description
Interface Settings Access	Ability to access and modify interface settings in user settings.

Interface Settings Access and instance defaults

Taking this permission away hides the Interface page and refuses any attempt to save personal settings, so the people affected stay on whatever Default Interface Settings you have configured. Leave it on, and those defaults are only a starting point that each person can change. Admins are exempt.

API Keys Permission Scope

For API key creation:

1. Global Toggle Required: The feature must be enabled globally in Settings > Admin > General > API Keys. If this is off, no one can generate keys.
2. Permission Check for Non-Admins: Users with the user role must have the features.api_keys permission.
3. Admins Are Exempt from features.api_keys: Users with the admin role can generate API keys when API keys are globally enabled, even without that specific permission.

Best Practice: Create an Admin Group

To prepare for future permission changes, create a dedicated group for administrators:

1. Create an "Administrators" group via Admin Panel > Users > Groups
2. Add all admin users to this group
3. Grant user-facing feature permissions to the group as needed (for example, API Keys for non-admin group members)

This approach ensures that when new permissions are added that apply to admins, you can easily grant them to all administrators via the group rather than modifying individual user settings. It also provides fine-grained control over which admins have access to which features.

Environment Variables

While the UI is the recommended way to manage permissions, initial defaults can be set via environment variables. These are typically prefixed with USER_PERMISSIONS_.

• ENABLE_IMAGE_GENERATION=True
• ENABLE_WEB_SEARCH=True
• USER_PERMISSIONS_CHAT_FILE_UPLOAD=True

See the Environment Configuration guide for a complete list of valid variables.