Open WebUI on Linux Docker: what actually happens in the first 90 seconds

The exact docker run we used

docker run -d \
  --name owui-test \
  -p 18080:8080 \
  -v owui-data:/app/backend/data \
  -e WEBUI_AUTH=true \
  ghcr.io/open-webui/open-webui:main

That's it. No --add-host, no --network=host, no Ollama, nothing else. We wanted to know what the README's "just run it" claim actually buys you.

What boot looked like, second by second

Container ID printed at 13:03:38. The first useful log line — INFO: Started server process [1] — appeared at 13:04:00. The first HTTP 200 on GET / came in at 13:04:14. So:

The 36 s number is on a 32 GB Hetzner CX-line VPS with the image pre-pulled. If you let docker run do the pull, add another 90 s on a 1 Gbit link for the first time. The image is ~3 GB compressed.

The 1.1 GB disk usage on first idle boot is the part most people miss when they pick a 10 GB VPS — Open WebUI ships a sentence-transformer model for retrieval-augmented chat. You don't get to opt out; it downloads on first run unless you bind-mount a pre-warmed cache.

The first user is admin. Quietly.

This is the line in the source that decides it: in backend/open_webui/routers/auths.py, the signup handler checks Users.get_num_users() == 0 and, if true, sets role="admin" for the new account. There's no UI prompt explaining this. We wrote a POST /api/v1/auths/signup with the first email we picked and got "role": "admin" back in the JSON response.

The takeaway: if you expose port 18080 to the internet for "just five minutes while I show a colleague," whoever hits the page first owns your instance. Bind to 127.0.0.1 behind a reverse proxy, or front it with HTTP basic-auth on the very first day, not the second.

The default Ollama URL doesn't resolve on Linux

Here's the config Open WebUI ships with, fetched from a real signed-in admin token against GET /ollama/config:

{
  "ENABLE_OLLAMA_API": true,
  "OLLAMA_BASE_URLS": ["http://host.docker.internal:11434"],
  "OLLAMA_API_CONFIGS": {}
}

$ docker exec owui-test getent hosts host.docker.internal
(no output — exit 2: not resolvable)

And the worse part: Open WebUI does not surface this as an error. Hitting the proxied tags endpoint returns an empty model list, not a connection-refused or DNS-resolution error:

$ curl -H "Authorization: Bearer $TOKEN" http://localhost:18080/ollama/api/tags
{"models":[]}

So you sign up, you sign in, you click the model picker, the dropdown is empty, you go check the docs, the docs say "Ollama discovery is automatic" — and you're stuck wondering whether it's your firewall, your Ollama install, or some local DNS quirk. None of those. It's a Mac/Windows-shaped default in a Linux-shaped container.

Verifying the bridge-gateway route from inside the container:

$ docker exec owui-test sh -c "timeout 2 nc -zv 172.17.0.1 11434"
nc: connect to 172.17.0.1 port 11434 (tcp) failed: Connection refused

"Connection refused" here is the answer we wanted — it confirms routing works; we got a TCP RST from the host because we hadn't started Ollama yet. With Ollama running on the host, the same command would succeed.

Things we noticed that the docs don't lead with

• The /api/v1/configs/* path is wrong. The Swagger UI implies a clean /api/v1/configs/{provider} shape, but in 0.9.2 the working endpoints are /openai/config, /ollama/config, /openai/config/update, /ollama/config/update — under the provider prefix, not the versioned API root. If your client calls /api/v1/configs/ollama, you get the SPA's index.html back instead of JSON. We wasted six minutes on this before grepping the source.
• Embedding model lives in the data volume. Wipe owui-data and the next boot re-downloads the 80 MB compressed weights from Hugging Face. This matters in CI: pin the volume across runs or you'll get rate-limited eventually.
• WEBUI_AUTH=false is a footgun, not a feature. It removes the sign-in screen entirely — every page shows the chat UI to anyone who can reach the port. We left ours at true; if you flip it off "for testing," remember the port-exposure note above applies tenfold.
• Cold-start > 30 s breaks naive healthchecks. Compose's healthcheck: default is 30 s before the first probe. Either set start_period: 60s, or your orchestrator will keep restarting the container during the embedding download.

What we'd do differently next time

1. Pre-bake the embedding model into the image (FROM open-webui:main, then RUN python -c "from sentence_transformers import SentenceTransformer; SentenceTransformer('all-MiniLM-L6-v2')"). Cuts cold-start by ~14 s and avoids first-run network egress.
2. Drop --add-host=host.docker.internal:host-gateway into the docker run as a habit — even when we don't use Ollama, it costs nothing and stops surprising future-us.
3. Front it with nginx + basic auth on day one. The "first user is admin" rule is fine for a personal box; on anything reachable from the public internet, treat it like a freshly-installed WordPress and assume bots will find it inside an hour.
4. Bind the data volume to a path you back up — /var/lib/owui-data rather than a Docker-managed volume. We've already lost a sandbox install once because we docker volume pruned after a Friday cleanup.

Where this article fits

This is one of a small set of self-host write-ups we publish: how a thing actually behaves on a real Linux box, with timings, the one default that breaks, and the one-line fix. Adjacent pieces: Discourse self-hoster's handbook (forum software), WordPress emergency repair (when the dashboard is gone). If you want SimpleReview to draft code fixes on whichever app you click — including a broken Open WebUI plugin or admin form — that's at onout.org.

Demo: SimpleReview on an Open WebUI admin error

localhost:18080/admin/settings/connections

Open WebUI · Admin Panel

ConnectionsModelsDocumentsPipelines

Ollama API ⚠ no models found

⚠ Ollama discovery returns 0 models

OLLAMA_BASE_URLS = http://host.docker.internal:11434

getent hosts host.docker.internal → exit 2 (not resolvable on Linux Docker). GET /ollama/api/tags returns {"models":[]} silently.

Open WebUI · Admin Panel

✓ Ollama reachable · 3 models discovered

OLLAMA_BASE_URLS = http://172.17.0.1:11434

llama3:8b mistral:7b qwen2.5:14b

Comment×

host.docker.internal not resolving|

Fix it ⟳ ✓ Done

SimpleReview PRO

waiting for selection…

Detected

Hostunresolvable

Platformlinux/docker

Fix plan

Replace host.docker.internal with the docker0 bridge gateway 172.17.0.1

Result

Ollama reachable. Models discovered. No --add-host needed.

✓ Fix ready

fix(env): use docker0 bridge for OLLAMA_BASE_URLS
1 line · docker-compose.yml

Click SimpleReview → select the broken Ollama URL → Fix it → docker0 bridge wired in