How to Connect Open WebUI to Ollama in Docker (2026): Host, Remote Server & Model Discovery

If you installed Ollama, pulled a model, and then opened Open WebUI only to see an empty model list or a connection error, the problem is usually not the model. It is the network path between the two services.

This guide focuses on the setup that causes the most confusion: Open WebUI running in Docker while Ollama runs on the same computer or on another machine. We will cover Docker networking, host.docker.internal, remote Ollama servers, model discovery, context length, verification commands, and the failure modes that make a perfectly healthy Ollama installation look broken.

What Open WebUI and Ollama are actually doing

Ollama is the model server. It downloads and loads local models and exposes an HTTP API, normally on port 11434. Open WebUI is the interface sitting in front of that API. When you select a model and send a message, Open WebUI sends the request to Ollama, Ollama runs inference, and the response comes back to the WebUI.

That distinction matters because the URL you enter in Open WebUI must be reachable from the Open WebUI backend, not necessarily from your browser.

For example, if your browser is on Windows and Ollama is also on Windows, http://localhost:11434 may work perfectly in the browser. But if Open WebUI is inside a Docker container, its localhost means the container itself. It does not mean your Windows host.

Open WebUI's current documentation specifically recommends host.docker.internal for reaching a host service from a Docker container. Its Docker examples also add a host-gateway entry so that this name resolves correctly, including on Linux. See the official Open WebUI Ollama connection guide.

Before you start

• Ollama is installed and running.
• At least one Ollama model has been downloaded.
• Docker is installed if you are running Open WebUI in Docker.
• You can access Open WebUI in your browser, normally at http://localhost:3000.
• You know where Ollama is running: the same host, another container, or another computer.

First, test Ollama itself. On the machine running Ollama:

curl http://localhost:11434/api/tags

You should receive JSON containing a models array. Ollama's API documentation defines /api/tags as the endpoint for listing locally available models. If this request fails, fix Ollama before touching Open WebUI.

Setup 1: Open WebUI in Docker, Ollama on the same machine

This is probably the most common setup. Ollama is installed directly on Windows, macOS or Linux, while Open WebUI runs as a Docker container.

Start Open WebUI with host access

The important part is --add-host=host.docker.internal:host-gateway:

docker run -d   -p 3000:8080   --add-host=host.docker.internal:host-gateway   -v open-webui:/app/backend/data   -e WEBUI_SECRET_KEY="$(openssl rand -hex 32)"   --name open-webui   --restart always   ghcr.io/open-webui/open-webui:main

Open WebUI's current quick-start documentation uses the same host-gateway approach. The persistent volume is important because it keeps your chats, users and configuration when the container is recreated.

Open http://localhost:3000, sign in as the administrator, then go to Settings → Admin → Connections. Under the Ollama connection, use:

http://host.docker.internal:11434

Save or verify the connection.

Why not localhost?

Inside the Open WebUI container:

http://localhost:11434

means “port 11434 inside this container.” It does not mean “port 11434 on my laptop.” That is the single most common networking mistake in this setup.

host.docker.internal gives the container a route to the Docker host. On Linux, the explicit --add-host=host.docker.internal:host-gateway entry is particularly useful because it makes the mapping explicit.

Docker Compose version

If you prefer Compose, use a configuration like this:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "3000:8080"
    volumes:
      - open-webui:/app/backend/data
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      WEBUI_SECRET_KEY: "replace-with-a-long-random-secret"
    restart: unless-stopped

volumes:
  open-webui:

Then:

docker compose up -d

With this arrangement, set the Ollama connection in Open WebUI to http://host.docker.internal:11434.

Do not regenerate the secret every time you recreate the container. Open WebUI recommends keeping a persistent WEBUI_SECRET_KEY; changing or omitting it can cause users to be logged out after container recreation.

Setup 2: Ollama is in another Docker container

If both services are containers on the same Docker network, you normally do not need host.docker.internal. Use the Ollama container or Compose service name.

http://ollama:11434

For example:

services:
  ollama:
    image: ollama/ollama:latest
    volumes:
      - ollama:/root/.ollama

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "3000:8080"
    environment:
      OLLAMA_BASE_URL: "http://ollama:11434"
      WEBUI_SECRET_KEY: "replace-with-a-long-random-secret"
    volumes:
      - open-webui:/app/backend/data
    depends_on:
      - ollama

volumes:
  ollama:
  open-webui:

The advantage is that Docker's internal DNS resolves ollama to the correct container. You avoid exposing Ollama unnecessarily to the host or LAN.

Setup 3: Ollama is on another computer

This is useful if you have a powerful desktop or GPU server running Ollama while Open WebUI runs on a laptop, NAS or VPS.

Suppose the Ollama machine has LAN address 192.168.1.50. Open WebUI would connect to:

http://192.168.1.50:11434

But there is another requirement: Ollama must actually listen on an address reachable from the network. Ollama normally binds to localhost. Its current documentation explains that OLLAMA_HOST controls the bind address.

For a temporary shell-based setup you can use an address such as:

OLLAMA_HOST=0.0.0.0:11434 ollama serve

On Linux running Ollama through systemd, configure the environment variable in the service and restart Ollama. On Windows, configure the environment variable for the Ollama application and restart it. On macOS, Ollama's application environment is handled differently; follow the platform-specific instructions in its documentation rather than blindly copying a Linux command.

Security warning: listening on 0.0.0.0 makes the service reachable on network interfaces. That does not automatically mean you should expose port 11434 to the public internet. For a home or office LAN, restrict access with your firewall. For remote access over the internet, use an authenticated reverse proxy or private network rather than publishing an unauthenticated Ollama endpoint directly.

How to verify the network path before blaming Open WebUI

When a connection fails, test each layer separately.

1. Test Ollama locally

curl http://localhost:11434/api/tags

If this fails, Ollama itself is not reachable.

2. Test the host address

If Open WebUI is in Docker and Ollama is on the host, test the equivalent host address from inside the container:

docker exec -it open-webui sh

Depending on the image and shell availability, use a network client available in the container or inspect the Open WebUI logs. The important target is:

http://host.docker.internal:11434/api/tags

A successful response should contain your Ollama models.

3. Test the remote machine

From the machine hosting Open WebUI:

curl http://192.168.1.50:11434/api/tags

If this works from the host but fails from the Open WebUI container, the remaining problem is Docker networking. If it fails from both, inspect the Ollama bind address and firewall.

Model discovery: why Ollama works but Open WebUI shows no models

Open WebUI can discover Ollama models through the Ollama API. A healthy Ollama server should return model information from /api/tags.

Start with:

ollama list

Then compare it with:

curl http://localhost:11434/api/tags

If ollama list shows models but the API does not, you may be talking to a different Ollama instance. This happens surprisingly often when a machine has Ollama installed natively while another Ollama container is also running.

Also check the model's exact name:

ollama list

Model names can include tags such as :latest or quantization-specific identifiers. Do not assume that two similarly named entries are necessarily the same model.

If the API returns the models but Open WebUI does not, re-check the connection URL in Settings → Admin → Connections and use the connection's verification/refresh control. Open WebUI's documentation specifically describes model discovery and connection verification from this settings area.

Use OLLAMA_BASE_URL when you want the connection configured at startup

You do not have to enter the Ollama address manually after every deployment. Open WebUI supports OLLAMA_BASE_URL.

For Ollama running on the Docker host:

environment:
  OLLAMA_BASE_URL: "http://host.docker.internal:11434"
  WEBUI_SECRET_KEY: "replace-with-a-long-random-secret"

For another machine:

environment:
  OLLAMA_BASE_URL: "http://192.168.1.50:11434"

Open WebUI also supports multiple Ollama endpoints through OLLAMA_BASE_URLS. This is useful for more advanced deployments where several Ollama servers are available.

What num_ctx means — and why it can make a working connection look broken

Connection problems and context-length problems are different, but users often discover them at the same time.

num_ctx controls the context window requested for an Ollama model. It affects how much conversation, retrieved information and other input the model can process in a request.

For example, an Ollama API request can specify:

{
  "model": "your-model",
  "prompt": "Explain this document.",
  "options": {
    "num_ctx": 8192
  }
}

Open WebUI's current environment documentation notes an important detail: a per-model num_ctx setting can override the server-level OLLAMA_CONTEXT_LENGTH. In other words, increasing the Ollama server setting does not necessarily win if Open WebUI is sending its own value.

Start conservatively. A larger context consumes more memory, and the practical limit depends on the model, quantization, GPU/CPU memory and the rest of the request. If a model suddenly becomes slow, starts swapping, fails to load, or produces an apparently blank response after enabling a larger context, test again with a smaller value.

For a deeper look at local model memory and RAM requirements, see our Local AI models by RAM guide.

Common errors and what they usually mean

A reliable troubleshooting order

1. Check Ollama. Run ollama list.
2. Check the API. Run curl http://localhost:11434/api/tags on the Ollama machine.
3. Identify where Open WebUI runs. Native, Docker, Compose, Podman or another server changes the correct URL.
4. Replace localhost with the correct network address. Docker host access normally means host.docker.internal; a Compose service normally means the service name.
5. Check Ollama's bind address. Remote clients cannot reach a service listening only on 127.0.0.1.
6. Check firewall rules. Especially when Ollama is on another machine.
7. Verify model discovery. Compare the API's model list with what Open WebUI displays.
8. Only then investigate model parameters. Context length, memory and model compatibility are separate from basic connectivity.

Privacy and security: local does not automatically mean safe

Running Ollama locally can keep inference on your own machine, but your network configuration still matters. If you expose port 11434 to a LAN or the internet, another device that can reach that endpoint may be able to interact with your model server depending on your configuration.

A safer architecture is usually:

• Keep Ollama on a private interface or private network.
• Allow Open WebUI to reach it over the internal Docker/LAN network.
• Use firewall rules to restrict port 11434.
• Do not publish an unauthenticated Ollama endpoint directly to the public internet.
• Keep Open WebUI's persistent secret key private.
• Back up the Open WebUI data volume before major upgrades.

Also remember that Open WebUI can connect to more than just Ollama. If you later add web search, cloud providers, MCP servers or other tools, the privacy model changes because those features may send selected data to external services. Our AI agent security guide covers the broader permission and prompt-injection risks.

When this setup is not the right choice

Open WebUI + Ollama is attractive when you want a self-hosted interface around local models, but it is not automatically the best architecture for every workload.

If you need high-throughput serving for many concurrent users, an inference server such as vLLM may fit the workload better than Ollama. Open WebUI supports OpenAI-compatible providers as well, so you can keep the interface while changing the inference backend.

For an overview of the broader Open WebUI ecosystem, including RAG, agents, web search, MCP and Docker, see our Open WebUI complete guide. If you are evaluating another local model runner, our Ollama vs LM Studio comparison covers the architectural differences.

Quick verification checklist

• Ollama is running.
• ollama list shows the model you expect.
• curl http://localhost:11434/api/tags returns model JSON.
• Docker Open WebUI uses host.docker.internal when Ollama is on the host.
• Ollama in another Compose container is addressed by its service name.
• Remote Ollama listens on a reachable interface and is protected by appropriate network controls.
• Open WebUI's connection verification succeeds.
• The expected models appear in the model selector.
• num_ctx is reasonable for your available memory.
• Your WEBUI_SECRET_KEY is persistent.

FAQ

Why does Open WebUI say Ollama is offline when Ollama works?

Usually because Open WebUI is running in a different network namespace. If Open WebUI is in Docker and Ollama is on the host, try http://host.docker.internal:11434 rather than http://localhost:11434.

Why are my Ollama models not showing in Open WebUI?

First call /api/tags against the exact Ollama server that Open WebUI is supposed to use. If the API returns no models, fix Ollama. If it returns models but Open WebUI does not, verify the connection URL and refresh the connection.

Do I need to expose Ollama on 0.0.0.0?

Only when another machine or network namespace needs to reach the Ollama server through a network interface. If Open WebUI and Ollama share a Docker network, use the Docker service name instead. If both are on the same host and Open WebUI can reach the host through host.docker.internal, you may not need to expose Ollama beyond the host.

What should I set num_ctx to?

There is no universal best value. Start with a modest context and increase it only when your workload requires it and your hardware can handle the additional memory use. If a model becomes unstable or dramatically slower after increasing it, reduce the value and test again.

Can Open WebUI connect to a remote Ollama server?

Yes. Configure the Ollama connection with the remote server's reachable URL, such as http://192.168.1.50:11434, and make sure Ollama is listening on a reachable interface and the network firewall permits the connection.

Should I use Docker host networking instead?

Host networking can simplify some Linux deployments, but it changes the networking model and is not necessary for the standard host-Ollama setup. The documented host.docker.internal approach is easier to understand and keeps the container's normal networking behavior.

Official sources and further reading

• Open WebUI Quick Start
• Open WebUI: Ollama connection guide
• Open WebUI: Connection troubleshooting
• Open WebUI environment configuration
• Ollama API documentation
• Ollama FAQ and configuration reference

Bottom line: when Open WebUI and Ollama are not talking, start with the network path, not the model. Identify where each service runs, use the address that is reachable from the Open WebUI backend, verify /api/tags, and only then tune context length or model settings. That approach turns a vague “Ollama isn't showing up” problem into a short sequence of checks you can actually verify.