Classic298/open-webui-plugins: a curated plugin collection for Open WebUI

What Classic298/open-webui-plugins actually is

Open WebUI ships a plugin system, but the plugins themselves come from elsewhere. This repository is one attempt to organise that elsewhere: a curated collection where each plugin lives in its own top-level folder with a README that explains what it does, what components it includes, and how to set it up. The top-level entries listed in the repository are email-composer/, inline-visualizer-v2/, inline-visualizer/, interface-defaults/, keep-reasoning-content/, mcp-app-bridge/, prune/ and vision-bridge/, alongside .github/, .misc/, LICENSE, README.md and SECURITY.md.

The audience is Open WebUI operators, not library consumers. If you are running an instance and want a capability the core does not have, you copy a file or a folder into the right admin screen. There is no package manager step in the README, no CLI, and no single artefact that installs everything. The README's own install section is three steps long: open the plugin's folder and read its README, note which components it lists and where they go, then install them. That is the whole contract.

The plugins are heterogeneous by design. Inline Visualizer v2 is a Tool plus a Skill and renders charts, dashboards, diagrams and mini-apps in the chat while the answer streams. Prune is an Event that cleans old chats, inactive users and orphaned files in the background. Interface Defaults is an Event that pushes default interface settings onto existing users. Email Composer is a single Tool. MCP App Bridge is a Tool for MCP Apps (SEP-1865). Vision Bridge is a Filter plus a Tool. Keep reasoning_content is a Filter. Two entries, Inline Visualizer and the legacy v1, sit in the table without a banner icon; the README notes that only plugins with a banner get an icon.

What the collection is not is a framework. Nothing here is shared between folders except a convention: the plugin folder, the README inside it, and the component list. If you want a plugin that is not one of these eight folders, the collection does not route you anywhere. It is one maintainer's selection, and the README does not claim otherwise.

Six plugin types, and why the install location changes

The README's plugin type table is the most useful page in the repository because it maps each type to a different admin surface. Tools give the model callable capabilities and install under Workspace, then Tools. Skills are structured instructions that teach a model a task or workflow and install under Workspace, then Skills. Filters transform messages before they reach the model or before they are shown to you, and install under Admin Panel, then Functions. Pipes are custom model endpoints that proxy, merge or create new model behaviours, also under Admin Panel, then Functions. Actions are buttons below messages, same location. Events react to system events such as user signup, valve updates and lifecycle hooks, and can additionally register routes and serve standalone pages; they also live under Admin Panel, then Functions.

That split matters when you plan a deployment. A plugin like Vision Bridge is a Filter plus a Tool, so half of it is configured in the admin panel and half in the workspace. Prune is an Event that registers a route, which is why the README can point at an admin page at /prune. If you are scripting an install or writing internal documentation, the type column is the field you actually need, not the plugin name.

The type table also explains why the README's install instructions are so short. There is no universal step to document, because the destination depends on the component. A reader who skips the table and looks for a single install command will find nothing and may conclude the repository is incomplete. It is not incomplete; it is deliberately split by surface.

One thing the type table does not tell you is how a plugin behaves when the Open WebUI version changes. The repository README is silent on version compatibility per plugin, and it does not document rollback. Each folder README is the place to look, and where that README is thin, you are reading source. Treat the type table as a routing guide, not a compatibility matrix.

Installing a plugin and running Prune for the first time

The README gives no shell commands, because installation happens through the Open WebUI interface. The workflow it describes is: open the plugin folder, read its README, identify the components, then install each one at the location the type table gives. For a Tool that means Workspace, then Tools; for an Event it means Admin Panel, then Functions.

Prune is the clearest first use because it exposes an admin page. According to the README, it is dry-run by default, so a fresh install previews rather than deletes, and the admin page at /prune lets you preview and run cleanups manually. The README also states that cleanups run in the background slowly enough that a live instance never notices, and that the plugin is safe across replicas. So the first run is a read, not a write: install the Prune Event under Admin Panel, then Functions, and open the preview page at the route the README names, /prune, in the same browser session as your instance.

What you should see is the preview page described in the README, with the cleanup candidates listed before anything is removed. The README does not document the exact fields on that page, so if the list is empty or the route does not resolve, the plugin is not registered and the Event did not install cleanly.

If you would rather work with a Tool, the path is the same shape but a different screen. Email Composer is a single Tool, so it installs once under Workspace, then Tools, and produces an email card in the chat that you can edit, adjust To/CC/BCC and priority on, and download as .eml. There is no repository-level command to run in either case.

The reason this tutorial is short is a property of the project, not an omission on my part. Every plugin in the collection installs through the same two screens, and the only variable is which screen. Once you have installed one Event and one Tool, you have learned the whole procedure.

Where the collection gets thin

The biggest limitation is stated by the repository's own structure: plugins are independent. There is no shared version number across them, no dependency manifest, and no compatibility statement tying a plugin to an Open WebUI release. The release list (v1.0.36 on 2026-09-01, v1.0.35 on 2026-08-25, v1.0.34 on 2026-08-20) suggests frequent tagged releases, but the README does not explain what a repository release covers relative to an individual plugin folder, so you cannot assume that updating to v1.0.36 refreshes every plugin you installed.

Uninstall and rollback are not documented. If a Filter starts rewriting messages in a way you dislike, the README gives you no revert procedure; you are working from the Open WebUI admin UI and your own backups. That is a real operational cost for anything touching message flow, which includes Filters and Pipes.

Events deserve a second look before you enable them. Interface Defaults pushes defaults onto existing users and adds a factory reset, which is a deliberate change to other people's settings. Prune deletes chats, users and files. Both are described as background behaviour, and Prune is dry-run by default, but the README does not describe an undo path for either. If your instance holds data you cannot lose, the wrong tool is anything in this collection that mutates stored state until you have a tested backup of the underlying database.

There is also a documentation asymmetry. The plugins with banners get a description paragraph in the top-level table that reads like marketing, while the two without banners (Inline Visualizer and the legacy v1) get one line. For Keep reasoning_content, the top-level README is the only place the problem it solves is named: it feeds a reasoning model its own prior chain of thought back so DeepSeek, Kimi, MiMo and vLLM models stay coherent across tool calls, fixing a reasoning_content is missing break mid-tool-call. That is a precise statement, and it is buried in a table cell. If you are evaluating that plugin, the folder README is the thing to read next, and the top-level table is not enough.

How this differs from pulling single functions from the community

The realistic alternative is installing individual community functions directly into Open WebUI, one at a time, from wherever each author publishes them. That is how most Open WebUI setups grow: you find a function, paste or upload it, and move on.

The difference here is packaging discipline, not capability. Each plugin in this repository is a self-contained folder with a README that names its components and its install targets, and the top-level README supplies the type-to-location mapping that a loose function listing usually lacks. When a plugin is multi-component, such as Vision Bridge (Filter plus Tool) or Inline Visualizer v2 (Tool plus Skill), that mapping is the part that saves you from installing half a plugin and wondering why nothing renders. The trade-off is that you get eight folders chosen by someone else, plus two legacy entries, rather than the full breadth of what the community publishes.

A second difference is that some of these plugins exist because a core feature stops short. Interface Defaults is the clearest example: the README states that Open WebUI's Default Interface Settings page cannot push your defaults onto existing users, and this plugin adds that, plus a factory reset and defaults for notifications, keyboard shortcuts, memory, the personal system prompt and the speech and voice block. A single community function might do one of those things. This one is scoped to the whole settings surface.

There is also a licensing difference worth noting. This repository is BSD-3-Clause, which is permissive and permits reuse and redistribution with the licence text retained. A function copied from a random gist may carry no licence at all, which is a problem the moment you redistribute it inside a company image. Check the LICENSE file at the repository root and any licence notice inside the individual plugin folder before you ship a plugin as part of your own distribution.

Maintenance, releases and what to verify before upgrading

The repository is not archived, and the last push was on 2026-09-07. Three releases landed in the three weeks before that: v1.0.36 on 2026-09-01, v1.0.35 on 2026-08-25 and v1.0.34 on 2026-08-20. That is a recent, steady cadence at the repository level.

What the README does not give you is an upgrade procedure. There is no changelog section in the README, no migration note, and no statement about which Open WebUI versions a plugin supports. The release notes are not reproduced in the README either. So the practical upgrade path is manual: before you replace an installed component, read the plugin folder's README in the new revision and compare it with what you have installed, then reinstall the component through the same admin or workspace screen you used the first time. For Events that register routes, such as Prune and Interface Defaults, re-check that the route still responds after the swap, because a failed reinstall leaves the old route gone.

The cost of this model is that upgrades are per plugin, not per repository. If you run four plugins and the repository cuts a release, you have four decisions to make and no changelog to base them on. The benefit is that a plugin you do not use cannot break you, which is not true of a monolith that installs everything at once.

Licence-wise, BSD-3-Clause is straightforward: keep the copyright notice and licence text with any redistribution, and note that the licence grants no trademark rights and comes with no warranty. That is the extent of what the repository states; it is not legal advice, and if you are embedding these plugins in a product you should read LICENSE yourself.

The maintenance risk is concentrated in the plugins you actually install, not in the repository. A folder that has not been touched in a while still installs; it just may not match current Open WebUI behaviour, and the README will not warn you.

Which plugin to look at first, by problem

If you are deciding whether to browse this collection at all, the fastest route is to match your problem to a folder rather than read the table top to bottom.

Your instance is accumulating dead data: Prune. It is an Event with an admin page at /prune, dry-run by default, and the README says it is safe across replicas, which matters if you run more than one Open WebUI process against the same database.

Your existing users are stuck on old interface settings: Interface Defaults. It is an Event, and it is the only plugin here whose stated purpose is to fill a gap the core settings page leaves open.

Your model cannot see images: Vision Bridge. It is a Filter plus a Tool, and the README says it lets a text-only model ask a separate vision model to look at an attached picture on demand, then come back with new questions about the same image later. No core changes are needed per the README.

You want charts in the chat: Inline Visualizer v2, a Tool plus a Skill, with the legacy v1 in inline-visualizer/ for older setups. The README says v2 renders live while the answer streams and works with hand-written SVG/HTML plus Chart.js, D3, Vega-Lite, ECharts, Plotly, vis-network and Tone.js, and that it matches your light or dark theme and lets you click a bar or node to ask the model about it.

You are connecting an MCP server that ships its own UI: MCP App Bridge, a Tool for MCP Apps (SEP-1865) that renders the server's interface as an embedded panel where the model called it, without middleware or core changes according to the README.

You run a reasoning model that loses coherence across tool calls: Keep reasoning_content, a Filter aimed at DeepSeek, Kimi, MiMo and vLLM models and the reasoning_content is missing break.

You want to draft mail inside the chat: Email Composer, a single Tool that produces an editable email card and a .eml download.

That is the whole catalogue. Eight folders, one problem each, and no plugin that tries to do two unrelated jobs.

Editorial conclusion

Adopt it if you already run Open WebUI and want a specific capability, such as the /prune admin page or the Vision Bridge filter, and you are willing to install each component by hand and read that plugin's README first. Do not adopt it expecting a single package, a versioned release artefact or a support commitment; there is no homepage, the repository says to open an issue for bugs and ideas, and the README does not document rollback or uninstall. Verify first that your Open WebUI version accepts the component type you need, since Tools and Skills install under Workspace while Filters, Pipes, Actions and Events install under Admin Panel, and check the plugin folder's own README for its exact files.

Frequently asked questions

Official sources

1. Classic298/open-webui-plugins on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases