Fix Open WebUI Showing No Models in the Dropdown

The exact symptom

Related: Fix Stable Diffusion Out Of Memory on a 6GB VRAM GPU →

You just finished spinning up Open WebUI. You load the web interface on port 3000, create your initial admin account, and get to the main chat screen. You click the "Select a model" dropdown at the top of the page, and it is completely empty.

You know you installed Ollama. You know the service is running. But Open WebUI acts like your machine is a ghost town.

I hit this exact issue the first time I set up my local stack. The problem almost always boils down to one of two things: you either haven't downloaded a model yet, or your Open WebUI Docker container is trapped in an isolated network and cannot see the Ollama service running on your host machine.

Here is exactly how to diagnose and fix this issue so you can actually start chatting.

Step 1: Prove Ollama actually has models

Related: Fix ComfyUI "Torch Not Compiled With CUDA Enabled" Error →

This sounds obvious, but you need to rule it out first. Installing the Ollama software does not install any AI models by default. The engine is there, but the tank is empty. Open WebUI populates its dropdown by reading the Ollama API, and if the API returns an empty list, the dropdown stays empty.

Drop into your terminal and run this command on the machine hosting Ollama:

ollama list

If it returns just the header row (NAME ID SIZE MODIFIED) and nothing else, Open WebUI is working perfectly fine—it just doesn't have anything to show you.

You need to pull a model. If you are working with limited hardware, check out running a local LLM on 8GB of RAM for some lightweight options. Otherwise, pull the standard Llama 3 model by running:

ollama run llama3.2

Wait for the download to finish. If you aren't sure if your hardware can handle larger models, I recommend reading up on how much RAM you actually need for local AI before you start downloading 30GB files.

Once the download finishes, run ollama list again. You should see llama3.2:latest in the output. Go back to Open WebUI, refresh the page, and check the dropdown. If it is still empty, proceed to the next step.

Step 2: Read the Docker logs to confirm the network failure

Related: A One-File Docker Compose Stack for Ollama and Open WebUI →

If you have a model but it isn't showing up, the Open WebUI container cannot communicate with the Ollama service. We need to look at the logs to confirm exactly how it is failing.

Find your Open WebUI container ID:

docker ps

Look for the container using the ghcr.io/open-webui/open-webui:main image. Grab the container ID (e.g., a1b2c3d4e5f6) and check the logs for connection errors:

docker logs a1b2c3d4e5f6 | grep -i error

You are almost certainly going to see an error string that looks like this: aiohttp.client_exceptions.ClientConnectorError: Cannot connect to host localhost:11434 ssl:default [Connection refused]

This is the classic Docker "localhost" trap. When Open WebUI tries to connect to http://localhost:11434, it is looking inside its own Docker container. Ollama is not inside that container; Ollama is running on your host operating system. The connection is refused because nothing is listening on port 11434 inside the Open WebUI container. If you see this error, you are dealing with a known issue where Open WebUI in Docker cannot reach Ollama.

Step 3: Fix the Docker network gap

Related: Fixing Painfully Slow Whisper Transcription →

We need to tell the Open WebUI container how to point its requests out of the container and onto your host machine. The method depends on your operating system.

For Mac and Windows (Docker Desktop)

Docker Desktop provides a magic DNS name that resolves from inside the container to your host machine: host.docker.internal.

You need to destroy your current Open WebUI container and spin it up again, explicitly passing this address via the OLLAMA_BASE_URL environment variable.

docker rm -f open-webui

docker run -d -p 3000:8080
--add-host=host.docker.internal:host-gateway
-v open-webui-main:/app/backend/data
--name open-webui
--restart always
-e OLLAMA_BASE_URL=http://host.docker.internal:11434
ghcr.io/open-webui/open-webui:main

For Linux (Native Docker)

Linux Docker doesn't use the host.docker.internal trick by default. The most reliable way to let a Docker container access a host service on Linux is to use --network host. This tells the container to share the host's networking stack directly.

docker rm -f open-webui

docker run -d
--network host
-v open-webui-main:/app/backend/data
--name open-webui
--restart always
-e OLLAMA_BASE_URL=http://127.0.0.1:11434
ghcr.io/open-webui/open-webui:main

Note: When you use --network host, you do not need the -p 3000:8080 port mapping argument. Open WebUI will default to port 8080 on your host machine. You will access it at http://localhost:8080 instead of 3000.

Step 4: Fix Ollama's bind address (OLLAMA_HOST)

Related: Secure Ollama with Nginx, HTTPS, and a Password →

If you applied the network fixes above and the dropdown is still empty, you have a bind address issue.

By default, Ollama only listens for traffic on 127.0.0.1. It aggressively rejects requests coming from other network interfaces. If your Docker container connects via the Docker bridge network (usually an IP like 172.17.0.1), Ollama sees this as an external request and drops it.

You will often see this manifest in the logs as Ollama connection refused on 127.0.0.1:11434.

We need to tell Ollama to listen on all network interfaces by setting the environment variable OLLAMA_HOST="0.0.0.0".

Changing OLLAMA_HOST on Linux

If you installed Ollama via their official curl script, it runs as a systemd service. You cannot just export a variable in your terminal; you have to edit the service file.

1. Open the service configuration override:

sudo systemctl edit ollama.service

2. This opens your default text editor. Add the following lines exactly as shown at the very top of the file:

[Service]
Environment="OLLAMA_HOST=0.0.0.0"

3. Save the file and exit the editor.
4. Reload the systemd daemon and restart Ollama:

sudo systemctl daemon-reload
sudo systemctl restart ollama

5. Verify it worked by checking your listening ports:

sudo netstat -tulpn | grep 11434

You should see :::11434 or 0.0.0.0:11434, indicating it is listening globally.

Changing OLLAMA_HOST on macOS

If you run the Ollama Mac app, you need to set the variable using launchctl so the background service picks it up.

Open your terminal and run:

launchctl setenv OLLAMA_HOST "0.0.0.0"

Then entirely quit the Ollama app (click the tray icon and select Quit) and relaunch it from your Applications folder.

Step 5: Verify the connection inside Open WebUI

Related: How to Stop Ollama From Unloading Models (keep_alive) →

Now that the networking is fixed and Ollama is listening, let's verify the connection in the Open WebUI settings.

1. Go back to your browser and log into Open WebUI.
2. Click your profile icon in the bottom left and select Admin Panel.
3. Click on the Settings tab, then select Connections from the left sidebar.
4. Look under the Ollama API section. Ensure the toggle is turned ON.
5. In the URL box, ensure it matches your setup:
   • Mac/Windows: http://host.docker.internal:11434
   • Linux: http://127.0.0.1:11434
6. Click the small refresh icon next to the URL input box.

If everything is configured correctly, a small green notification will pop up saying "Server connection verified." If you go back to the main chat screen, your models will now populate the dropdown menu.

A quick comparison of connection methods

If you are confused about which network strategy to use for Docker, here is a breakdown of the three common methods for hooking Open WebUI up to Ollama.

What did NOT work for me

When I first encountered the empty dropdown, I wasted a couple of hours going down troubleshooting rabbit holes that did absolutely nothing. I want to save you that time.

Reinstalling Docker and Open WebUI I assumed my Docker container was corrupted, so I pruned my entire system and re-pulled the images. It changed nothing. The default network architecture of Docker is what causes this issue, so a fresh install just recreates the exact same network barriers.

Setting OLLAMA_ORIGINS="*" If you Google this issue, you will see a lot of people telling you to set OLLAMA_ORIGINS="*". This is a misunderstanding of the problem. That environment variable fixes CORS (Cross-Origin Resource Sharing) issues when a web browser tries to hit the Ollama API directly. Open WebUI connects to Ollama server-to-server (backend-to-backend). CORS does not apply to server-side requests. Changing this variable won't hurt anything, but it will not fix an empty model dropdown.

Chmodding the Ollama models folder I thought maybe the Open WebUI container didn't have read permissions to the directory where Ollama stores .gguf files. This is a fundamental misunderstanding of how the app works. Open WebUI does not read the model files off your hard drive. It makes an HTTP GET request to http://<ollama-ip>:11434/api/tags. File permissions on the host have nothing to do with it.

FAQ

Question: Why does the web interface load perfectly fine if the backend is broken?

Open WebUI runs its own lightweight web server (often FastAPI or Node-based, depending on the fork/version). That web server handles the frontend UI, user accounts, and database. It operates completely independently of Ollama. It only queries Ollama when it needs to populate the model list or generate text.

Question: Can I pull models directly from the Open WebUI interface instead of the terminal?

Yes. Once you have fixed the connection issue and the API is talking, you can go to Admin Panel -> Settings -> Models. There is an input box where you can type a model tag (like phi3) and click a download button to pull it without opening a terminal.

Question: Does setting OLLAMA_HOST to 0.0.0.0 make my machine vulnerable?

It exposes the Ollama API to any device on your local network (like your Wi-Fi). It does not expose it to the internet unless you have manually configured port forwarding on your router for port 11434. On a private home network, the security risk is negligible.

Question: How do I refresh the model list if I pull a new model in the terminal?

You do not need to restart the Docker container. Just refresh your web browser tab. Open WebUI requests the /api/tags endpoint dynamically every time the UI loads, so newly pulled models will appear immediately upon a page refresh.