Open-WebUI-Functions is a folder of Python you paste into the admin panel

There is no install step, so the security model is whatever the admin pastes

The whole installation procedure is six steps through the web interface. You need admin rights in Open WebUI, you navigate to Admin Settings, you open the Functions tab, you click Add New Function, you paste the code from this repository into the function editor, and you set whatever environment variables that particular file needs. Saving it makes it available inside Open WebUI.

There is no pip install, no container, and no package version to pin. Whatever Python ends up in that editor is running inside your instance, which means the review step is a human reading a file before pasting it into a production chat server. That is a real property, not a gap: the code is inspectable in full before it touches anything.

The same property is a cost. A function you pasted has no commit history, no test, and no way to diff it against the version upstream later. When the maintainer changes the file, there is nothing telling you that. The `pipelines/` and `filters/` layout makes discovery easy, but upgrade is manual by construction.

WEBUI_SECRET_KEY gates the encrypted: prefix that every stored key uses

The functions carry a shared mechanism for handling API keys, and it depends on one environment variable being set in the Open WebUI environment or `.env` file:

# Set this in your Open WebUI environment or .env file
WEBUI_SECRET_KEY="your-secure-random-string"

With that variable in place, the behaviour is documented as automatic. Keys and other sensitive values are encrypted when stored, and the stored form carries an `encrypted:` prefix followed by the encrypted data. Encryption and decryption happen transparently when a value is read, so the calling code does not change.

The failure mode is quiet. Without the variable set, the encryption features do not work properly, and the instructions call that out as required rather than optional. A function that reads a key and finds it in plain text will not raise; it will simply return the string, and the difference between an encrypted and an unencrypted stored value is one prefix. If you are auditing an instance, check that the values in your function configuration actually begin with `encrypted:` rather than assuming they do.

The Azure pipeline carries most of the configuration surface, and half of it is Azure OpenAI only

The `pipelines/azure/` directory holds the largest of the four provider folders, and `azure_ai_foundry.py` is where the environment variables concentrate. Several of its features are explicitly marked as Azure OpenAI only, which is the first thing to check before assuming a capability transfers to another Azure AI model.

Azure Search and RAG integration is one. So is the native Open WebUI citations support: rich citation cards, source previews, relevance scores, and automatic conversion of `[docX]` markers into clickable markdown links. The relevance scores come from Azure AI Search as two separate numbers, a BM25 keyword score and a semantic rerank score, and each is normalised independently through `BM25_SCORE_MAX` and `RERANK_SCORE_MAX` before being shown as a percentage. Two dials rather than one means you can decide what counts as a strong keyword match versus a strong semantic match.

Model selection is either explicit or inferred. Set `AZURE_AI_MODEL` to a semicolon- or comma-separated list, for example `gpt-4o;gpt-4o-mini`, or let the pipeline extract the model from the Azure OpenAI URL. A predefined catalogue covering GPT-4o, GPT-5, o3, o4-mini, Phi-4, DeepSeek-R1/V3, Mistral, Llama 3.x, Cohere, and Grok is available through `USE_PREDEFINED_AZURE_AI_MODELS`, and the display prefix in the model picker is set by `AZURE_AI_PIPELINE_PREFIX` so you can tell an Azure pipeline apart from a native one.

Authentication defaults to an `api-key` header; `AZURE_AI_USE_AUTHORIZATION_HEADER` switches it to an `Authorization: Bearer` token. Token usage is tracked by requesting `stream_options.include_usage` during streaming.

filters/ holds three small utilities that run on every request

The `filters/` directory is short enough to read in full, which makes it the right place to start if you are deciding whether this repository is trustworthy. It contains `google_search_tool.py`, `time_token_tracker.py`, and `vertex_ai_search_tool.py`.

The two search tools are separate because they target different providers: one is Google search, the other Vertex AI search. The time token tracker is the odd one out and is not a vendor connector at all, which is a useful reminder that a filter in Open WebUI is simply a hook that sees requests and responses rather than a model backend.

A filter applies custom logic to refine, manipulate, or preprocess input and output data. That is a broader position than a pipeline has: a pipeline extends Open WebUI with a model or a data transformation you select by name, while a filter sits in the path of traffic that already exists. The distinction matters when you are debugging, because a filter that misbehaves affects every conversation rather than the one model you picked.

docs/ is the real documentation, and the README is only the index

Seven Markdown files sit under `docs/`, and the file names tell you what the repository is actually for. There is `azure-ai-integration.md` and `azure-ai-citations.md`, so Azure is documented as two separate concerns rather than one. There is `google-gemini-integration.md`, `infomaniak-integration.md`, `n8n-integration.md`, and `n8n-tool-usage-display.md`, which implies the N8N work covers both talking to a workflow and showing what its tools did. The seventh is `setup-azure-log-analytics.md`, which is a deployment concern rather than a model concern.

So the repository is four integrations and one Azure operations guide, documented individually. That is a different shape from a framework: there is no shared abstraction to learn and no configuration file to understand, just a set of files each solving one problem.

The `pipelines/` tree mirrors it with a directory per vendor, `azure/`, `google/`, `infomaniak/`, and `n8n/`. Read that as the map. If your provider is not one of those four, nothing here will help you, and the closest comparison is the general shape of the Azure pipeline rather than any documented alternative.

GitVersion drives version badges across five GitFlow branch types

The version table in the README has an empty value for every row: `main`, `hotfix/*`, `release/*`, `dev`, and `feature/*`. Those blanks are populated by a workflow, and a `GitVersion.yml` at the repository root configures it. The version is derived from Git history and branch names rather than typed into a file, which is why the table looks unfinished on the rendered page.

The release history is short. v1.0.0 was tagged on 2026-03-16 and v1.0.1 on 2026-04-30. The last push to the repository was on 2026-08-19.

The branch scheme is worth noting if you fork. A `feature/*` branch gets its own version, and a `hotfix/*` branch gets a different one, so two people working on two branches are producing functions with different version strings even when the code is identical. That is useful when you want to trace which build of a function reached an instance, and it is noise if you do not.

Development tooling in the repository root is minimal and modern: `pixi.toml` and `pixi.lock` for environment management, `ruff.toml` for linting, and a `CLAUDE.md` at the top level. There is no test directory in the tree, which for a collection of pasted functions is the most significant thing about the layout.

Streaming and non-streaming support is a claim you can check per function

Two features are listed at the repository level rather than per file: flexible configuration through environment variables, and both streaming and non-streaming support for real-time and batch processing. They are listed that way because they are properties of how the functions are written, not settings you turn on.

This is the part to verify per function rather than assume. The Azure pipeline's token usage tracking works by requesting `stream_options.include_usage` in the streaming request, so any feature that depends on usage data depends on the streaming path being the one in use. A pipeline that only exercises its non-streaming branch will not produce that data, and the absence of a token count is then a property of the request mode rather than evidence of a bug.

The same caution applies to the N8N integrations. `n8n-integration.md` and `n8n-tool-usage-display.md` being separate documents suggests tool usage display is a distinct concern from the workflow call itself, and whether a given N8N pipeline surfaces tool usage is a question for that specific file rather than for the repository as a whole.

Editorial conclusion

Open-WebUI-Functions fits an administrator who wants a vendor connector or a preprocessing filter without writing an Open WebUI extension from scratch, and who is comfortable pasting Python into a running instance. It does not fit a team that wants version-pinned, reviewable code in its own repository, since a pasted function has no history and no upgrade path except manual re-pasting. Before you paste anything that touches a paid API, set `WEBUI_SECRET_KEY` in the Open WebUI environment, because the encryption that protects stored keys is inert without it, and then check whether the pipeline you want needs an Azure OpenAI endpoint specifically rather than another Azure AI model.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. owndev/Open-WebUI-Functions on GitHub
3. Project website
4. README
5. Releases