ModelRefs / Open WebUI — AI Glossary

Open WebUI — AI Glossary

A self-hosted web UI for LLMs supporting Ollama and OpenAI-compatible APIs, with RAG, model management, and multi-user support.

Overview

Open WebUI (formerly Ollama WebUI) provides a Slack-like chat interface for local and cloud LLMs. Features: Retrieval-augmented chat (document upload + vector search), model downloading, multi-user with role-based access, conversation history, and image generation. Deployed via Docker; actively maintained open-source project.

Reference details

Topicinfrastructure
Last reviewed2026-06-24

How it works

  1. A self-hosted web application provides the chat interface and talks to model backends over an OpenAI-compatible API, so local runtimes and hosted providers are reachable through the same configuration.
  2. Conversations, users and settings live in the application's own database, which is what makes history and multi-user access possible and what has to be backed up.
  3. Retrieval is built in: uploaded documents are chunked, embedded and searched, with the retrieved passages injected into the conversation.
  4. Role-based access separates administrators from users, so model availability and settings can be controlled centrally rather than per person.
  5. Model management can pull and remove models on the backend, which means the application's permissions include consuming the host's disk and memory.
  6. The deployment is a container plus a persistent volume, and the resource planning that matters is on the backend rather than on the interface — concurrent users multiply the key-value cache, not the web application.

Example: Why concurrent users are a backend memory question

Take a 7B model at 4-bit on a single 24GB accelerator: the weights are 7e9 x 0.5 = 3.5e9 bytes, about 3.5GB, leaving 24 - 3.5 = 20.5GB. Each concurrent conversation needs its own key-value cache, and for a 32-layer model of width 4,096 at an 8,192-token context that is 2 x 2 x 32 x 4,096 x 8,192 = 4,294,967,296 bytes, about 4.3GB per user. So the ceiling is 20.5 / 4.3 = 4.8, meaning 4 concurrent conversations at full context — not a number the interface advertises, and not one that scales with the number of registered accounts. Halving the context to 4,096 halves the per-user cache to about 2.1GB and roughly doubles the ceiling to 20.5 / 2.1 = 9.8, so 9 concurrent conversations. The practical consequence for a small-team deployment is that the user limit is set by context length and accelerator memory, so the first configuration change when a shared instance becomes unusable is the context setting rather than a larger model or a faster disk.

Commonly confused with

This is an interface and an orchestration layer, not an inference engine, and performance questions belong to the backend behind it. Generation speed, batch handling and memory use are properties of the runtime serving the model; the application contributes the chat UI, user management, conversation storage and retrieval. So a slow response is a backend or hardware question, while a missing model or an access problem is an application question. The related distinction is from a hosted assistant: this provides a comparable interface with the data staying on infrastructure you operate, which is the reason to run it and also the reason you now own the backups.

When to use it

Reach for it when:

  • Small-team or personal deployment where conversations must stay on your own infrastructure.
  • Giving non-technical users access to local or self-hosted models through a familiar interface.
  • Lightweight document chat, where the built-in retrieval is adequate and a dedicated pipeline is not warranted.
  • With backend memory planned from context length and concurrency, which is what sets the usable user count.

Reach for something else when:

  • As a production application platform, since it is an interface rather than an API layer with the controls an application needs.
  • At scale, where the backend's concurrency ceiling rather than the interface is the constraint.
  • Where retrieval quality matters, since the built-in pipeline is a convenience rather than a tuned system.
  • Without a backup plan for its database, which holds the conversation history and user configuration.

Continue your research

Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Open WebUI — AI Glossary.

Frequently asked questions

What is Open WebUI?

A self-hosted web UI for LLMs supporting Ollama and OpenAI-compatible APIs, with RAG, model management, and multi-user support.

What concepts are related to Open WebUI?

Closely related concepts include ollama, lm studio, rag.