Open WebUI functions: pipes, filters and actions

Open WebUI functions act at different points in a chat request, and the point a function uses determines who it affects. A pipe presents itself to users as a model in the model selector. When a user chooses it, Open WebUI passes the conversation to the pipe, and the pipe decides what happens next. It might call an external service, combine several models or return a response of its own. Because a pipe replaces the model call rather than sitting beside it, the people who choose that model are the ones who see its behavior. Confirm the exact entry points and expected return values for your version in the Open WebUI documentation before writing one.

A filter sits on the message path around the model call. Its inlet logic runs before the request reaches the model and can inspect or change the messages being sent. Its outlet logic runs after the response and can inspect or change what the user receives. Redaction, content policy checks and audit logging usually live here. A filter can be enabled for every user and every model, which is what makes it useful for policy and also what makes it risky. Before enabling one, list which models and which roles can reach the chat, and test a conversation with each group that matters to your organization.

An action adds a control to a message or to the chat as a whole, such as a button that a user clicks to run a function against that content. Actions are not in the request path by default. They run only when someone invokes them, so the risk depends on who can see the control and what data the action receives. An action that forwards message content to an outside service creates a data flow that your privacy and security reviewers need to approve. Confirm where action controls appear in your version, which context they receive, and whether role settings can restrict who sees them.

A shared deployment needs a few controls that a single-user installation can ignore. A broken global filter can stop chats for every user at once, so test changes outside production and keep a documented rollback. Edits to a function usually take effect on live traffic immediately, which calls for a change record and a named approver. Functions run Python code on the server, so only trusted administrators should install or edit them. Also confirm how install, enable, update and disable behave in your version, including what happens to chats already in progress, because the lifecycle and hook points have changed between releases.

Every Open WebUI function should pass a written review before any user can select it, because a function is Python that runs inside the Open WebUI process with the access that process has. The review is a procedure with defined inputs and a signed outcome, not a quick look at the code. Assign one named reviewer, give them the source of the exact version to be installed, and do not accept a function that is only available as a pasted snippet with no record of where it came from.

The reviewer needs two kinds of knowledge. Security knowledge covers outbound network calls, file reads and writes, subprocess or dynamic code execution, and secrets handling. Application knowledge covers how pipes, filters and actions are called by Open WebUI, what the message and body objects contain, and which valves or user settings the function reads. A reviewer who knows Python but not the platform will miss filters that silently alter every prompt, and one who knows the platform but not Python may miss obfuscated imports. Where one person does not hold both, pair a platform engineer with a security engineer and record both names on the sign-off.

Work through the code in a fixed order. First, read every import and list the third-party packages. Second, search for outbound network calls, including HTTP clients, sockets, webhooks and calls to model providers that the function does not need. Third, check file access, especially paths outside the function's own data and anything that touches the Open WebUI data directory or database. Fourth, check logging: a filter that writes the message body to standard output or a log file copies user content into a store that may have a different retention and access model. Record each finding as pass, fail or needs a decision, with the line reference.

Test with sample data only. Build a test plan that runs the function against synthetic prompts, including prompts that contain obvious dummy identifiers so you can confirm redaction works, and prompts that try to make the function leak or skip its policy. Do not use production conversations, customer records or copies of real personal data in a test environment, because the test instance may have weaker controls and its logs will be read by people who should not see that data. Keep the test inputs and expected outputs with the review record so a later reviewer can repeat them.

Close the review with a sign-off record that names the function, its source and version or commit, the reviewer, the date, the findings and their resolution, the test results, and the approver who allowed installation. Re-review is required whenever the function's code changes, and also when any dependency it imports is updated, since a clean function can become unsafe after a package change. Ask your team to confirm how valve values changed by administrators are tracked, because a setting change can alter behavior without any code change.

Every upgrade of Open WebUI is also a change to your functions, because pipes, filters and actions depend on internal interfaces that the project can change between releases. These include the shape of the request and response objects a pipe receives, the points at which a filter runs, and the event data an action button uses. Treat each enabled function as a dependency with its own test, and plan every upgrade as a change to the function set as well as to the server.

Before any production upgrade, build an inventory of every enabled function. Include global filters that apply to all models, because they are easy to forget and affect every conversation. Record each function's version and its valve settings, which are the configuration values that control its behavior. Back up the database, then upgrade a staging copy and run a fixed set of test conversations against each model. Check that filters still modify messages as intended, that pipes return complete responses, and that actions render and fire. Compare the results with a baseline captured before the upgrade. Confirm with your own environment whether all valve values survive the move.

The project's release history shows why upgrade windows need slack. According to the Open WebUI releases page on GitHub, v0.11.0 shipped in July, v0.12.0 followed on October 10, and v0.12.3 was published on October 16, 2026. Two releases within a week mean a minor version can be followed quickly by patch fixes. Avoid moving a new release into production on the day it ships, and schedule a window that leaves room for a follow-up patch. Read the release notes for every version between your current release and your target, since a function that passes on the target may fail on an intermediate version you skip.

The license change that applies from v0.6.6 onward is covered on the upgrade practice page, so review it there before you choose a target version. The licensing review and the function regression plan should happen together, because both determine which release is viable for your deployment. Record the decision and its date in the same change record as the test results, so auditors and internal reviewers can trace why a version was adopted.

Finally, keep the regression suite under change control. Store the test conversations, expected outputs and the function source in version control, and rerun the suite after any edit to a function, any change to its valves, and any change to the Python dependencies it imports. Assign an owner for each function, who signs off on its test results before the production upgrade proceeds. Without that ownership, the first failing function usually surfaces as a user complaint rather than a planned finding.