When Open WebUI is missing a feature you can't live without, the reflex is to request it and wait. Often the faster path is a plugin, a small Python file your instance can already run, probably written by someone who hit your problem before you did.
When Open WebUI is missing a feature you can't live without, the reflex is to ask for it in a GitHub issue, a message in the official Open WebUI Discord server, or even a post on the subreddit. Then you wait to see whether anyone picks it up.
Often you don't have to. The chat window you're typing into is a programmable platform, and the export button, the automatic translation, or the model integration you're hoping ships next release may already be sitting in the community library as a small Python file.
Open WebUI calls these files Tools and Functions. Add the community that writes and shares them, and the sum is a real plugin ecosystem. The library lives on openwebui.com, where every plugin's listing carries a Get button that imports it into your instance.
Most missing features need a plugin your instance can already run rather than a core change and a release cycle.
The community library. One Get click starts the import into your own instance.
Two kinds of plugin#
The split decides who gets the new ability.
Tools give the model new abilities. A model on its own can only work with what's in the conversation, however cleverly you prompt it. Give it a Tool and it can reach out mid-chat to check the weather right now, pull a stock price, search the web, or call an API you care about. The model picks the moment, based on what the conversation needs.
The model picks the moment. A weather Tool called mid-chat, with the live result folded into the reply.
Functions change Open WebUI itself. They add new entries to your model selector, rewrite messages on their way in or out, put buttons under chat replies, and run automation in the background. Some of those jobs never involve a model at all.
| Tools | Functions | |
|---|---|---|
| Who gains the ability | The model in your chat | Open WebUI itself |
| Where they live | Workspace → Tools | Admin Panel → Functions |
| Who manages them | Users, when granted permission | Admins only |
| Typical jobs | Live data, external APIs, actions mid-chat | New models, message rewriting, UI buttons, automation |
Tools live in the Workspace, next to models, knowledge, prompts, and skills.
One boundary worth drawing first is that Open WebUI can also reach external tool servers, separate programs that speak MCP (Model Context Protocol, an open standard for connecting AI to outside tools) or OpenAPI. Those plug in under Settings → Connections, and the docs cover them. Tools and Functions run in-process, inside Open WebUI itself rather than as a separate program you host, and they're the kind the community library trades in.
What are the four kinds of Function?#
The four types map to the four places a conversation can change: what answers you (a Pipe), what flows in between (a Filter), what happens to a reply after it lands (an Action), and what goes on around the conversation (an Event).
Open WebUI reads the Python when a Function is saved, whether you wrote it or imported it, and detects the type from the class name inside. The editor has no type picker.
A Pipe invents a model. The invention shows up in the model selector like anything else, but what answers is the code inside. Pipes connect providers that don't speak the OpenAI protocol, run agents that reason in steps, and stand in for things that aren't language models at all, like a database query interface or the controls for the lights in your actual house. One Pipe can even expose a whole family of models at once, and the docs call that kind of Pipe a manifold.
A Pipe in the model selector. Research Agent is a Function, listed like any provider's model.
A Filter sits in the middle. It can rewrite or reject a request before the model sees it, touch the reply while it streams, or process the finished response. Those three stages make a Filter the natural home for live translation, for redacting customer data before it ever reaches a hosted model, or for the compliance log your auditor keeps asking about. Filters attach to specific models or to all of them, and some add a per-chat toggle so users can opt in.
A toggleable Filter from the user's side. One switch, no code in sight.
An Action puts a button under a message. Clicking the button hands the plugin the message's context plus a live line to the chat and the server. What happens next is whatever the code was written to do, whether that's exporting the reply somewhere your team actually works, filing it into a knowledge base, or reaching a system that has nothing to do with the message at all.
An installed Action appears as a button under the reply, named on hover.
An Event runs when something happens on the server. The trigger can be a user signing up, a chat getting deleted, the server starting, or a setting changing. Since v0.10.0 of Open WebUI, Event Functions have offered the chat nothing to click on. Instead, they run as an automation layer around the platform, handling audit logging, provisioning, gating signups, and the other tasks you'd otherwise script by hand. What an Event does once triggered can reach anything the server can, chats included.
The admin's view. Every Function declares its type, detected from the code.
What people actually build#
The community library is a quick way to get a feel for what the system can do. A few picks:
- Vision Bridge by @sciencepond. A Filter that gives a text-only model the ability to see. Attach a screenshot, and a vision model you choose describes it, with the description slipped into the message before your chat model reads it. Four days old at the time of writing, and that's the library moving at its usual speed.
- PII Filter by @isidrospencer114645b5a5. A Filter that swaps names, emails, and phone numbers for stable placeholders before the conversation reaches the chat model, then restores them in the reply, so a hosted model can help with a customer ticket without reading the raw details.
- Jellyfin Tool by @ichrist. A Tool that turns the chat into a remote for your own media server. Ask for a movie, a specific episode, or live TV, and it plays right there in the conversation, subtitles and all.
- Token Usage & Cost Display by @smetdenis. A Filter that appends the numbers behind each reply: tokens in and out, generation speed, context-window fill, and what the message cost. When a platform change broke the old version, the author rebuilt it within the month, and the comment thread reads like a support desk closing every ticket.
The ceiling sits higher still, with the docs' own examples running from live-streaming dashboards to per-user cost enforcement to entire in-chat apps.
The first check comes before any install, and it isn't about the code. Does Open WebUI already do the job? Automatic memories, context compaction for long chats, sub-agents, and chatting with several models side by side are all core features today, and popular plugins that overlap with them still sit near the top of the library.
Installing your first plugin#
- Find a plugin on the community site, where Tools and Functions each have a library.
- Click Get. The community site asks for a free sign-in the first time, then a dialog asks for your instance's address.
- The plugin opens in your instance's editor with the code on screen. The second check happens here. Read the code before you go further, however popular the listing is.
- Save. You then switch a Tool on where you'll use it, either per chat from the message input's Integrations menu or per model from the model's edit page in the Workspace. An admin turns a Function on from the Functions page.
The Get dialog on a community listing. The address you give it is your own instance.
More advanced plugins keep their settings in valves, knobs you turn from the UI instead of editing code. They come in two tiers: valves, set by whoever manages the plugin, and user valves, set by each person for themselves.
Valves belong to whoever manages the plugin: an admin for a Function, the owner for a Tool, along with anyone the Tool is shared with under write access. The valves live behind the gear icon on the plugin's row and carry whatever settings the plugin exposes at that tier, like an API key, an endpoint, or a default that should hold for everyone. Valves that carry secrets can be stored encrypted.
The shared tier. A plugin's valves, exposed in the UI instead of buried in code.
User valves belong to each person. Open the Controls sidebar in any chat and a Valves section sits at the top, where anyone can adjust whatever personal settings the same plugin exposes, like a preferred language or an output format, without asking an admin or touching anyone else's setup.
The user tier. The same plugin's personal settings, at the top of the chat's Controls sidebar.
Read before you run#
All this capability carries one cost, and the project's docs lead with it. Plugins are Python code running on your server, by design, and that access is why plugins can do so much.
So a plugin import deserves a moment of judgment. Popular isn't the same as audited, because community listings aren't security-reviewed and a featured badge isn't a guarantee. Read the code before you save it. If you can't tell what it does, that's a signal worth taking seriously. Open WebUI underlines the point itself by gating a new Function's first save behind an acknowledgment that you're about to let code run on your server.
The acknowledgment that gates a new Function's first save.
Every admin can install Functions, so the admin list is also the list of who can run code on your server. The workspace Tools permission opens that same door for ordinary users. Grant it with the same care, and look over what's installed from time to time.
That caution is the same discipline any code on your server deserves.
Before you file that feature request#
If a feature idea feels like it needs a core change, ask whether it can be a plugin first. Things like per-user rate limits, response cleanup, provider-specific routing, and cost tracking have shipped as plugins without waiting on a release.
A design philosophy sits underneath. It starts with how differently Open WebUI gets used, whether as a desktop assistant for one person, a team server, a hospital's locked-down deployment, or a classroom. A feature that's essential in one of those settings is noise in the others. A core that absorbed all of those features would get heavier and slower for everyone, so the base stays lean and the extension points carry the differences. Your instance grows in exactly the direction you want it to, while an instance across the world grows in a different direction entirely.
Writing your own plugin#
Creating your own plugin is often an evening project, the kind you start after dinner and finish sooner than you expect. Here's a complete, working Function taken straight from the docs' Filter guide, a per-user rate limiter in thirty-four lines.
from pydantic import BaseModel, Field
from typing import Optional
import time
class Filter:
class Valves(BaseModel):
requests_per_minute: int = Field(default=60, description="Max requests per minute per user")
def __init__(self):
self.valves = self.Valves()
self.user_requests = {} # Track requests per user
async def inlet(self, body: dict, __user__: dict = None) -> dict:
if not __user__:
return body
user_id = __user__.get("id")
current_time = time.time()
# Clean old entries and count recent requests
if user_id not in self.user_requests:
self.user_requests[user_id] = []
# Keep only requests from the last minute
self.user_requests[user_id] = [
t for t in self.user_requests[user_id]
if current_time - t < 60
]
if len(self.user_requests[user_id]) >= self.valves.requests_per_minute:
raise Exception(f"Rate limit exceeded: {self.valves.requests_per_minute} requests/minute")
self.user_requests[user_id].append(current_time)
return bodySave the filter, flip its Global toggle, and every chat on your instance now has a requests-per-minute budget. The limit is a valve, so dropping it from sixty to something stricter is a settings edit rather than a code edit.
The Filter guide's rate limiter. Pasted in, switched on, its valve set to two, and enforcing on the third message.
The guides walk you through each type from there. A docstring at the top of the file carries the metadata, and any pip packages it lists install themselves the first time the plugin loads. Your plugin doesn't have to come from the community site either, since the editor takes pasted code and the admin page imports straight from a URL.
And a plugin that solves your problem probably solves someone else's. The library is where plugins find their second user.
Get involved#
- Browse the libraries. Tools and Functions on the community site, sortable by popularity.
- Read the guides. The plugin docs cover every type, starting with the security notes worth reading first.
- Share what you build. Publish it to the community so the next person searching finds yours.
The Open WebUI Team
