Open WebUI

Last reviewed Aug 23, 2026 · 659 words

Open WebUI is the missing front half of local AI: point it at Ollama or any OpenAI-compatible endpoint and you get a private ChatGPT — accounts, chat history, document upload, model switching — that your whole household can use from a browser. One container, easy setup, and two facts worth knowing before you start: the first account to register becomes the admin, and the project ships features faster than almost anything else in self-hosting, which cuts both ways.

Wiring it to Ollama without the networking dance

If Ollama runs as a container in the same compose file, it's one environment variable:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "8080:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - ./open-webui:/app/backend/data
    restart: unless-stopped

If Ollama runs natively on the host (the better setup when a GPU is involved), the container needs a route back out: add --add-host=host.docker.internal:host-gateway (or the compose extra_hosts equivalent) and set OLLAMA_BASE_URL=http://host.docker.internal:11434. "No models found" on first load is almost always this wiring, not a broken install. Cloud fallback slots in beside local: add an OpenAI-compatible connection under Admin → Settings → Connections and both model lists appear in the same picker — the pattern the self-hosted AI stack is built around.

Claim admin first, then invite the household

Registration is open by default and the first signup gets admin — so create your account immediately after first start, then set new signups to require approval (or disable them) in the admin panel. From there the multi-user story is genuinely good: pending-approval workflow, user and admin roles, per-model access controls if you want the kids on the small fast model and not the 70B that monopolises the GPU. Everyone gets their own chat history, stored in the /app/backend/data volume — which, note, contains every conversation your family has had with it; back it up and treat it as private data per the local AI privacy audit.

RAG: useful, with honest expectations

Upload a PDF into a chat (or build a knowledge collection) and Open WebUI chunks, embeds, and retrieves from it automatically — "chat with your documents" with zero extra infrastructure. It works well for question-answering over manuals, contracts, and notes. Where expectations need calibrating: retrieval quality depends heavily on the underlying model and chunking defaults, and a 7B model reasoning over retrieved chunks is not a research assistant. Start with single-document questions, and if you outgrow the built-ins the embeddings-in-production notes explain what the next tier looks like. Web search can also be wired in (SearXNG among the supported engines — a natural pairing if you already run SearXNG).

Managing the feature firehose

Tools, functions, pipelines, voice, image generation hooks, evaluation arenas — the catalogue's one listed con is that the feature set can overwhelm, and it's fair. Two habits keep it sane. First, ignore everything until a concrete need shows up; the chat experience needs none of it. Second, pin your image version rather than riding :main, because weekly releases occasionally move settings around or change behaviour — the same update discipline as everything else, applied to a project moving faster than most. Updates preserve your data volume; the risk is churn, not loss.

What I'd do

Ollama native on the GPU box, Open WebUI in Docker beside it with the host-gateway wiring, admin claimed in the first five minutes, signups set to approval, one mid-size local model as the default plus a cloud connection for hard questions. Add RAG when a real document problem appears, not before. That configuration has survived in my house for a year with near-zero maintenance, which for a project this fast-moving is the strongest compliment available.