# Open WebUI: a self-hosted chat front end for Ollama and OpenAI-compatible APIs

> Open WebUI puts a browser interface, user accounts and RAG on top of local or remote model runners. Here is what the repository documents, where the setup gets fiddly, and which deployments it does not fit.

**open-webui/open-webui** — Open WebUI is a self-hosted AI interface that runs entirely offline, supporting Ollama and OpenAI-compatible APIs with a built-in inference engine for RAG.

- Repository: https://github.com/open-webui/open-webui
- Website: https://openwebui.com
- Stars: 153,167 · Forks: 22,401
- Language: Python
- License: not declared
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/open-webui-open-webui

## What Open WebUI replaces, and for whom

Calling an Ollama model from a shell works fine for one person. It stops working the moment a colleague wants to try the model, or you want conversation history that survives a terminal restart. Open WebUI is the layer that fills that gap: a self-hosted web application that talks to Ollama and to any OpenAI-compatible endpoint, and adds accounts, groups, permissions and persistent chats around them. The README describes it as a "self-hosted AI platform designed to operate entirely offline", which is the load-bearing phrase. Nothing in the default path requires a request to leave your network, though the same README lists dozens of optional integrations (GroqCloud, Mistral, OpenRouter, Tavily, Jina and others) that do.

The audience is therefore narrower than the feature list suggests. It suits a small team or a single engineer who already runs a model somewhere and wants a shared interface in front of it. It also suits organisations that need per-group access control, since administrators define roles, groups and permissions rather than handing everyone an admin key. It does not suit someone who wants a hosted chat product with no server to look after. The README links to an Enterprise Plan covering custom theming, SLA support and Long-Term Support versions, which tells you the project's own view of where the free self-hosted path ends.

## How the request path actually runs

The repository splits cleanly. The frontend is SvelteKit and Vite (package.json declares @sveltejs/kit, vite and a static adapter); the backend is FastAPI and Uvicorn, with python-socketio for the live channels and message-flow features. The Dockerfile builds the frontend in a node:22-alpine3.20 stage, then copies the output into a python:3.11-slim-bookworm base. A single container serves both.

Persistence is SQLAlchemy with aiosqlite by default, and PostgreSQL is available through psycopg. Alembic is a dependency, so schema changes arrive as migrations rather than ad-hoc table edits. Files go to local storage or to S3, Google Cloud Storage or Azure Blob Storage. Retrieval is the part with the most moving pieces: the README lists nine vector databases (ChromaDB, PGVector, Qdrant, Milvus, Elasticsearch, OpenSearch, Pinecone, S3Vector, Oracle 23ai) and several extraction engines (Tika, Docling, Document Intelligence, Mistral OCR, PaddleOCR-vl, external loaders), with hybrid BM25 plus vector search and reranking on top. chromadb is a default dependency in pyproject.toml, so the simple path works without choosing anything, but the choice is real once documents matter.

Two details in the dependency list are worth reading closely. aiodns is deliberately pinned because, per the inline comment, 4.x pulls pycares 5 and breaks DNS on some hosts, with an opt-in escape hatch via AIOHTTP_CLIENT_ASYNC_DNS_RESOLVER. And aiohttp carries a "do not update to 3.13.3 - broken" note. Those are the marks of a project that has been bitten in production and pinned its way out.

## Installing Open WebUI with Docker Compose

The repository ships docker-compose.yaml, which is the shortest route to a working stack. It defines two services: ollama on the ollama/ollama image, and open-webui built from the local Dockerfile or pulled as ghcr.io/open-webui/open-webui. The open-webui service maps ${OPEN_WEBUI_PORT-3000} on the host to port 8080 inside the container, so the browser URL is http://localhost:3000 unless you override the variable. It depends on ollama and sets OLLAMA_BASE_URL to http://ollama:11434, which is how the two containers find each other on the Compose network.

Start it from the repository root:

```bash
docker compose up -d
```

When the containers are up, open http://localhost:3000. The first account you create is the administrator. The compose file also sets WEBUI_SECRET_KEY to an empty string; the README does not explain what happens in that case, so set it explicitly before you expose the instance to anyone else.

The README also lists pip, uv, Kubernetes (kubectl, kustomize or helm) and :ollama and :cuda tagged images as installation routes. If you would rather not run Ollama locally, point the same interface at an OpenAI-compatible API instead; the README names LMStudio, GroqCloud, Mistral, OpenRouter and vLLM as endpoints you can point the API URL at. Once a model is reachable, the two commands you will use most are `#` followed by a URL to pull a page into the conversation, and `#` followed by a document reference to pull from your library.

## The embedding model is a one-way door for your documents

The Dockerfile carries an explicit warning that deserves more attention than it usually gets. The USE_EMBEDDING_MODEL build argument defaults to sentence-transformers/all-MiniLM-L6-v2, and the comment above it states that if you change the embedding model, you cannot use RAG chat with documents you previously loaded: you need to re-embed them. This is not a bug. It is how vector search works, and Open WebUI is honest about it in the file rather than in the documentation site.

The practical consequence is that the embedding model is a decision you make before you ingest anything, not a setting you tune later. A team that starts with the default, loads a few thousand internal documents, then switches to intfloat/multilingual-e5-large for better multilingual support has to rebuild the index. If your corpus is large or your ingestion pipeline is manual, that is a real cost, and the Dockerfile's own comment is the only place in the repository that flags it.

A second limitation is subtler. Choosing among nine vector databases is presented as flexibility, but each one is a different operational dependency. PGVector keeps vectors in the PostgreSQL you may already run; Qdrant, Milvus, Pinecone and the rest add a service to monitor, back up and upgrade. The README does not rank them or say when the default is insufficient, so the selection is left to you.

## Where Open WebUI is the wrong tool

If you want a desktop application, look elsewhere or accept the compromise. Open WebUI is a server-rendered web app plus a Progressive Web App for install-to-home-screen behaviour. The README describes offline access for the PWA as working on localhost, which is a narrow claim: it is not the same as a native client that runs without a reachable backend.

If you need a stable, versioned API contract for other software to call, the project's own release cadence is the risk. Releases v0.10.2, v0.11.0 and v0.11.1 landed between 2026-07-01 and 2026-08-25, and package.json reports version 0.11.3. That is a fast-moving surface. The README does not document rollback, and there is no long-term support line in the free path; the Enterprise Plan is where LTS versions are listed. Pinning an image tag and reading CHANGELOG.md before upgrading is the only mitigation the repository itself offers.

Finally, if your requirement is a single-user CLI with no web server, Open WebUI is more machinery than you need. It brings a database, migrations, a frontend build and a session layer to a problem that `ollama run` already solves.

## How it compares with putting a gateway in front of the models

The closest alternative approach is a model gateway such as LiteLLM plus your own minimal UI, or simply pointing users at each provider's own console. The difference is where the work sits. A gateway normalises many providers behind one OpenAI-shaped API and leaves the interface to you; Open WebUI bundles the interface, the accounts, the groups, the chat history, the RAG pipeline and the plugin system into one deployable. If your problem is routing and cost accounting across providers, a gateway is the more direct answer. If your problem is that people need somewhere to type, Open WebUI is the more direct answer, and the README's plugin surface (Filters, Actions, Pipes, Tools, Skills, plus MCP, MCPO and OpenAPI tool servers) is what you would otherwise build yourself.

The trade-off is coupling. With a gateway you can replace the UI without touching routing. With Open WebUI the two are one container, one database and one upgrade cycle, and the RAG index lives inside that boundary. That is a reasonable price for a small team and a poor one for a platform group that already has opinions about each layer.

## Maintenance, licence and what to check before you commit

The repository is not archived, and the last push was on 2026-08-25. That is recent enough that the codebase is clearly moving, but the cadence also means you should treat upgrades as scheduled work rather than background noise. The upgrade path is the standard container one: pull a new image tag, restart, and let Alembic apply migrations against your database. Back up the SQLite file or the PostgreSQL database first, because the README does not describe a downgrade procedure.

On licensing, the honest answer is that the repository does not state a licence identifier. The repository root contains LICENSE, LICENSE_HISTORY and LICENSE_NOTICE alongside a CONTRIBUTOR_LICENSE_AGREEMENT, and pyproject.toml declares license = { file = "LICENSE" } rather than an SPDX string. The presence of a LICENSE_HISTORY file suggests the terms have changed at least once. Read the LICENSE file in the exact commit or image tag you deploy, and if the terms matter to your organisation, have someone qualified review them. Nothing here is legal advice, and a licence file that has a history is a licence file worth reading rather than assuming.

## Conclusion

Adopt Open WebUI if you want a browser chat layer over Ollama or an OpenAI-compatible endpoint and are willing to run the container yourself. Do not adopt it if you need a supported SLA out of the box, if you cannot re-embed documents when the embedding model changes, or if you expect the README to explain rollback. Before rolling it out, confirm the LICENSE file in the repository you clone, check that OPEN_WEBUI_PORT maps to the container's 8080, and decide up front which vector database you will commit to.

## FAQ

### Is Open WebUI free?

The repository is public and the README describes a self-hosted platform you install and run yourself, with no pricing on the install path. The same README links to a separate Enterprise Plan that adds theming, SLA support and Long-Term Support versions, so there is a commercial tier alongside the free one.

### Is Open Web UI fully open source?

The repository contains a LICENSE file, a LICENSE_HISTORY file and a LICENSE_NOTICE file, and pyproject.toml points to the LICENSE file rather than naming an SPDX identifier. The repository does not state a licence name, so check the LICENSE file at the commit you deploy.

### How do I use Open WebUI with Ollama?

The bundled docker-compose.yaml starts an ollama service and an open-webui service together, and sets OLLAMA_BASE_URL to http://ollama:11434 so the interface finds the runner on the Compose network. Bring the stack up and the models Ollama serves appear in the interface.

### How do I install Open WebUI on Windows?

The README lists pip, uv, Docker and Kubernetes as installation routes and does not describe a native Windows installer. Running the Docker Compose stack is the path the repository itself ships, and the host port defaults to 3000.

### How do I access Open WebUI from another computer?

The compose file publishes ${OPEN_WEBUI_PORT-3000} on the host and forwards it to port 8080 in the container, so another machine reaches it at the host's address on that port. The README does not document a separate remote-access mode, so treat it as a normal web service and secure it accordingly.

### How do I use web search in Open WebUI?

The README lists dozens of search providers for RAG, including SearXNG, Google PSE, Brave Search, Kagi, Tavily, Perplexity, Firecrawl and DuckDuckGo, and says results are injected directly into the conversation. Separately, the `#` command followed by a URL pulls a page into chat.

## Sources

- [Official documentation](https://openwebui.com)
- [Official README](https://github.com/open-webui/open-webui#readme)
- [Project repository](https://github.com/open-webui/open-webui)
- [Release notes](https://github.com/open-webui/open-webui/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/open-webui-open-webui