A proper chat interface for your local AI (Open WebUI + Ollama)

GOING FURTHER

Tested for real: I ran every command in this guide top-to-bottom on a fresh Ubuntu 24.04 virtual machine (4 CPUs, 8 GB RAM, no GPU) on 13 August 2026. Versions at test time: Open WebUI v0.11.0 (main image), Ollama 0.32.9, model llama3.2:3b, Docker Engine 29.7.2, on Ubuntu 24.04.4 LTS.

Found a problem? Tell me via the contact page.

What you'll end up with

The terminal chat from my Ollama guide is fine for you. It is useless for anyone else in your house. This guide puts a proper web chat — history, multiple conversations, a login — in front of your local model, reachable from any phone or laptop on your network.

$ curl -s http://localhost:8080/api/chat/completions ... "What can I use a local AI model for?"

A local AI model, also known as an edge AI model, can be used to perform
real-time computer vision and machine learning tasks on devices such as
smartphones, smart home devices, or IoT sensors...

That answer came from my own model, through Open WebUI, on the test machine. Nothing touched the cloud.

Who this is for

GOING FURTHER. You need two of my BASIC guides done first (listed below). There is one honest complication in the middle. The command most tutorials give you often fails with a local Ollama install on Linux, and I show you why with evidence.

A note on how I tested this

My test rig has no browser. Where you will click buttons in a web page, I drove the same actions through Open WebUI's own API and captured the real responses. The account created, the chat sent, the answer received — all of it happened for real and is in the transcripts. Where I describe a screen, that is what you will see; where I show output, that is what the machine said.

Time and cost

Machine time in my test was about 5 minutes, but 7 GB of downloads dominate. Allow 60 minutes end to end on decent broadband; more on a slow line. Cost: free. Disk: about 7.5 GB for the Open WebUI image and its data, on top of Ollama's 4 GB.

Words you'll meet

Volume — Docker-managed storage that survives when a container is removed. Your accounts and chat history live in one. See /basics.
Host network mode — running a container with no network wall between it and your machine. It shares your machine's addresses directly.
Port mapping — the normal alternative: Docker forwards one chosen port through the container's wall (-p 3000:8080).
Environment variable — a named setting handed to a program at start (-e NAME=value). It is how we tell Open WebUI where Ollama is.
127.0.0.1 / localhost — the address that means "this machine only". Ollama listens there, which is about to matter a great deal.

Placeholders

Anywhere you see CAPS-WITH-DASHES, swap in your own value. This guide uses one: YOUR-SERVER-IP — your machine's address on your own network, for example 192.168.1.50. Find it with ip -4 addr if you are not sure.

Before you start

Docker installed the official way — my Docker guide.
Ollama installed with the llama3.2:3b model pulled — my Ollama guide.
Your user in the docker group (the Docker guide's step 6), so no sudo needed below.
About 8 GB of free disk.

The steps

Step 1 — Check your starting point

Both prerequisites need to be alive before we stack anything on top. First Docker:

docker --version

Docker version 29.7.2, build a7dcaa6

Then the model:

ollama list

NAME           ID              SIZE      MODIFIED
llama3.2:3b    a80c4f17acd5    2.0 GB    2 minutes ago

And note where Ollama is listening — this line is the source of the trap in step 2:

ss -tln | grep 11434

LISTEN 0      4096       127.0.0.1:11434      0.0.0.0:*

The important part is 127.0.0.1:11434.

Check it worked. All three outputs present? Good. 127.0.0.1:11434 means Ollama only answers callers on this machine — which is the privacy feature we wanted, and the thing we now have to work around.

Step 2 — Start Open WebUI (the command that actually works on Linux)

Here is the trap, up front. Most tutorials give you a docker run with -p 3000:8080 --add-host=host.docker.internal:host-gateway. On Linux, with Ollama installed the normal way, that command starts a working web page that cannot see your model.

I ran it on the test machine to be sure. The page answered, but from inside the container, Ollama was unreachable — connection refused. The reason: a normal container lives behind its own network wall, and host.docker.internal points at your machine's bridge address. Ollama is only listening on 127.0.0.1, so nobody is home at the bridge.

Open WebUI's own documentation gives the Linux fix: run the container in host network mode. The container then shares your machine's network directly, and 127.0.0.1 means the same thing inside and out. That is what we do — this is one long command on one line:

docker run -d --network=host -v open-webui:/app/backend/data -e OLLAMA_BASE_URL=http://127.0.0.1:11434 --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Reading it left to right: run detached, share the host's network, keep data in a volume called open-webui, tell it Ollama is at 127.0.0.1:11434, name it, restart it with the machine, and use the official image.

One consequence to know now: with host networking the page is on port 8080, not 3000 — there is no port mapping to move it. In my test the 7.16 GB image downloaded and started in 1 minute 43 seconds.

Check it worked. The app takes a while to initialise on first run — about 45 seconds in my test. Then:

docker ps --filter name=open-webui

NAMES        STATUS                             PORTS
open-webui   Up 46 seconds (health: starting)

The important part is the Up status. The empty PORTS column is correct — host networking does not list mappings. Now ask the page itself:

curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8080

200 means the web page is answering.

Step 3 — Prove the container can see your model

Do not take my word for the networking story — test the exact link that the trap breaks. This runs one command inside the container, asking Ollama for its version:

docker exec open-webui curl -s http://127.0.0.1:11434/api/version

You should see something like:

{"version":"0.32.9"}

That is the container talking to Ollama on the host. When I ran the tutorial-default command instead, this same check died with connection refused. This one line is the difference between a chat interface and an empty model list.

Step 4 — Claim the admin account. Do it now, not later

Open a browser on any device on your network and go to:

http://YOUR-SERVER-IP:8080

You will see Open WebUI's welcome screen with a Sign up link. Create your account: name, email (it stays local — no verification email is sent), and a strong password.

Here is the part that deserves bold text: the first account created becomes the administrator. And because of host networking, this sign-up page is already reachable by everyone on your network.

I verified both facts on the test machine. The page answered from another machine before any account existed, and my first sign-up came back with the admin role:

{
  "name": "Tester",
  "role": "admin",
  "email": "[email protected]"
}

The important line is "role": "admin".

So do not start this guide, wander off for the weekend, and sign up on Monday. Start the container, then claim the account before leaving the container running.

Check it worked. You land in the chat interface, and the model picker at the top offers llama3.2:3b. On my test machine, the API listed exactly that:

['llama3.2:3b', 'arena-model']

(arena-model is a built-in comparison feature of Open WebUI, not one of your downloads.)

Step 5 — Have a real conversation

Pick llama3.2:3b in the model picker, type a question, and send it. The first reply pauses for a few seconds while the model loads into RAM, then streams in word by word — 15 seconds start to finish in my test, on 4 CPU cores.

Here is my real test exchange, sent through Open WebUI to the local model:

Asked: "What can I use a local AI model for? Answer in one sentence."

A local AI model, also known as an edge AI model, can be used to perform
real-time computer vision and machine learning tasks on devices such as
smartphones, smart home devices, or IoT sensors with limited connectivity
to the cloud.

Check it worked. The reply itself is the check. Conversations appear in the left sidebar. Open WebUI stores conversations in the local Docker volume; I did not test external telemetry.

Step 6 — See what the whole stack costs in memory

Two things are now using RAM: the Open WebUI container and the loaded model. Measure both. First the container:

docker stats --no-stream open-webui

NAME         MEM USAGE / LIMIT     CPU %
open-webui   866.3MiB / 7.755GiB   14.55%

Then the model:

ollama ps

NAME           ID              SIZE      PROCESSOR    CONTEXT    UNTIL
llama3.2:3b    a80c4f17acd5    2.6 GB    100% CPU     4096       4 minutes from now

And the machine's overall position:

free -h

               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       3.8Gi       249Mi       4.2Mi       4.0Gi       4.0Gi

The important figure is 3.8Gi in the used column.

Check it worked. Roughly: 0.9 GB for the interface, 2.6 GB for the loaded model, 3.8 GB used in total on my 8 GB machine. It fits, with headroom for the model's 5-minute idle unload to claw back the big chunk.

Step 7 — Understand exactly who can reach what

This is the honest security audit of what we built. Look at the open doors:

ss -tln | grep -E "8080|11434"

LISTEN 0      4096       127.0.0.1:11434      0.0.0.0:*
LISTEN 0      2048         0.0.0.0:8080       0.0.0.0:*

Read it plainly: Ollama (11434) still answers this machine only — the privacy promise from the Ollama guide holds. But Open WebUI (8080) answers on 0.0.0.0, which means every device on your network. I proved both from a second machine on the test network:

curl -s -o /dev/null -w "%{http_code}\n" http://YOUR-SERVER-IP:8080

curl -s --max-time 5 http://YOUR-SERVER-IP:11434/api/version

(nothing — connection refused)

Is the exposed page a problem? Your chats and the API are behind the login. An unauthenticated request to the API on my test machine got {"detail":"Not authenticated"}, exactly as it should.

But "reachable by the whole network" still means something. Anyone on your Wi-Fi can see the sign-up page, and until you claimed admin in step 4, they could have claimed it instead.

Two follow-ups are worth doing in the interface. In Admin Panel → Settings → General, turn off Enable New Sign Ups once your household's accounts exist. And treat this as a home-network service — do not port-forward it to the internet.

Check it worked. If you saw 200 from another device and Not authenticated without a login, your setup matches my tested one exactly.

Something went wrong?

You used a command from another tutorial and the model list is empty, though the page loads → it means Open WebUI is running behind Docker's network wall and cannot reach Ollama on 127.0.0.1 → run this guide's Undo, then start again from step 2 with the host-network command. Step 3 is the test that tells you it is fixed.
You see (health: starting) in docker ps and the page will not load yet → it means Open WebUI is still initialising, which took about 45 seconds on my machine → wait a minute and retry the curl; only worry if it is still not answering after five.
You see {"detail":"Not authenticated"} when poking the API with curl → it means the login is doing its job → the browser is the normal way in; API calls need the key from Settings → Account.
The first reply in a new conversation is slow, later ones are quick → it means the model was loading into RAM (Ollama unloads it after 5 idle minutes) → normal on CPU; 15 seconds in my test, then answers stream immediately.

Undo all of this

Tested for real on the same machine, straight after everything above. Three commands remove Open WebUI completely; Ollama and your models stay (the Ollama guide's own Undo covers those).

Stop and remove the container:

docker rm -f open-webui

Delete the data volume. This is the destructive one — every account and every saved chat goes with it.

docker volume rm open-webui

Remove the 7.16 GB image and get your disk back:

docker rmi ghcr.io/open-webui/open-webui:main

Check it worked.

docker ps -a

No open-webui row. And the door is closed:

curl -s --max-time 3 http://localhost:8080

(nothing — connection refused)

That refusal is the pass mark.

Where to go next

Want it reachable away from home without opening ports? That is exactly what Tailscale is for — your phone on 4G talking to your model at home, privately.
Official reference: docs.openwebui.com — the quick start plus the troubleshooting page on Ollama connection errors, which this guide's step 2 follows and verifies.

Last tested: 13 August 2026 on Ubuntu 24.04.4 (4 vCPU, 8 GB RAM, no GPU). Versions: Open WebUI v0.11.0, Ollama 0.32.9, llama3.2:3b, Docker Engine 29.7.2. Measured: 3.8 GB total RAM with model loaded; first reply 15 s.