Open WebUI: A Private ChatGPT Front End for Your Own Models

Ollama gave me a local language model in about five minutes, and then I spent three weeks barely using it. The problem was the interface: ollama run mistral drops you into a terminal REPL with no history, no way to switch models mid-thought, no document upload, and nothing to hand a curious housemate who has used ChatGPT and expects a text box in a browser. The model was excellent and the front door was a cave. Open WebUI is the front door — a self-hosted web application that gives your local models the interface people already know, while keeping every conversation on hardware you own.

If you’ve used the popular hosted chat assistants, the layout will be instantly familiar: a sidebar of past conversations, a model picker at the top, a message box at the bottom, and streaming replies. The difference sits underneath. There’s no account with a third party, no monthly bill, no conversation logged on someone else’s server, and no model you don’t control. It talks to Ollama on your network, and when you point it at a document or a codebase, that content is processed by software that has no route to the internet unless you give it one.

A note on the name, because it confused me too: the project was called Ollama WebUI until early 2024, then renamed Open WebUI to reflect that it now speaks to any OpenAI-compatible backend alongside Ollama. If you find older tutorials under the previous name, they describe the same tool.

Why a front end matters more than it sounds

The instinct is to treat the interface as decoration on top of the real work, which the model does. In practice the interface decides whether the model gets used at all. A REPL is fine for a quick one-shot question and hopeless for the things a chat assistant is actually good at: a long back-and-forth where earlier answers inform later ones, comparing how two models handle the same prompt, or dropping in a PDF and asking about it. Every one of those needs persistent state and a real UI, and without them a perfectly capable local model sits idle while you reach for the hosted one out of sheer convenience.

There’s a household dimension too. My local model is far more useful when the people I live with can reach it. A browser tab they can bookmark, with a login and their own conversation history, turns a personal experiment into a shared utility — the family asks it to draft emails and explain error messages, and none of those questions leave the house. You cannot get that from a command line, and the convenience gap is exactly what pushes people back onto services that harvest their data.

The last reason is that Open WebUI quietly adds capability the raw model runner lacks. Document chat, prompt presets, per-user model access, and an admin panel are all things you’d otherwise script yourself. Getting them from one container is a good trade for a homelab where time is the scarce resource.

Standing it up

Open WebUI and Ollama are two containers that need to find each other. The cleanest arrangement puts them on the same compose network so Open WebUI can reach Ollama by service name:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

services:
  ollama:
    image: ollama/ollama:latest
    volumes:
      - ./ollama:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    restart: unless-stopped

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

The critical line is OLLAMA_BASE_URL=http://ollama:11434. It tells Open WebUI where the model runner lives, and ollama here is the compose service name resolving on the internal network. This is the single most common thing people get wrong, usually by leaving it pointing at localhost, which inside the Open WebUI container means the container itself and not the Ollama one.

Bring it up and pull a model into Ollama so there’s something to talk to:

1
2
3

docker compose up -d
docker compose exec ollama ollama pull mistral
docker compose exec ollama ollama pull llama3.1:8b

Open http://mylab.local:3000 and the first thing it asks for is an account. The very first account you create becomes the administrator — this catches people out, because there’s no prompt telling you it’s special. Guard those credentials; the admin can manage users, restrict which models each person sees, and change server settings. Everyone who signs up after that is a regular user pending your approval.

The WEBUI_AUTH=true setting is doing real work. Turn authentication off and anyone who can reach the port gets an unauthenticated chat interface into your models, which is fine on a laptop and reckless on a machine other devices can see. Leave it on.

Making it reachable without exposing it

The stack above listens on a LAN port, which is right for a start. Once the household is using it, you’ll want a proper hostname and TLS rather than an IP and a port number, and you’ll want it reachable from a phone without opening a hole in your firewall.

The sane pattern is a reverse proxy in front of Open WebUI terminating TLS, so people reach https://chat.mylab.local on your internal network. Because Open WebUI streams responses over long-lived connections, the proxy has to allow WebSocket upgrades or replies will hang half-rendered — Caddy handles this automatically, and with nginx you add the Upgrade and Connection headers by hand. For access away from home, route through a VPN or a private tunnel back to the proxy rather than publishing the service to the open internet; a chat interface into your own models is precisely the sort of thing that should stay behind the front door.

The features that make it worth running

Model switching mid-conversation. The dropdown at the top swaps models on the fly, so you can ask a coding question of one model, decide the answer’s thin, and re-ask a larger one without losing the thread. It surfaces whatever you’ve pulled into Ollama, so ollama pull and a page refresh is all it takes to add a model to the menu.

Document chat. Upload a PDF or paste a URL and ask questions about it, and Open WebUI does a lightweight retrieval pass — chunking the document, embedding it, and feeding the relevant parts to the model. It’s a browser-native taste of retrieval-augmented generation with nothing to configure. For a serious document workflow you’ll outgrow it, but as a way to interrogate a single report without building a pipeline, it’s excellent.

Prompt presets. Save a system prompt as a reusable model — “reply in British English, be terse, show your working” — and pick it like any other model. It removes the tax of re-typing the same framing every session.

Multi-user with real controls. The admin panel lets you approve accounts, group users, and decide which models each group can use. That’s what makes it safe to hand out to a household rather than keeping it to yourself.

Troubleshooting: the things that actually go wrong

Open WebUI loads but the model list is empty. Almost always the OLLAMA_BASE_URL. From inside the Open WebUI container, curl http://ollama:11434/api/tags should list your models; if it can’t reach Ollama, the two containers aren’t on the same network or the URL is wrong. Fix the base URL before touching anything else — an empty model list is a connection problem nine times out of ten.

Replies hang or never stream in. Your reverse proxy is blocking the WebSocket upgrade or buffering the response. Confirm the proxy passes Upgrade/Connection headers and disables response buffering for the Open WebUI route. Hitting the raw :3000 port directly, which bypasses the proxy, is the fastest way to prove the proxy is the culprit.

The model responds but painfully slowly. Ollama fell back to CPU. Check nvidia-smi on the host during a reply — if VRAM is idle, the GPU isn’t wired into the Ollama container, and the fix is the deploy.resources block in the compose file plus the NVIDIA container toolkit installed on the host. Open WebUI itself needs no GPU; all the compute is Ollama’s.

You can’t log in and there’s no obvious reset. If you’ve lost the admin account, the user data lives in the volume you mounted at /app/backend/data as a SQLite database. Reset a password by editing that database directly, or in a throwaway setup, delete the volume to start the account flow again — which of course wipes conversation history, so treat it as a last resort.

An update breaks something. Open WebUI moves fast and the :main tag tracks the bleeding edge. Pin a specific version tag for a stable household service, and back up the data volume before pulling a new image so a bad release is a one-command rollback rather than a lost evening.

Document upload does nothing useful. The built-in retrieval uses an embedding model, and if it’s misconfigured or the document is scanned images with no text layer, you get vague answers. Check the admin document settings, and remember that a PDF of photographed pages has no extractable text until it’s been through OCR.

Where it fits with the rest of a local-AI stack

Open WebUI is the interface layer, so nearly every other offline-AI project plugs into it. The document-chat feature is a gentle on-ramp to retrieval-augmented generation; when you want more control than the browser gives, a local RAG stack for chatting with your own documents builds the real pipeline behind the same idea. The embeddings that power both the document feature and any self-hosted search box are worth understanding in their own right — running embeddings locally for self-hosted search covers what’s happening under that upload button. Point all of it at the one Ollama instance and you have a single private front end over your whole local-AI setup.

Is it worth it, and who for

Run Open WebUI if you already have Ollama and you’re only occasionally using it because the terminal is a chore, or if you want to share a local model with people who expect a browser and a login. It’s a small stack, it adds document chat and multi-user access for free, and it’s the thing that turned my local model from a novelty into something the household reaches for daily.

Skip it if you’re a solo user who genuinely lives on the command line and wants nothing more than a quick prompt — the REPL is lighter and you’ll never miss the UI. And be realistic that it’s a front end, so the quality of every answer is still down to the model and hardware behind it; a slick interface over a tiny model on a CPU is still a tiny model on a CPU.

For me it was the piece that made local AI stick. The models were always good; Open WebUI gave them a door the whole house could walk through, with every conversation staying on a machine I own and can unplug at will.