Open WebUI in practice

Where I landed

The series opened with the case for self-hosting and then spent seven articles building. The Docker host now runs a chat interface, a local language model (with an alternate inference engine for power users), a self-hosted search backend, a remote-access edge, and an image-generation pipeline — all behind one URL that asks for a PIN at the door. The closer is not another service. It is the Open WebUI moves that turn the interface from a chat box into a workbench.

Automations: scheduled chats, no extra service

An Automation is a saved prompt, a model, a cron expression, and an optional set of tools and knowledge attachments. At the scheduled time, Open WebUI starts a chat as if you had typed the prompt yourself, runs it to completion, and saves the conversation in a folder you nominate. The answer is waiting when you open the folder in the morning.

Setup lives under Workspace → Automations. A new automation asks for:

• A name and a cron expression. The UI accepts five-field cron (30 6 * * * for 06:30 daily). I keep mine to a small set: morning briefing, weekly digest, end-of-day notes catch-up.
• A model. Same dropdown as the chat picker — local model via Ollama for routine runs, an OpenRouter model when the job needs more horsepower than the laptop can spare. Cost stays bounded because the job runs once.
• The prompt. Plain text, the same as a chat message. Open WebUI substitutes the usual variables into prompts — {{CURRENT_DATE}}, {{CURRENT_DATETIME}}, {{CURRENT_WEEKDAY}}, {{USER_NAME}}. Use them; "today is the 14th" answers tend to drift otherwise.
• Tools and knowledge. The same toggles available in a normal chat — web search, image generation, attached document collections. A morning briefing that searches the web becomes a checkbox.
• The folder the output lands in. The chat appears there with a timestamp, ready to read.

A concrete recipe that exercises three earlier articles at once — Ollama (article 3), SearXNG (article 5), OpenRouter as a fallback (article 2):

# Automation: "Morning briefing"
# Cron: 30 6 * * *
# Model: deepseek/deepseek-v4 (OpenRouter) — fast, cheap, good at structure
# Tools: web_search ✓
# Folder: Briefings

It is {{CURRENT_WEEKDAY}}, {{CURRENT_DATE}}. Produce a brief covering, in this order:

1. AI / open-source ML — releases, papers, notable forks (last 24h)
2. Self-hosting and homelab — useful posts, new tools, security notes
3. Local-first software — anything Tauri, Sciter, or Electron-killer adjacent

For each section, give three to five items. Each item: one
sentence of substance plus a link. Skip anything that is
press-release filler. End with a one-paragraph "what changed
this week" synthesis across the three sections.

The first run is the audit. Read the output, see where the model overreaches, tighten the prompt. Most of my Automations went through three or four revisions before they produced something I actually wanted to read. The cron is the easy part; the prompt is the work.

Settings the docs bury

Open WebUI's defaults were set when models behaved differently than they do now. A handful are worth changing on day one. Three places to set them, in increasing reach:

• Per model, in Workspace → Models → (your model) → Advanced Params. Overrides everything else.
• Per user, in User Settings → General → Advanced Parameters. The defaults you see in new chats.
• Global defaults for all users, in Admin Panel → Settings → Settings (top right) → Model Parameters. Set once when you stand up a multi-user instance; the rest of this list applies the same way.

Organizing what you already have

The chat history sidebar gets unmanageable around the 200-chat mark, which on a daily-driver install is a couple of months.

Folders are the obvious move, with a less-obvious payload: every folder carries its own system prompt. Drop a chat into Code review and the model picks up "you are reviewing code; flag bugs, suggest cleaner expressions, do not rewrite without asking" without me typing it. Start a chat in Drafting and it inherits a different prompt — same model, no re-priming, no copy-pasting a preamble. The folder is the context; the chats inside it inherit it. I have lost count of mine somewhere past forty — each one a role I would otherwise be priming from scratch at the start of every session.

Notes attach to a chat as a free-form sidebar. They are not seen by the model unless you explicitly reference them. Their job is the human side: what was I trying to do here, what did I conclude, what to come back to. I use them as the answer to "why does this six-week-old chat exist" — the question Open WebUI's auto-generated title rarely answers well.

Knowledge collections are the third move. Upload a folder of documents — project specs, internal docs, a paper you keep coming back to — and attach the collection to a model. Open WebUI runs retrieval against the collection on every prompt and feeds matched chunks into the context. The mechanism is RAG; the user-facing surface is "the model now knows about my project". For a small team this is the simplest way to give everyone the same shared context without paying a vendor to host it.

Moves worth knowing exist

Four features that each deserve their own article. Just the names and shapes, enough to find them later.

Tools. A tool in Open WebUI is a Python function with a typed signature; the model sees it as a callable, the user sees it as a toggle. Write a function that calls your home automation, your weather station, your work API; expose it to the model. Combined with native function calling (see §2), this is how the assistant stops being a chatbot and starts being an agent on your terms — without leaving the interface.

Filters and Pipelines. Filters intercept requests and responses — strip PII before a prompt leaves the box, redact a model's output before it lands in the chat, attach metadata. Pipelines are a heavier abstraction that can route between models, fan out and merge, or implement custom RAG. Both are the escape hatch when "saved prompt in Automations" is no longer enough.

HTML artifact rendering. Open WebUI detects HTML in the model's output and offers an inline preview pane. Pair this with asking the model for HTML instead of Markdown — the topic of a separate article on this site — and the assistant can produce charts, diagrams, small interactive demos, and dashboards that render the moment the stream finishes. The fastest way to see this is to ask any current model to "make a small HTML comparison of three options I am considering" and watch what comes back.

OpenAPI tool servers. Any service that publishes an OpenAPI spec can be added as a tool source without writing Python. A handful of community-maintained servers already exist for filesystem access, time, memory, and more. The pattern is the right shape for letting a model touch a service you already run, on its own surface, instead of building a bespoke integration.

What you have now

A private chat interface. A local model for the work you would rather not send out, a cloud model for the work where capability matters more than privacy. A search backend that does not meter you. A remote-access edge that asks for a PIN. An image-generation pipeline. The workspace customizations above. None of it locked to a vendor. All of it yours.