Connect Open WebUI to Ollama

Quick diagnosis

Open WebUI is the interface. Ollama is the model runtime underneath it. Get Ollama working by itself first, then connect Open WebUI to the Ollama service. If models do not appear, diagnose the service address and network boundary instead of reinstalling both products at random.

The order matters: a broken Ollama runtime cannot be fixed from the Open WebUI screen.

First three checks

1. Run ollama list and a short chat with the exact installed model on the Ollama computer.
2. Open http://localhost:11434/api/tags in a browser on that computer and confirm it returns the model list.
3. Set the Ollama connection address for the actual host or container arrangement, then test it from Open WebUI.

Confirm Ollama works first

Before touching Open WebUI, run one known model directly through Ollama and confirm that it returns a normal response. Also confirm that the local Ollama API responds on the host.

Record:

• the machine where Ollama is running;
• the machine or container where Open WebUI is running;
• the Ollama host and port;
• whether either service is inside Docker;
• whether a firewall, VPN, proxy, or security tool changes local networking.

If Ollama cannot return a response directly, stop and fix that layer first.

Check the API from both environments

On the Ollama computer, run curl http://localhost:11434/api/tags in Terminal, or Invoke-RestMethod http://localhost:11434/api/tags in PowerShell. A JSON response with a models list means the API is reachable. An empty list means there are no models on that server; a refused connection means the service or address must be fixed first.

For the standard Open WebUI Docker container, this command tests the host API from the backend that actually needs it:

docker exec open-webui python -c "import urllib.request; print(urllib.request.urlopen('http://host.docker.internal:11434/api/tags', timeout=5).read().decode())"

Replace open-webui with your container name from docker ps. A JSON model list confirms that path. A name-resolution error points to the Docker host mapping; a refusal or timeout points to the service bind or firewall. On Linux Docker, the documented host mapping is --add-host=host.docker.internal:host-gateway (or extra_hosts in Compose). That name alone is not enough when Ollama listens only on 127.0.0.1; see "Open WebUI runs in Docker and Ollama runs on the host" below for the Linux fix. Do not open the model API to the internet.

Pick the correct connection pattern

In Open WebUI, open the admin settings and Connections, then edit the Ollama connection. Saved connection settings take precedence over a changed OLLAMA_BASE_URL (the ENABLE_PERSISTENT_CONFIG setting is on by default); check the address displayed in the interface.

The provider base address ends at the port; the /api/tags suffix above is for the diagnostic request. After saving, refresh the model list and ask the same short prompt that worked directly in Ollama.

Both products run natively on the same machine

Open WebUI should point to the local Ollama service on the same host. A loopback address can work because both processes share the host network.

Open WebUI runs in Docker and Ollama runs on the host

Inside a container, localhost means the container itself, not your computer. What to do depends on your Docker.

Docker Desktop (Windows, macOS). Use http://host.docker.internal:11434. No Ollama setting needs to change.

Docker Engine on Linux, with Ollama installed as a service. Ollama listens only on 127.0.0.1:11434 by default, and a container on the bridge network cannot reach that address. Open WebUI's connection-error page documents two routes.

Route A: run the container on the host network, so 127.0.0.1 inside the container means the host. First create or reuse the private openwebui.env file with the server key, as shown in the installation guide. Confirm the existing container uses the named open-webui data volume with docker inspect open-webui; if it uses a different volume or folder, use that same storage in the command below. Then replace the container, keeping its data volume:

docker rm -f open-webui
docker run -d --network=host -v open-webui:/app/backend/data --env-file openwebui.env -e HOST=127.0.0.1 -e OLLAMA_BASE_URL=http://127.0.0.1:11434 --name open-webui --restart unless-stopped ghcr.io/open-webui/open-webui:v0.12.3

Replace v0.12.3 with the version tag you pinned. Open WebUI is then at http://localhost:8080, not port 3000, and a 127.0.0.1:3000:8080 loopback-only mapping no longer applies.

Route B: keep the bridge network and make Ollama listen where the bridge can reach it. Run sudo systemctl edit ollama.service, add these two lines, then save:

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

Then run sudo systemctl daemon-reload and sudo systemctl restart ollama. The address 0.0.0.0 accepts connections on every network interface, so allow port 11434 only from the Docker bridge or from computers you trust.

You changed OLLAMA_BASE_URL and nothing changed. Open WebUI keeps saved connection settings in its database, and they take precedence over environment variables. Edit the address in Admin Settings, Connections. If you cannot open the interface, start the container once with -e RESET_CONFIG_ON_START=true, which resets database-saved settings to the environment values; write down your other settings first. Do not delete the data volume.

Both products run in containers

Use the container or service name on the shared Docker network rather than a host loopback address. Confirm that both containers are on the same user-defined Docker network. The Ollama port needs publishing only if something outside Docker must reach it.

The services run on different machines

This is no longer a single-machine loopback setup. You need an intentional network bind, firewall path, and access-control decision. Do not expose the model service broadly merely to make the interface connect.

Diagnose by symptom

A clean diagnostic sequence

1. Run a known model directly through Ollama.
2. Confirm the Ollama API responds on the machine hosting it.
3. Confirm the exact model appears in Ollama’s local model list.
4. Identify whether Open WebUI is native, in Docker, or on another machine.
5. Test whether that environment can reach the Ollama host and port.
6. Set the Open WebUI provider address for the real topology.
7. Refresh the model list and run the same known model.
8. Add authentication and network restrictions before any intentional remote exposure.

Change one layer at a time. Otherwise a successful result does not tell you which change fixed the problem.

Docker-specific mistakes

Using localhost inside the container

A container has its own network namespace. localhost usually points back to the Open WebUI container. The Ollama process running on the host is somewhere else from the container’s perspective.

Starting Open WebUI before the provider is ready

The interface may load even though the provider is unavailable. Confirm provider readiness independently and restart or refresh after the service is available.

Publishing more ports than necessary

Do not expose Ollama or Open WebUI on every interface merely because the default connection failed. First establish the minimum network path the actual deployment needs.

Confusing browser access with container access

Your browser reaching Open WebUI says nothing about whether the Open WebUI backend can reach Ollama. Test the backend-to-provider path separately.

What success looks like

Success means:

• Ollama returns a direct response outside Open WebUI;
• Open WebUI lists the intended local Ollama models;
• the same known model returns a response through the browser interface;
• the connection survives a normal service restart;
• the services are exposed only to the network scope you intentionally chose.

Privacy and network boundary

A local browser interface can still connect to remote providers, web search, tools, plugins, or network services. Confirm the selected model and provider, not merely the fact that Open WebUI is self-hosted.

Keep single-machine services on loopback where practical. Before allowing LAN or internet access, add appropriate authentication, firewall rules, transport protection, and organizational controls for the data involved.

When to stop

Stop changing Open WebUI settings when Ollama itself is not working. Stop broadening network exposure when you cannot explain which machine, process, and user actually need access.

Next step

Follow the Open WebUI with Ollama setup guide after the connection works, or return to install Ollama when the runtime itself is the failing layer.

Sources

• Open WebUI quickstart and container setup
• Open WebUI connection errors
• Open WebUI v0.12.3 server address and key settings
• Ollama binding and proxies