.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Ollama's terminal chat is fine for testing a model and terrible for daily use. Open WebUI puts a proper interface in front of it: a ChatGPT-style chat window that runs in your browser and talks to your own models. This guide covers the three ways to install it and connects it to Ollama running locally, in Docker or on a remote server. It ends with the update routine and the connection errors you'll hit first.
What Open WebUI adds over the Ollama CLI
Four things justify the extra container. User accounts with roles, so a team or family shares one server without sharing one history. Persistent, searchable chat history across devices. Document uploads with built-in RAG, meaning you drop a PDF into the chat and ask questions against it. And a model switcher that makes comparing answers from, say, qwen3 and llama3.1 a two-click job instead of two terminals. There's plenty more in the Open WebUI repository (tools, functions, image generation hooks), but those four are why it became the default Ollama frontend.
Pick an install route
You have three options and I have a clear favorite. Separate Docker containers, Open WebUI in one and Ollama native or in its own, is what I run and recommend, because each part updates on its own schedule and a UI bug never takes down your API. The bundled :ollama image ships both in a single container, which means one command and one thing to manage, fine for a first look on a fresh machine. And the pip route covers people who'd rather not run Docker at all; it works, with Python version caveats below.
Prefer skipping the setup altogether? The LumaDock Ollama VPS template deploys exactly this pair, Ollama plus Open WebUI, preconfigured in one click.
Route 1: Docker with a separate Ollama
Ollama should already be running; if not, our Ollama install guide for Ubuntu gets it up in five minutes. Then start Open WebUI:
docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway \
-e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
-v open-webui:/app/backend/data --name open-webui --restart always \
ghcr.io/open-webui/open-webui:mainThe two middle flags handle the awkward part: a containerized Open WebUI can't reach the host's localhost, because localhost inside a container is the container. --add-host=host.docker.internal:host-gateway maps a hostname to the Docker host and OLLAMA_BASE_URL points the UI at it. Leave those out on Linux and you get an empty model list, which is the single most reported Open WebUI problem.
The UI listens on host port 3000 (container port 8080 internally), the open-webui volume keeps accounts and chats across restarts and --restart always brings it back after reboots. If Ollama also runs in Docker, skip the add-host flag, put both containers on one network and set OLLAMA_BASE_URL=http://ollama:11434; the compose file in our Ollama Docker guide wires this up properly.
Route 2: The bundled image
One container with both applications inside:
docker run -d -p 3000:8080 -v ollama:/root/.ollama -v open-webui:/app/backend/data \
--name open-webui --restart always ghcr.io/open-webui/open-webui:ollamaNote the two volumes, one for models and one for UI data. Add --gpus=all if the NVIDIA Container Toolkit is set up on the host. There's also a :cuda tag of the standalone image, which accelerates Open WebUI's own features like local Whisper transcription and embeddings, separate from Ollama's GPU use. The bundle is genuinely convenient, and I still move people off it once they're serious: updating means pulling a whole new image with both apps, and Ollama releases far more often than the UI.
Route 3: Install with pip
Open WebUI supports Python 3.11 and 3.12, nothing newer, and the project recommends 3.11. On Ubuntu 24.04 (which ships 3.12), a virtual environment keeps things tidy:
python3 -m venv ~/open-webui-env
source ~/open-webui-env/bin/activate
pip install open-webui
open-webui serveThe UI comes up on port 8080 and finds a local Ollama on 11434 automatically, no container networking to fight with. The install pulls a lot of dependencies, so give it a few minutes. Downsides: you own the Python environment, and you'll want a systemd unit to keep open-webui serve running after logout. The Open WebUI quick start documents this route and the Docker ones side by side.
First login and the admin account
Open http://localhost:3000 (or your server's address, or port 8080 for pip) and click Sign up. The first account created becomes the administrator automatically, so create yours before handing the URL to anyone else. On a server that's reachable by others, do it immediately; an unclaimed admin seat on an exposed UI is a gift to whoever finds it first. Admins manage users, control which models are visible and set defaults from the Admin Panel.
Serving the UI to the internet deserves the same care as any service with a login page. Put Nginx or Caddy with HTTPS in front of port 3000 before you share the URL beyond your own network, since credentials shouldn't cross the internet unencrypted. On a LAN or over a VPN, plain HTTP to the port is fine.
Connect to Ollama on a remote server
The UI on your laptop can drive a much larger Ollama server elsewhere, which is how most teams end up running it. Point the container at the server's address:
docker run -d -p 3000:8080 -e OLLAMA_BASE_URL=http://YOUR_SERVER_IP:11434 \
-v open-webui:/app/backend/data --name open-webui --restart always \
ghcr.io/open-webui/open-webui:mainYou can also change this later under Admin Panel, then Settings, then Connections. Two requirements on the server side. Ollama binds to localhost by default, so the remote machine must set OLLAMA_HOST=0.0.0.0:11434 before it accepts outside connections. And since Ollama has no authentication of its own, that port needs a firewall rule, reverse proxy or VPN in front of it before it's exposed. Both steps, done safely, are the subject of our Ollama VPS hosting guide. In practice the cleaner pattern is running Open WebUI on the same server as Ollama and exposing only the UI, which brings its own login screen.
Pull models from the UI or the CLI
Admin Panel, Settings, Models lets you type a tag like llama3.2:3b and download it with a progress bar, handy when the person adding models never touches a terminal. I still pull over the CLI (ollama pull or docker exec -it ollama ollama pull) because the terminal shows download speed and resumes cleanly. Both land in the same store, and every model appears in the UI's model dropdown either way. Tag names come from the Ollama library; our best Ollama models roundup is a decent shortlist if the library feels endless.
Update Open WebUI and Ollama
The components update independently, which is the point of keeping them separate. For the UI container:
docker pull ghcr.io/open-webui/open-webui:main
docker stop open-webui
docker rm open-webuiThen rerun your original docker run command; accounts and chats live in the volume and survive. For pip, pip install -U open-webui inside the venv does it. Ollama updates by rerunning its install script (native) or pulling its image (Docker). I update the UI monthly and Ollama whenever a model I want needs a newer runtime.
Fix Server Connection Error and an empty model list
The classic failure: the UI loads but shows no models, or a red Server Connection Error banner. Work through these in order. First, confirm Ollama itself answers: curl http://127.0.0.1:11434 on the machine running it should return Ollama is running. Second, check OLLAMA_BASE_URL for the localhost trap described above; from inside a container, localhost is never the host. Third, for remote setups, test the URL from where the UI runs, since a firewall that drops 11434 produces exactly this symptom. docker logs open-webui usually names the failing URL outright. If none of that lands, the longer list of causes and fixes lives in our Ollama troubleshooting guide.
