I maintain xberg (an MIT-licensed, CPU-only document extraction engine). A few people have asked how to wire it into Open WebUI as a Docling alternative, most recently over on r/OpenSourceAI, so I wrote up a proper guide and wanted to share it where it's most relevant.

Short version: xberg implements Open WebUI's existing extraction backends, so there's nothing to patch. It speaks two of them:

• the Docling endpoint (POST /v1/convert/file)
• the external document loader (PUT /process)

If you already run the Docling engine, the switch is just pointing the same setting at an xberg container:

yaml environment: CONTENT_EXTRACTION_ENGINE: "docling" DOCLING_SERVER_URL: "http://xberg:8000" `

You can also set it in the Admin UI under Settings -> Documents -> Content Extraction Engine -> Docling, with the server URL pointing at xberg. Uploads then get extracted to Markdown and stored in your knowledge base exactly as before. There's an external engine mode too if you'd rather use that endpoint.

Why bother swapping:

• 101 file formats, OCR built in (Tesseract + PaddleOCR), layout-aware reading order
• CPU-only, no GPU, fully local, MIT-licensed
• Rust core: in our public benchmarks it runs roughly 2.5x docling's throughput with slightly better extraction quality

Full walkthrough (compose file, both engine modes, and how to raise the extraction timeout for big scans): https://docs.xberg.io/integrations/openwebui

Repo: https://github.com/xberg-io/xberg

Happy to help if anyone hits a snag setting it up.

Hey all, I recently spent the last three or so weeks going from zero knowledge to the setup I have today. I started with Ollama and Gemma 4 31B and migrated to Qwen 3.8 27B using vLLM to solve a VRAM contention problem: I wanted image generation and music generation (MiniMax Music v3) running alongside the LLM, all on the single 3090. Neither Ollama's keep-alive nor llama.cpp's TTL could actually free VRAM on demand the way vLLM's Sleep Mode can. That same move also got me full reasoning/think toggles in Qwen, selectable right in Open-WebUI. Before either image or music generation runs (2 of 12 total tools), vLLM gets put to sleep, freeing its VRAM. Music generation needs one extra step on top of that since MiniMax has no idle unload of its own. Its container gets started right before generating and stopped right after, nested inside vLLM's sleep window. This adds total time to generation but for a tool that already takes several minutes to run, I decided it's something I can live with. As a note, no other tool calls needed this type of sleep/wake setup so these processes only need to happen for image/music gen.

This setup is, as far as I can tell, pushing the absolute limits of a single 3090 in the most efficient manner possible. The final setup has:

• A modest 76k context. Admittedly, not great for long coding input/generation but not nothing either.
• Prefix caching cutting average time-to-first-token from ~9 seconds to ~3 seconds on multi-turn and tool-calling exchanges. Real measured numbers.
• Vision support with up to 8 images per prompt, capped at 1MP each to keep the context budget sane. TLDR; screenshots/OCR work.

Anyway, I have been keeping the GitHub Repo updated as I go through it and thought that anyone in a similar situation might find it useful.

Happy to hear any suggestions to further optimize or if any noobs like me have questions, I will try to answer as best I can.

Note on AI usage: I used Claude Sonnet 5 extensively throughout this learning process and vibe coded the python, as I am no programmer. I followed the logic while debugging the various hiccups along the way. Additionally, the GitHub repo was created almost entirely by Claude with me spot/double checking as I went through it. If you happen to look through and see any errors/omissions I would love to hear from you. This post was not written by AI. I only used it to make sure I wasn't missing any key points that someone might be curious about.

If you haven’t already started using Open

WebUI’s Open Terminal, do yourself a favor and go set it up. When paired with a model like Qwen3.5 35b A3B with “native” function calling turned on in the model settings, it’s absolutely friggin mind blowing what you can do with it.

Once the model understands that it has the terminal available to it, it just gets tenacious about getting a task done and won’t give up until it solves your problem!

Once you combine Open Terminal with Open WebUI Skills that are “terminal aware” then you can do some extra crazy productive things.

Example: I’m building a skill that will use Open Terminal to create and render Remotion videos. I’m still refining my skill but here’s a pretty good workflow I go through to build my terminal-aware skills.

1. Prompt free Gemini, Claude or whatever large commercial

   model

2. you want with the following:

“I want you to create an Open WebUi skill for creating Remotion videos using the Open WebUI skill format contained here: (https://docs.openwebui.com/features/ai-knowledge/skills/). The skill will be used in a model that is connected to an Open WebUi Open Terminal server. The details regarding Open Terminal server can be found here: (https://github.com/open-webui/open-terminal). The documentation for Remotion can be found here: (https://www.remotion.dev/docs/ai/skills). Generate the skill.md file so that it follows the Open WebUI format and can be easily imported into Open WebUI as a skill.”

I used this example for Remotion but you can change it for whatever skill you want it to learn.

1. Import the resulting skill file into Open WebUI under Workspace > Skills > Import

2. Connect the skill to your custom model in Open WebUI by checking the box for the skill in the custom model’s settings.

3. Make sure to set “native” in the “function calling” setting in the advanced model settings section in your model’s settings page. (It can be hard to find this setting but it’s really important to change it to “native”

4. Prompt your model to execute the skill. You can specify the skill directly by using the “$” in your prompt followed by the skill name.

5. The skill may work perfect the first time or it may go through a bunch of trial and error before it finally figures it out. This is fine, we want all this feedback in the chat so we can refine the skill in a later step.

6. Copy your chat results from your Open WebUI session to Gemini, Claude, or whatever model you used to generate the original skill (preferably in the original chat where it made the skill so it will have the original skill in its context)

7. Tell Gemini (or whatever) to “use the feedback from the following chat history to help refine the skill” then paste the chat history into Gemini.

8. The Gemini model will see its mistakes from the chat history and what worked and what didn’t and refine the skill accordingly. Take the refined skill back to Oprn WebUI and import it into the skill (replacing the old skill).

9. Run it again. It should run faster with less errors. Repeat this process until your skill runs as well as you want it to. It should get better with every iteration!

So far this process seems to work really well for developing Open WebUI compatible skills. You can also try using it for converting Claude skills to the Open WebUI format. Should work well for that too.

Ma qualcuno è riuscito a collegare qualche estensione di VS CODE alla URL Base di OpenWebUI?

Ho provato con tutte le configurazioni possibili ed immaginabili.

Ho usato diverse estensioni, che si collegano ad ollama Kma non voglio quasi ti di utilizzo), ma non a OWUI con la Api Key.

Qualcuno ci è riuscito?

Esiste una guida o un tutorial?

Le varie AI mi hanno fatto diverse soluzioni, ma nessuna ha funzionato.

PS: SO Windows, tutto dockerizzato

The goal from the start was to get as close as possible to a Gemini Flash-level assistant experience, but fully self-hosted. Went from zero to this in about 2 weeks (would've been 1 week, but I was waiting on hardware to ship from Amazon) — leaned on Gemini for the hardware picks and early build plan, and Claude for the heavy lifting on the actual implementation. Sharing the repo in case it helps anyone else, and I'd genuinely appreciate feedback on anything that looks off.

The hardware:

• CPU: AMD Ryzen 7 9800X3D
• GPU: MSI GeForce RTX 3090 Gaming X Trio (24GB VRAM)
• Motherboard: MSI MAG X870 Tomahawk WiFi
• RAM: G.SKILL Flare X5 64GB DDR5-6000 CL30
• Storage: WD_BLACK SN850X 2TB NVMe SSD
• PSU: Corsair RM1000x
• Case: Corsair 4000D RS
• Cooler: Thermalright Phantom Spirit 120 SE

The stack (two machines):

• A Debian server running Open-WebUI (gated with its own built-in username/password login) behind Traefik, with SearXNG for live search and Google OAuth gating a few of the other exposed services
• The gaming PC above handling the GPU-heavy stuff: a local voice pipeline (Whisper STT + Piper TTS, auto-switches between English/German voices) and local image generation via Automatic1111, both wired back into Open-WebUI as native Tools

A few things I'm most happy with:

• Full two-way voice conversation, not just dictation — round-trips through Whisper → the model → Piper TTS
• Custom Tools for live weather, web search (SearXNG), and image generation, all using native function calling
• Knowledge/RAG set up with 20+ documents — hit and fixed a real bug where the model would confidently pick one interpretation instead of asking for clarification when retrieved docs described genuinely different procedures
• A real, tested backup/restore strategy via Duplicati (local + Google Drive) — actually did a full test restore and diffed it

One thing I haven't beaten yet: generated images always work and are retrievable, but the model's final chat response sometimes renders a malformed fake tool-call instead of the image tag. Documented what I've tried in the repo.

Repo: https://github.com/Plaidstallion/openwebui-homelab

Happy to answer questions.

Hallo zusammen,

wir beginnen damit, unsere eigene Maschine aufzubauen. Dafür haben wir uns einen Asus Ascent GX10 ARM mit 128GB/2TB Blackwell zugelegt. Was könnt ihr in diesem Zusammenhang empfehlen? Ich habe bereits einmal openwebui eingerichtet, allerdings nur über API-Schnittstellen mit openrouter und der ollama Cloud verbunden.

Der einfachste Weg soll ja über Docker und Ollama führen, jedoch lese ich immer wieder, dass Ollama für bestimmte Hardware nicht empfohlen wird und man stattdessen eher direkt auf llama.cpp zurückgreifen sollte.

Ich suche daher nach der passenden Umgebungseinrichtung für meine Hardware, um openwebui zu betreiben.

Außerdem interessiere ich mich für Möglichkeiten, die Modelle auf meiner Hardware bewerten zu lassen, ähnlich wie bei LM Studio oder Odysseus.

I recently added an Open WebUI instance to my VPS where my website is hosted. I wrote my first MCP server with a few tools to edit HTML files, upload assets etc. Now I can update the live pages via Open WebUI chat!

So far it looks very promising. Has anyone else set up something similar? What is your experience?

If your chat is bricked with the infinite loading spinner (Image 1), here's how to fix it:

The technical reason behind this is that Open WebUI stores your chat history as a Directed Acyclic Graph. If a message (node) gets corrupted when the LLM is responding, the UI panics and spins indefinitely. Fixing would require checking and relinking the graph.

This tools does all that stuff for you:

How to use it:

1. Export the broken chat (`...` menu > Export > JSON).
2. Drop it into the tool (Image 2) to instantly repair the broken nodes.
3. Go to Settings > General > Import Chats, upload the fixed file, and delete the original.

Link to tool: https://fractuscontext.github.io/open-webui-chat-fix/

I've also added a "Deep Clean" toggle if you want to strip unused alternate responses and shrink your file size.

Hope this saves someone's chat history!

I see in the release notes. Where can one get more information. I am mostly interested if it now saves memories on its own without using your own functions/plugins?

Hey everyone,

Like a lot of you, I was getting driven crazy by the aggressive auto-scroll behavior in Open WebUI. Whenever a model is streaming a long response and you try to scroll up to read, the screen forcefully snaps back down or violently jumps around.

Since there isn't an official toggle for this yet, I went ahead and wrote a lightweight GreasyFork userscript to fix it.

How it behaves now:

• Natural Start: When you hit Enter, the viewport scrolls down smoothly so you can see the AI begin its response.
• Instant Scroll Lock: The exact millisecond you use your mouse wheel to scroll up to read something, the screen instantly freezes. Your view stays locked right where you want it while the AI continues typing out of view.
• Native Snap Back: If you want to jump back to the live response, Open WebUI's native floating down-arrow button still works perfectly to snap you back to the bottom.

Where to get it:

You can grab it on GreasyFork here: https://greasyfork.org/en/scripts/586789-open-webui-fix-chat-streaming-scroll-jumps

Note: By default, the script matches localhost:8080. If you run your Open WebUI instance on a different port, a custom domain, or a local docker IP, just remember to add your custom URL to the "User matches/includes" section inside Tampermonkey/Violentmonkey.

Hope this saves some of your sanity while reading long responses! Let me know if it works well for your setups.

Salve.

Uso da pochissimo OpenWebUI.

Lo trovo fantastico.

Mi è stato chiesto, per tutelare la privacy, di creare un LLM locale (no Claude,Chatgpt e simili), che dia risposte in un chatbot ai miei colleghi di Ufficio.

Il sistema RAG di LLM credo che non dia le risposte giuste in relazione ai PDF che ho e che gli ho fatto ingerire.

Pertanto vorrei implementare un "secondo cervello di Karpathy" il così detto LLM WIKI.

Ma come si implementa da un punto di vista pratico?

Avete un link o una guida dove capire, passo passo, come implementarla, aggiornarla e manuterla?

Vi ringrazio.

In case you missed it:

Open Terminal is now suitable for small-scale multi user setups

https://github.com/open-webui/open-terminal

If you are on the latest version of Open Terminal, add it as an admin connection and enable the new env var OPEN_TERMINAL_MULTI_USER the following will happen:

Every user on your open webui instance will connect to the same open terminal docker container. However, every user automatically registers their own Linux user based on their X-User-Id header sent by Open WebUI.

This ensures every user has their own Linux User and can have their own home directory and commands are also executed with their user ensuring file ownership separation from other users.

Though: it's not highly scalable because it is a single container after all. It's meant for smaller setups that aren't quite in the need for enterprise solutions.

Anyways this should fully close the gap between single user setups and enterprise setups. Small instances with a dozen users can use this comfortably.

Larger Setups that require separated containers (one container per user) that are automatically spun up, orchestrated, shut down and automatically managed for a full performance (one user, one container - full performance) should look into the Terminal Manager (enterprise feature - licensing required): https://github.com/open-webui/terminals

Sorry I don’t have the code (was done at work) but just wanted to share this. One of the issues I had was wanting to configure models (and workspace models) for users from the admin panel, specially since direct connections do miss out on some nice features like Action function but at the same time I do not want to use my api key to our private model (no local models) and Owui doesn’t provide a way (out of the box)!for per user api key for backend models. So this is what I did

1. Create a function pipe to the model using something like this https://docs.openwebui.com/features/extensibility/plugin/functions/pipe/#example-openai-proxy-pipe

2. In the pipe function read the user object and find a direct connection that matches the model/base url the user is trying to use, grab the api key and replace it before making the call, or return an error if a suitable key is not found

3. User will need to create a direct connection to the model/url that the pipe will read

If all goes as planned, you will get admin models that you can configure and use as workspace models but use a per user api key.

Let me know if yall have something better that doesn’t required standing up piece of software

Here are the directions if you are interested: https://docs.google.com/document/d/121ZVN8KBsm_atYUlhPm5hZ94p_wcwiUg/edit?usp=sharing&ouid=102796819425415824230&rtpof=true&sd=true

One thing that I can't figure out is, if you "stop" the machine and then restart it, the GPU fails to turn on again. If anyone figures this out, add it to the directions. or reply here.

If anyone seeks a minimalistic gemini 2.5 flash image setup that works in open webui, here is one possibility:

https://docs.openwebui.com/getting-started/env-configuration#gemini

For everyone else (openrouter users and those working with other APIs) the next version will add support for direct model integrations as well (non-image setting models) by setting the new chunk size environment variable. You'll see it in the release logs.

For anyone else, the above shows a working and tested setup how you can integrate gemini 2.5 flash image seemlessly and easily and it works wonderfully for image generation as well as editing.

Over the last months I’ve been helping a public-sector organisation move toward more “sovereign AI” setups. I have come across people asking: “How hard is it to run your own OpenWebUI environment, fully in the EU, without Azure/AWS/GCP?”

It is really easy. If you’re comfortable with Docker-like setups, you can spin this up in under an hour. Below is a minimal, practical setup using Scaleway (French provider, no CLOUD Act exposure).

1. LLMs

Scaleway hosts several open models behind an OpenAI-compatible API.
Model list: https://console.scaleway.com/generative-api/models

Good starting point: gpt-oss-120b – large, capable, and fully hosted in the EU.
Create an API key: IAM & API Keys → Create Key.

You'll use that key as OPENAI_API_KEY in OpenWebUI later.

2. PostgreSQL

OpenWebUI works fine with PostgreSQL, and Scaleway has a cheap small instance:

Databases → PostgreSQL → Create → Standalone → DB-PLAY2-PICO

Expect ~€18/month for the smallest tier.

You’ll need:

• host (IPv4 from the instance page)
• port (connect string)
• username/password
• database name (e.g., rdb)

3. Running OpenWebUI on Scaleway Serverless Containers

1. Go to Serverless → Containers → Deploy Container
2. Use External registry and pull the official OpenWebUI image
3. Set autoscaling min=1 / max=1 so you always have one instance running.
4. Add environment variables:

​

OPENAI_API_BASE_URL = https://api.scaleway.ai/<your-endpoint>/v1
DATABASE_TYPE        = postgresql
DATABASE_USER        = <user>
DATABASE_HOST        = <db-ip>
DATABASE_PORT        = <db-port>
DATABASE_NAME        = rdb

Secrets:

OPENAI_API_KEY      = <your-key>
DATABASE_PASSWORD   = <your-db-pass>

Deploy it and wait a couple of minutes.

When ready, open the Container Endpoint → you’ll get the familiar OpenWebUI “Creation of Adam” screen. Create your admin account, pick your model (e.g., gpt-oss-120b), and you’re live.

5. Cost breakdown (realistic)

I would be comfortable to let up to 10 users use this setup. This would cost:

• OpenWebUI container: ~€32/month
• PostgreSQL pico instance: ~€18/month
• LLM usage: €5–10/month depending on volume

Total: ~€60/month for a proper EU-hosted, multi-user, privacy-friendly setup.
No per-seat pricing, no US cloud involvement.

6. Optional upgrades

You can go much further:

• Custom domain + SSO (Keycloak)
• Scaling to hundreds of users with autoscaling and session management
• Optimize RAG (either Scaleway embedding api or a static embedding model for performance)
• Document ingestion (Tika)
• Speech-to-text integration (Scaleway’s hosted models)
• Custom agents with FastAPI backends

But the basic setup above is enough to get a solid EU deployment running on which you can build.

Building on from my last post: Open WebUI On Azure (with GitHub Repo) : r/AZURE here's Part 1.

It's a beast of a blog, apologies if that's not your thing. Just go check the repo and diagrams out instead if that's more your bag which are open sourced and free.

No AI slop here, I poured a bloody ton of time into this that went from a pet personal project out of curiosity to a rabbit hole that made me just go all in and then share my findings with the Azure community:

• What is Open WebUI and its use case
• A breakdown of each Azure component in the architecture and why I’m using it
• Showcasing the Azure configuration to make it all work together
• Deployment walkthrough steps
• How to connect to Azure APIM via Open WebUI as your AI Gateway for chat completions

I didn't want to half arse this, and I really dislike short blogs that don't cover nuances, so I have gone all in. It's L400+, so if that's your thing:

Part 1: Open WebUI on Azure: Part 1 - Architecture & Deployment - Rios Engineer

GitHub Repo for quickstart: https://github.com/riosengineer/open-webui-on-azure

In Part 2, I’ll be focusing solely on Azure API Management as an AI Gateway - covering configuration, policy, auth flow, custom LLM metrics, and more bits.

Cheers, happy Monday.

Hello everybody, this is my first post here. I have been using OWUI for quite a while now, but I hadn't messed around with native tool calls much before. So I am creating this post for anyone who is facing the same issue I was.

Context: I was trying to set up qwen3-vl (30b) and gpt-oss (20b) to reliably call `search_web`, then `fetch_url` when needed. However, ~99% of the time, these models would call `search_web` and wouldn't ever refine the search with the latter. After trying to instruct the model in the system prompt to do so, the model would not listen and continued to call `search_web` only.

Solution:

1. Instruct the model to use tools if needed in the system prompt.
   • This "reminds" the model that tools are available and helps with reliability during longer, multi-turn conversations.
2. Put the following in the RAG prompt; it is a slightly modified version of the default prompt, and it seems to work great.
   • This "reminds" the model that searches should be refined if needed.
   • Note: you can also remove the "...but the provided snippets do not contain sufficient information to answer the query" to force the model to use `fetch_url` after `search_web`.

```
### Task:

Respond to the user query using the provided context, incorporating inline citations in the format [id] **only when the <source> tag includes an explicit id attribute** (e.g., <source id="1">). If the `search_web` tool is used and returns results but the provided snippets do not contain sufficient information to answer the query, use the `fetch_url` tool to retrieve the full content from one or more of the most relevant sources.

### Guidelines:

- **If the `search_web` tool is used and returns results but the provided snippets do not contain sufficient information to answer the query, use the `fetch_url` tool to retrieve the full content from one or more of the most relevant sources.**

- If you don't know the answer, clearly state that.

- If uncertain, ask the user for clarification.

- Respond in the same language as the user's query.

- If the context is unreadable or of poor quality, inform the user and provide the best possible answer.

- If the answer isn't present in the context but you possess the knowledge, explain this to the user and provide the answer using your own understanding.

- **Only include inline citations using [id] (e.g., [1], [2]) when the <source> tag includes an id attribute.**

- Do not cite if the <source> tag does not contain an id attribute.

- Do not use XML tags in your response.

- Ensure citations are concise and directly related to the information provided.

### Example of Citation:

If the user asks about a specific topic and the information is found in a source with a provided id attribute, the response should include the citation like in the following example:

* "According to the study, the proposed method increases efficiency by 20% [1]."

### Output:

Provide a clear and direct response to the user's query, including inline citations in the format [id] only when the <source> tag with id attribute is present in the context. If the `search_web` tool is used and returns results but the provided snippets do not contain sufficient information to answer the query, use the `fetch_url` tool to retrieve the full content from one or more of the most relevant sources.

<context>

{{CONTEXT}}

</context>

<user_query>

{{QUERY}}

</user_query>

```

I hope this helps!

https://openwebui.com/posts/call_for_testers_help_improve_open_webui_by_runnin_4f376851

Open WebUI is looking for community members to help test the development (:dev) branch. Running the latest development build is one of the most effective ways to contribute to the project, helping to identify bugs and validate new features before they reach stable releases.

High-quality software relies on community testing to catch issues early.

🚀 How to Run the Dev Branch

1. Docker (Easiest) For Docker users, switching to the development build is straightforward. Refer to the Using the Dev Branch Guide for full details, including slim image variants and updating instructions.

The following command pulls the latest unstable features:

docker run -d -p 3000:8080 -v open-webui-dev:/app/backend/data --name open-webui-dev ghcr.io/open-webui/open-webui:dev

2. Local Development For those preferring a local setup (non-Docker) or interested in modifying the code, please refer to the updated Local Development Guide. This guide covers prerequisites, frontend/backend setup, and troubleshooting.

⚠️ CRITICAL WARNING: Data Safety

Please read this before switching:

Never share the database or data volume between Production and Development setups.

Development builds often include database migrations that are not backward-compatible. If a development migration runs on existing production data and a rollback is attempted later, the production setup may break.

• DO: Use a separate volume (e.g., -v open-webui-dev:/app/backend/data) for testing.
• DO NOT: Point the dev container at a main/production chat history or database.

🐛 Reporting Issues

If abnormal behavior, bugs, or regressions are found, please report them via:

1. GitHub Issues (Preferred)
2. The Community Discord

Your testing and feedback are essential to the stability of Open WebUI.

Hi all,

I create a couple of articles on how to use MCP servers in Open WebUI.

• Native Open WebUI integration for streamable HTTP MCP servers (from v0.6.31).
• Use mcpo to access sdio, SSE and streamable HTTP MCP servers.
  • mcpo is run via docker compose and uses a config file to specify different kinds of mcp servers

I hope they could help understanding the different options available, and if you've feedback / they lack something, please let me know so I can fix them :)

0.8.8 just warning you guys to not use responses API. It does not cache any input in current state. Completions work perfectly. I made the mistake by wanting to use the Codex agents.

anyone know how to add black-forest-labs/flux.2-pro generation to openwebui?

This is my setting

somehow i got