Open WebUI + Ollama Connection Guide

Open WebUI talks to Ollama out of the box: point Open WebUI at Ollama's API on http://host.docker.internal:11434 (Docker) or http://localhost:11434 (bare metal), and any model you've pulled shows up in the model dropdown automatically. The whole pairing takes one Docker command plus one environment variable, and 90% of "Open WebUI can't see my models" problems come down to a single networking mistake — Docker can't reach localhost on your host the way you'd expect. Below I'll wire it up both ways and fix the connection issues I actually hit.

This is a cluster guide under the Open WebUI local AI interface pillar — read that for the full tour of the UI itself. Here I'm only solving the connection.

What is the Open WebUI + Ollama pairing?

Open WebUI is a self-hosted, ChatGPT-style web interface; Ollama is a local model runner that serves open-weight models (Qwen, Llama, Gemma, DeepSeek, Mistral, Phi) over an HTTP API on port 11434. Open WebUI is the front end, Ollama is the engine — Open WebUI sends chat requests to Ollama's API and renders the streamed tokens in a browser your whole household can hit.

You need both because Ollama on its own only gives you a terminal prompt or a raw API. Open WebUI adds accounts, chat history, model switching, document upload (RAG), and a clean mobile-friendly URL — so the rest of the house gets a real app instead of a command line. If you haven't installed the runner yet, start with installing Ollama on Windows, Mac, or Linux, then come back.

Docker vs bare metal: which install should I pick?

Run both in Docker if you want isolation and a one-command teardown; run Ollama bare metal + Open WebUI in Docker if you want the best GPU performance on the model engine. Here's the trade-off:

Approach	GPU access	Setup effort	Best for
Open WebUI (Docker) → Ollama (bare metal)	Native, full speed	Low	Apple Silicon, most home setups
Both in Docker, separate containers	Needs GPU passthrough config	Medium	Linux + NVIDIA, tidy homelab
Bundled image (open-webui:ollama)	Needs GPU passthrough	Lowest	Quick demo, single machine
Both bare metal (no Docker)	Native	Medium	Minimal-overhead purists

Decision list:

• If you're on a Mac (Apple Silicon) → run Ollama as the native app and Open WebUI in Docker. Docker on macOS can't pass through the Apple GPU, so a containerized Ollama runs on CPU only. Native Ollama uses Metal and is dramatically faster.
• If you're on Linux with an NVIDIA GPU → either works; bare-metal Ollama is simplest, but a Docker Ollama with --gpus all is fine.
• If you just want to try it in five minutes → use the bundled image and move on.
• If you already have a homelab compose stack → fold both into it; see my homelab Docker stack for Ollama + Open WebUI.

How do I connect Open WebUI (Docker) to bare-metal Ollama?

This is the setup I run and recommend for most people. Install Ollama natively, pull a small model, then start Open WebUI in Docker pointed at the host.

# 1. With Ollama already installed and running, pull a small model
ollama pull qwen2.5:7b-instruct-q4_K_M

# 2. Start Open WebUI in Docker, pointing at host-side Ollama
docker run -d \
  --name open-webui \
  -p 3000:8080 \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --restart unless-stopped \
  ghcr.io/open-webui/open-webui:main

The two load-bearing lines: OLLAMA_BASE_URL tells Open WebUI where the engine lives, and --add-host=host.docker.internal:host-gateway makes that hostname resolve to your host machine from inside the container. On Docker Desktop (Mac/Windows) host.docker.internal works automatically; on Linux you need that --add-host flag or it won't resolve.

Open http://localhost:3000, create the first account (it becomes admin), and your pulled models should already be in the dropdown. The default q4_K_M quant is the sweet spot — if you're fuzzy on what that means, see Q4 vs Q8 quant quality trade-offs.

How do I run both Ollama and Open WebUI in Docker?

Use a compose file so the two containers share a network and Open WebUI can reach Ollama by service name. No localhost gymnastics needed — Docker's internal DNS resolves ollama to the right container.

# docker-compose.yml
services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    volumes:
      - ollama:/root/.ollama
    ports:
      - "11434:11434"
    restart: unless-stopped
    # NVIDIA only — drop this block on Mac/CPU:
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

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

volumes:
  ollama:
  open-webui:

docker compose up -d
# Pull a model into the containerized Ollama:
docker exec -it ollama ollama pull llama3.1:8b-instruct-q4_K_M

Note OLLAMA_BASE_URL=http://ollama:11434 — inside the compose network the hostname is the service name, not localhost or host.docker.internal. This is the single most common mix-up. Reminder for Mac users: a containerized Ollama here runs on CPU. If tokens crawl, switch to the bare-metal pairing above.

Why can't Open WebUI see my Ollama models?

Nine times out of ten it's a networking address problem, not a broken install. Open WebUI is reaching the wrong place for the Ollama API. Quick diagnosis:

• localhost inside Docker points at the container, not your host. If you set OLLAMA_BASE_URL=http://localhost:11434 inside a container, Open WebUI looks for Ollama inside its own container and finds nothing. Use host.docker.internal (bare-metal Ollama) or the service name (compose).
• Ollama is only listening on loopback. By default Ollama binds 127.0.0.1, which refuses connections from other containers. Set OLLAMA_HOST=0.0.0.0 so it accepts LAN/container traffic:

# macOS native app
launchctl setenv OLLAMA_HOST "0.0.0.0:11434"
# then quit and reopen Ollama

# Linux systemd service
sudo systemctl edit ollama
# add under [Service]:
#   Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl restart ollama

• The --add-host flag is missing on Linux. Without it host.docker.internal doesn't resolve. Add --add-host=host.docker.internal:host-gateway.
• A firewall is blocking 11434. Confirm the port is reachable.

Verify the API directly before blaming Open WebUI:

# Should return JSON listing your pulled models
curl http://localhost:11434/api/tags

# From inside the Open WebUI container, prove it can reach Ollama:
docker exec -it open-webui curl http://host.docker.internal:11434/api/tags

If the first curl works but the second fails, it's networking — fix the host/binding. If the first curl fails too, Ollama itself isn't running or has no models. You can also set or correct the URL live in the UI under Admin Settings → Connections → Ollama API, then hit the refresh icon to re-scan.

Can I connect Open WebUI to other runners too?

Yes. Open WebUI speaks both Ollama's native API and the OpenAI-compatible API, so anything that exposes an OpenAI-style /v1 endpoint — llama.cpp's server, LM Studio, vLLM — slots in alongside Ollama. Add it under Admin Settings → Connections → OpenAI API with the base URL and a dummy key.

# llama.cpp server (llama-server) running on the host:
Base URL:  http://host.docker.internal:8080/v1
API Key:   sk-no-key-required

This is handy when you want one model on Ollama and another served by llama.cpp for a specific quant or feature. For the broader picture on that compatibility layer, see Ollama's OpenAI-compatible API, and if you're weighing the tools themselves, LM Studio vs Ollama vs llama.cpp.

Bottom line

For most home setups, run Ollama natively and Open WebUI in Docker with OLLAMA_BASE_URL=http://host.docker.internal:11434 plus --add-host=host.docker.internal:host-gateway. Going all-Docker? Use compose and point Open WebUI at the ollama service name. When models don't appear, it's almost always an address problem — curl /api/tags from inside the container to find out where the request is actually landing, and set OLLAMA_HOST=0.0.0.0 so Ollama accepts the connection. Get those right and you've got a household-grade chat app over your own open-weight models, with nothing leaving the LAN. Next stop: the full Open WebUI interface pillar.