Connect Ollama to AnythingLLM and Open WebUI: Diagnose the Network First

Updated 28 October 2026 · Sources & corrections

A frontend needs a reachable Ollama server and an installed model tag. Start with those two facts before changing application settings. The correct address depends on whether the frontend runs on the host, inside a container, or on another computer.

1. Verify the host endpoint

ollama --version
ollama list

PowerShell:

Invoke-RestMethod -Uri 'http://127.0.0.1:11434/api/tags'

macOS/Linux shell:

curl --fail --show-error http://127.0.0.1:11434/api/tags

A response containing a models array confirms reachability of that endpoint. Copy an exact model name from the response or ollama list. Do not use an invented digest or a sample size as proof of your own installation.

2. Choose the address from the frontend’s location

• Frontend and Ollama on the same host: test the local endpoint first.
• Frontend in a container: localhost refers to that container, so verify the host route and Ollama binding.
• Frontend on another host: explicitly configure a trusted network route and access control before using a host address.

A successful browser request on the host does not prove a container can reach the same endpoint. Test from the frontend environment. Docker host routing differs by platform; follow the frontend’s deployment instructions rather than pasting a command written for another operating system.

Docker: identify the request origin before changing the URL

For Open WebUI’s backend Ollama connection, a host-browser test and a container test answer different questions. Draw the route from the actual caller to Ollama. The following addresses are conditional examples, not a universal configuration:

Docker’s Compose networking guide explains service-name discovery and why container-to-container connections use the container port. A service IP can change after recreation. Do not substitute a published host port into a service-to-service address without checking the topology.

Read-only checks from the existing container

Replace open-webui with your existing frontend container name. These examples inspect the current deployment; they do not recreate it. The curl commands require curl to be present in that image. A missing executable is not evidence of a network outage.

docker ps --format '{{.Names}}'
docker inspect --format '{{json .NetworkSettings.Networks}}' open-webui
docker exec open-webui curl --version

Choose only the address matching your topology. For the shared-network example where Ollama’s service name is ollama:

docker exec open-webui curl --fail --show-error --max-time 10 http://ollama:11434/api/tags

For a configured container-to-host route, test that route instead:

docker exec open-webui curl --fail --show-error --max-time 10 http://host.docker.internal:11434/api/tags

These are interpretation branches, not captured command outputs. If the configured URL is HTTPS and certificate validation fails, repair the trust configuration rather than adding curl’s insecure flag. Keep model access on the intended private route; changing CORS does not repair a refused backend TCP connection.

When an environment change appears to be ignored

Open WebUI documents backend/browser connection differences and persisted connection settings. Saved database configuration can take precedence over environment values. If the admin interface is accessible, inspect the Ollama connection under Settings → Admin → Connections and compare it with the tested route. Preserve the previous value before a targeted change. Do not delete the database or disable persistence globally just to diagnose one endpoint.

AnythingLLM has its own provider settings and deployment variants; do not copy Open WebUI’s environment names into it. After reachability is established, use the appropriate provider’s native base URL and verify a short chat before investigating document ingestion.

AnythingLLM: check Built-in versus the separate Ollama provider

If models appear in your Ollama terminal but not in AnythingLLM, confirm the selected provider before downloading them again. A frontend’s built-in engine and your separately installed Ollama instance are not automatically the same library.

The current AnythingLLM built-in provider documentation says new desktop installations use Lemonade. Older desktop installations can still have the previous embedded Ollama engine. To use a separately installed Ollama server, choose the Ollama provider and verify its actual endpoint.

The official built-in-engine migration note warns that switching from the older embedded engine removes its old engine and downloaded models, requiring downloads again. Do not use an engine upgrade as a diagnostic reset. Record the existing provider, selected model and any custom storage location before considering a migration.

For an external Ollama connection, query the selected server’s model list from the same environment as AnythingLLM, using the topology checks above. Then copy an exact listed text-generation model into the provider selection where supported. A successful terminal request against a different host does not establish the application’s configuration.

If the selected tag is absent, use our same-server model-name checks. If the list responds but chat fails, retain the error body and distinguish that failure from connection discovery. A model-list response does not prove generation capacity.

Also inspect chat and embedding providers separately. The Ollama embedder reference requires an embedding-capable model. A working chat model is not evidence that document embeddings use the same engine or even the same destination. Record each selected provider before investigating retrieval.

Next step: save the provider name, application version, selected server URL and model identifier as a small diagnostic record. Remove secrets before sharing it. This is more useful than deleting the database or treating every missing model as a Docker network fault.

Update, 28 October 2026: added the built-in-versus-external provider distinction using current vendor documentation. No AnythingLLM deployment, engine migration or model request was executed for this update.

3. Configure the frontend

Use AnythingLLM’s Ollama provider configuration or Open WebUI’s current provider connection instructions. Enter the base URL expected by that provider; a native Ollama provider and an OpenAI-compatible provider can expect different URL suffixes. Confirm the model appears and send a short request before importing large documents.

4. Distinguish connection and document-chat problems

If no models are visible, check reachability and model tags. If a simple chat works but document retrieval fails, inspect the embedding provider, document processing and retrieval configuration separately. Changing the chat model does not necessarily repair an embedding or parsing failure.

5. Interpret browser CORS errors carefully

CORS applies to browser cross-origin requests. It is not a general explanation for server-to-server connection failures. Configure only the required origin when a browser calls Ollama directly; do not enable wildcard origins or expose the model server publicly as a default fix.

This guide does not claim that a particular Docker or frontend version was executed in a lab. Follow the versioned vendor steps below and record the exact host/container topology when reporting a problem. For Cursor or other editors, check their current custom-provider support rather than assuming every editor accepts an arbitrary local endpoint.

Related: Ollama diagnostics and model storage.

If a retrieval application connects successfully but reports vector-size errors after a model change, use our embedding-dimension and index-contract checks before rebuilding its index.

If the frontend connects but seems to ignore a larger server context setting, use our client context-override checks to compare its request with the running allocation.

Editorial update, 25 October 2026: added topology-specific Docker checks and saved-setting diagnosis from official documentation. Three command blocks were syntax-checked locally; no Docker deployment was executed or benchmarked.