Open WebUI loads, but the model selector is empty and nobody can start a chat. Open WebUI is the interface, not the model: it needs a model provider such as Ollama or an OpenAI-compatible server, and installing the interface alone does not supply any chat models. Open WebUI Quick Start Work from the provider outward: confirm it has a chat model, confirm Open WebUI can reach it, then confirm Open WebUI is set up to show it to the account you are using.
Check that the backend has a model
On the machine running Ollama, list downloaded models. If the service is stopped, start the Ollama application or service; ollama serve starts a foreground server. If no models appear, pull a chat model suitable for your hardware; gemma3 below is an example. An empty ollama ps only means no model is currently loaded, so use ollama ls for this check. Ollama CLI Reference
ollama ls
# Run this only if you need to download this model:
ollama pull gemma3
curl --fail --show-error http://localhost:11434/api/tags
The API response should contain a models array with the expected model name. An empty array means this server has no models to list; a failed request means you have not established connectivity. Ollama List Models API
Check the actual instance Open WebUI uses. For an Ollama container named ollama, run docker exec ollama ollama ls and, if needed, docker exec ollama ollama pull gemma3. A download into a separate host installation does not populate that container’s model volume. Ollama Docker Guide
Check that Open WebUI can reach it
Open Settings > Admin > Connections, then inspect Manage Ollama API Connections. For Docker connecting to host Ollama, use http://host.docker.internal:11434. Enter the base URL, without /api/tags. This is a backend connection, so a successful request from your laptop’s browser is insufficient. Ollama connection guide
Choose the address from Open WebUI’s execution environment:
| Deployment | Ollama base URL |
|---|---|
| Both run directly on the same host | http://localhost:11434 |
| Open WebUI in Docker, Ollama on its host | http://host.docker.internal:11434 |
Separate containers sharing a network; service named ollama | http://ollama:11434 |
Compose services can resolve each other by service name on a shared network. For host access on Linux, add the host-gateway mapping. Merge this fragment into your existing service definition, preserving its image, ports and data volume. Docker Compose Networking
services:
open-webui:
extra_hosts:
- "host.docker.internal:host-gateway"
environment:
OLLAMA_BASE_URL: "http://host.docker.internal:11434"
Apply the edited Compose service with docker compose up -d open-webui. Then test from inside it, substituting your configured base URL:
docker compose exec open-webui curl --fail --show-error \
http://host.docker.internal:11434/api/tags
If the host succeeds but the container fails, look at Ollama’s listener. Ollama defaults to 127.0.0.1:11434; set OLLAMA_HOST to an address reachable from Docker, restart Ollama, and if it binds all interfaces, restrict network access to trusted clients. Ollama FAQ Our guide to Open WebUI not connecting to Ollama walks through the bind address, the Docker host URL and slow endpoints step by step.
For connection refusal, timeouts or name-resolution errors, inspect docker compose logs open-webui and correct the listener, address or network indicated. Review every configured endpoint: an abandoned connection can delay model discovery even when another backend works. Open WebUI Connection Errors
Correct URL, still empty: saved settings and filters
Changing Compose may leave the effective URL unchanged. Open WebUI persists connection configuration in its database; saved settings can override environment variables. Also check OLLAMA_BASE_URLS, which takes precedence over singular OLLAMA_BASE_URL. Update the active connection in the admin interface and save. Environment configuration
If you intentionally manage configuration through environment variables, ENABLE_PERSISTENT_CONFIG=False makes them authoritative, but admin changes will not survive restarts. Avoid deleting the data volume to fix a URL. If Cache Base Model List is enabled, saving Connections refreshes that backend cache; reloading the browser alone does not. Environment configuration
Inspect Model IDs (Filter) for stale names or missing tags. For Ollama, an empty filter shows all models; a populated filter limits visibility. Ollama connection guide
The admin sees the model but a user does not
If an administrator sees the model but a regular user cannot, the connection is working and the problem is access. Inspect that model’s access grants and the user’s groups. Open WebUI supports per-resource permissions, so repeat the final check using the affected account. Grant the intended access instead of promoting the user to administrator. Authentication and Access
Using vLLM or another compatible API
For vLLM, configure Manage OpenAI API Connections, using the server’s API base ending in /v1. The documented host-from-Docker example is http://host.docker.internal:8000/v1. Supply the key configured on that server. vLLM connection guide
Open WebUI verifies compatible connections through /models. Check the base URL, credentials and enabled toggle. Some providers omit model discovery or authenticate it differently. When that behavior is documented for your provider, enter exact supported names under Model IDs (Filter) and save. A manually listed name still needs a successful chat request to prove usability. OpenAI-compatible connections
Confirm the fix
Sign in as the affected user, select the model and send a short prompt. Treat the two results separately: the model appearing in the selector shows that discovery and access work, and a reply shows that generation works. A cached or manually entered model list can still show a name while the backend behind it is unavailable, so a model in the list is not proof on its own. If the list fills but chats fail, return to the connection checks above, starting with the logs.