Open WebUI Can't Connect to Ollama in Docker: The Fixes

You start Open WebUI, open the model picker, and it's empty. Or the admin connection check fails. Ollama is clearly running, because curl localhost:11434 on the server answers Ollama is running. So why can't Open WebUI see it?

Almost always, Open WebUI is trying to reach Ollama at an address that doesn't lead to Ollama from inside its container. This guide gives you the URL that works for each common setup, a quick test you can run from inside the container, and the saved-settings trap that makes a correct fix look like it did nothing.

Lots of people run this pair. On October 14, 2026, the Open WebUI repository had about 155,600 GitHub stars, and the ollama/ollama image had been pulled more than 186 million times from Docker Hub.

One warning before you start. Open WebUI's roles documentation says: "The very first account created on a fresh installation is automatically assigned the Admin role." If port 3000 is reachable from the internet before you sign up, a stranger can create that account and take over the instance. Docker-published ports also skip UFW, according to Docker's firewall docs. So every example below binds the UI to 127.0.0.1:3000. Reach it through a reverse proxy such as Nginx Proxy Manager or an SSH tunnel (ssh -L 3000:127.0.0.1:3000 you@server), and create your admin account right away.

Short version:

• Inside the Open WebUI container, localhost is the container itself, so http://localhost:11434 never reaches Ollama.
• Use http://ollama:11434 when both run in one Compose file. With Ollama on a Linux host, use http://host.docker.internal:11434 plus an extra_hosts entry host.docker.internal:host-gateway, and make Ollama listen on more than 127.0.0.1.
• Test from inside the container, for example docker exec open-webui curl -s http://ollama:11434. You want Ollama is running.
• Changed OLLAMA_BASE_URL and nothing happened? Open WebUI saved the first value in its database. Change it under Admin Panel > Settings > Connections.

The right Ollama URL for your setup

Quick answer

If you changed OLLAMA_BASE_URL and nothing happened, skip to the section on saved settings.

Why localhost fails inside a container

Each container has its own network namespace. Inside the Open WebUI container, localhost and 127.0.0.1 mean the Open WebUI container itself, not your server. Nothing in that container listens on 11434, so the connection is refused.

The problem reproduces with OLLAMA_BASE_URL=http://localhost:11434 and Ollama running in a separate container. The model list came back as {"models":[]}, with no error in the UI. The Open WebUI log had the real message:

ERROR | open_webui.routers.ollama:send_get_request:88 - Connection error: Cannot connect to host localhost:11434 ssl:default [Connect call failed ('127.0.0.1', 11434)]

In the browser, the model picker just said "No models available":

The connection check in the admin settings did show a problem. Clicking the verify button in the Edit Connection dialog for http://localhost:11434 gave a red "Ollama: Network Problem" message:

Check your own log first:

docker logs open-webui 2>&1 | grep -i "ollama\|11434" | tail

Test the connection from inside the container

Run curl where Open WebUI runs

Don't test from your laptop or the host shell. Test from where Open WebUI actually runs. The official image includes curl:

docker exec open-webui curl -s http://ollama:11434
docker exec open-webui curl -s http://host.docker.internal:11434/api/version

You want Ollama is running for the first and something like {"version":"0.40.4"} for the second. Once it works, you can keep an eye on it with an HTTP monitor in Uptime Kuma pointed at the same URL, from a container that has the same network access. Replace open-webui with your container name. docker ps shows it, and Compose names look like myproject-open-webui-1.

This is the same test from the lab, first in a container set to localhost, then in one set to the service name:

What the curl errors mean

• curl: (7) Failed to connect ... Couldn't connect to server: the name resolved, but nothing accepted the connection on that IP and port. Ollama is probably listening on 127.0.0.1 only (see the next section).
• Could not resolve host: the name doesn't exist inside the container. On Linux, host.docker.internal needs extra_hosts. A Compose service name only resolves inside the same Compose network.
• A hang until timeout: something is dropping packets, usually a firewall.

Ollama installed on the host

This is the setup where you ran Ollama's install script on the server, so Ollama runs as a systemd service, and Open WebUI runs in Docker. It needs two fixes, and most people only make the first.

Add host.docker.internal on Linux

On Docker Desktop (Mac and Windows), host.docker.internal works out of the box. On Linux it doesn't exist unless you add it. Docker's special host-gateway value maps it to the host's address on the default bridge network. On the test box that was 172.17.0.1.

That's why Open WebUI's own quick-start command includes --add-host. Here it is with the port bound to localhost. The docs use -p 3000:8080, which listens on every interface.

openssl rand -hex 32 > ~/.open-webui-secret && chmod 600 ~/.open-webui-secret
docker run -d -p 127.0.0.1:3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  -e WEBUI_SECRET_KEY="$(cat ~/.open-webui-secret)" \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:v0.12.0

Or in Compose:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:v0.12.0
    ports:
      - "127.0.0.1:3000:8080"
    volumes:
      - open-webui:/app/backend/data
    extra_hosts:
      - host.docker.internal:host-gateway
    environment:
      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY}
      # - OLLAMA_BASE_URL=http://host.docker.internal:11434  # this is already the image's default
    restart: unless-stopped

volumes:
  open-webui:

Open WebUI's environment variable reference lists http://host.docker.internal:11434 as the Docker default for OLLAMA_BASE_URL. So for this setup, extra_hosts is often the only thing missing from the compose file.

Put the secret in a .env file next to compose.yaml instead of typing it into the file. Compose reads .env automatically:

echo "WEBUI_SECRET_KEY=$(openssl rand -hex 32)" > .env
chmod 600 .env

Why bother with a fixed key? Without one, Open WebUI generates a key file inside the container. The same reference says that when the container is recreated and that file isn't in a persisted volume, a new key is generated. Every user gets logged out, OAuth sessions stop working, MCP tools fail to decrypt their tokens, and Open WebUI refuses to start if MFA is on (unless MFA_ENCRYPTION_KEY is set).

Run either key-generating line once. Running it again overwrites the key with a new one, and a new key has exactly those effects: everyone is logged out.

Make Ollama listen on more than 127.0.0.1

This one catches nearly everyone with Ollama on the host. Ollama's FAQ puts it plainly: "Ollama binds 127.0.0.1 port 11434 by default." That's loopback only. A request from a container arrives on the Docker bridge address (172.17.0.1), not on loopback, so Ollama never sees it. The Open WebUI connection guide names the same cause first.

To reproduce this, Ollama ran Ollama on the host network bound to 127.0.0.1:11434. From a container with host-gateway set:

$ getent hosts host.docker.internal
172.17.0.1      host.docker.internal
$ curl http://host.docker.internal:11434
curl: (7) Failed to connect to host.docker.internal port 11434 after 0 ms: Couldn't connect to server

The name resolves correctly, but the connection is refused. Meanwhile curl localhost:11434 on the host works fine, which is why this is so confusing.

The fix is to make Ollama listen on more than loopback. For the Linux systemd install, the FAQ's method is:

sudo systemctl edit ollama.service

Add:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

Then:

sudo systemctl daemon-reload
sudo systemctl restart ollama
ss -ltn | grep 11434     # should now show *:11434 or 0.0.0.0:11434, not 127.0.0.1:11434

After that change, the same curl from the container returned Ollama is running.

Be careful with 0.0.0.0. It means every interface, including your public one, and Ollama's API has no authentication. On a VPS, block 11434 from the internet in your cloud firewall. Or bind Ollama to the Docker bridge address only:

[Service]
Environment="OLLAMA_HOST=172.17.0.1:11434"

That was tested too. Containers on the default bridge and on a Compose network could both reach it through host.docker.internal, and nothing outside the host could. The catch is that localhost:11434 on the host stops working, so the ollama CLI needs OLLAMA_HOST=172.17.0.1:11434 set in your shell as well.

172.17.0.1 belongs to Docker's docker0 bridge, so it only exists while Docker is running. To have systemd start Ollama after Docker at boot, also put After=docker.service under a [Unit] section in the same override.

UFW can also get in the way here. Traffic from a container to 172.17.0.1:11434 is addressed to the host itself, not to a published container port, so UFW's normal input rules apply to it. If your UFW default is deny incoming and requests from the container hang, a rule that allows only Docker's subnets to that port looks like this:

sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp

172.16.0.0/12 covers 172.16.0.0 to 172.31.255.255, where all of the test box's Docker networks were (172.17.0.0/16 and 172.27.0.0/16, for example). Yours may differ, so check the subnets you actually have with docker network inspect bridge <your-compose-network> --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}' and adjust the rule.

There's also a shortcut. Open WebUI's connection guide suggests running the container with --network=host, which puts it directly on the host's network. 127.0.0.1 then points at the host, so a loopback-bound Ollama works without changes:

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:v0.12.0

With host networking, -p mappings don't apply, and the UI is on port 8080, not 3000. It's a fine shortcut on a single-purpose box, but you give up network isolation, and the app listens on all host interfaces.

Ollama in the same Compose file or on another machine

One Compose file for both

This is the cleanest setup. Containers in the same Compose project share a user-defined network, and Docker resolves service names on those networks. So Open WebUI reaches Ollama at http://ollama:11434. You don't need host.docker.internal, and you don't need to publish Ollama's port to the host.

This is the tested file. The test run published "3000:8080", and the localhost binding shown here is the only change.

services:
  ollama:
    image: ollama/ollama:0.40.4
    restart: unless-stopped
    volumes:
      - ollama:/root/.ollama
    # no "ports:" needed, only Open WebUI talks to it

  open-webui:
    image: ghcr.io/open-webui/open-webui:v0.12.0
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY}   # from .env, see above
    volumes:
      - open-webui:/app/backend/data
    depends_on:
      - ollama

volumes:
  ollama:
  open-webui:

docker compose up -d
docker compose exec ollama ollama pull llama3.2   # or any model from Ollama's library that fits your RAM
docker compose exec open-webui curl -s http://ollama:11434

You don't need to change OLLAMA_HOST here. The official ollama/ollama image already sets OLLAMA_HOST=0.0.0.0:11434 (docker image inspect ollama/ollama shows it), so Ollama listens on the container network.

The test box couldn't download from Ollama's model registry, so a small model was loaded (SmolLM2-135M-Instruct) from a GGUF file with ollama create instead of ollama pull. Open WebUI listed it once pointed at http://ollama:11434, and a chat completion through Open WebUI's API worked on CPU.

With http://ollama:11434 set, the connection check in the admin settings passed:

Two things break this setup:

• Two separate Compose projects. If Ollama and Open WebUI live in different folders and files, they're on different networks, and ollama won't resolve. Put both services in one file, or attach both to a shared external network (docker network create ai, then declare it as external: true in both files).
• The wrong service name. The hostname is the service key under services: (ollama above), not the image name. If you set container_name, that name resolves too.

Don't publish Ollama's port unless you need it. Docker's firewall docs explain that traffic to published container ports is routed in the NAT table before UFW's rules apply. So with -p 11434:11434, Ollama is reachable from the internet even if ufw status says otherwise. If you need it on the host, publish it to loopback only: 127.0.0.1:11434:11434.

Ollama on another machine

Treat it like the host setup, but over the LAN:

1. On the Ollama machine, set OLLAMA_HOST=0.0.0.0:11434 and restart Ollama.
2. In that machine's firewall, allow port 11434 from the Open WebUI machine only.
3. Set the URL to http://192.168.1.50:11434 (your IP) in Admin Panel > Settings > Connections, or with OLLAMA_BASE_URL on a fresh install.
4. Test with docker exec open-webui curl -s http://192.168.1.50:11434.

You don't need OLLAMA_ORIGINS for this. Open WebUI's backend calls Ollama server to server, and Ollama's FAQ describes OLLAMA_ORIGINS as the setting for extra web origins, such as browser extensions.

If you put Ollama behind its own reverse proxy, Ollama's FAQ shows that it expects the Host header rewritten (proxy_set_header Host localhost:11434; in its nginx example).

Changed OLLAMA_BASE_URL and nothing happened?

Why the old URL sticks

This is the trap that makes people think their fix is wrong. OLLAMA_BASE_URL is a ConfigVar (the docs used to call these PersistentConfig). On first start, Open WebUI saves the value in its database. The env reference says values saved in the database take precedence, so on later starts the environment variable is ignored for that setting.

The test confirmed it. It started with the wrong URL, then changed the compose file to http://ollama:11434 and recreated the container. docker exec ... printenv OLLAMA_BASE_URL showed the new value, but Open WebUI's Ollama config still said:

{"ENABLE_OLLAMA_API":true,"OLLAMA_BASE_URLS":["http://localhost:11434"]}

Three ways to apply the new URL

1. Change it in the UI. This is the recommended option. Click your avatar, then Admin Panel > Settings > Connections, and edit the Ollama URL there. UI changes are saved to the database and take effect.
2. Force a reset from the environment once. Add RESET_CONFIG_ON_START=true, run docker compose up -d, check that it worked, then remove the variable. In testing this switched the stored URL to the env value on the next start. It resets the stored config to your environment values, not just this one setting.
3. Ignore the database for config. ENABLE_PERSISTENT_CONFIG=false makes Open WebUI read env vars on every start. The catch is that settings changed in the admin UI then don't survive a restart.

Deleting the open-webui volume also works, but it deletes your users and chats too. Avoid it.

One more thing came up in testing. Right after adding a model to Ollama, a chat request through Open WebUI returned {"detail":"Model not found"} until the model list had been refreshed. If a new model isn't showing, reload the model list or the page before you blame the connection.

FAQ

Models and connections

Why does Open WebUI show no models?

Open WebUI can't reach Ollama at the URL it has saved, and the model list comes back empty without an error in the UI. Check the container log for Cannot connect to host, then run curl from inside the container as shown above. With Ollama on the host, the usual cause is Ollama listening on 127.0.0.1 only.

Why is OLLAMA_BASE_URL ignored after a restart of the container?

Open WebUI stored the first value in its database, and the stored value wins. Change the URL under Admin Panel > Settings > Connections, or use RESET_CONFIG_ON_START=true for one start.

Can Open WebUI and Ollama run on different machines?

Yes. Make Ollama listen on the network (OLLAMA_HOST=0.0.0.0:11434), allow port 11434 from the Open WebUI machine in the firewall, and point Open WebUI at http://<ollama-ip>:11434. If curl to that address from the Open WebUI container doesn't answer Ollama is running, fix that first.

Access and proxies

How do you open Open WebUI from other devices on your network?

Open WebUI listens on port 8080 inside the container, and -p decides where it appears on the host. This guide binds it to 127.0.0.1:3000, which only the server itself can reach. For other devices, put a reverse proxy in front, or bind to the server's LAN IP (-p 192.168.1.10:3000:8080). With --network=host there's no mapping, so it's port 8080 on every interface. Either way, create the admin account before anyone else can reach the page.

Why do you get "Open WebUI backend required" through an SSH tunnel or proxy?

Open WebUI's connection guide says the page loaded but its request to /api/config on the same address failed. It's usually a port mapping or tunnel that doesn't lead to container port 8080, or a stale cached page. Run curl http://localhost:3000/api/config through the tunnel. JSON back means the backend is reachable. Then try a private window. Behind a proxy, also turn on WebSocket support, which Open WebUI requires from v0.5.0 on, per the same guide. In Nginx Proxy Manager that's the Websockets Support toggle. The n8n reverse proxy guide shows the matching headers for plain nginx.

Originally published on DeployLark: Open WebUI Can't Connect to Ollama in Docker: The Fixes