Is "docker exec open-notebook-ollama-1 ollama pull ..." necessary if local host ollama exists and connectable?

[chris-opendata]

I have local host ollama and models installed and running prior to using open-notebook. Setting up open-notebook, I notice that https://github.com/lfnovo/open-notebook/blob/main/examples/docker-compose-full-local.yml suggests pulling and running ollama and models in a Docker container open-notebook-ollama-1. However, configuring Ollama and local models in the UI page at http://localhost:8502/ allows me to connect to the local host Ollama and models externally via http://host.docker.internal:11434. I successfully configured this external connection on the page at http://localhost:8502/settings/api-keys. So, this leads to my question here. I would remove ollama and models from the Docker container to save space if it is not necessary given the said context.

[chris-opendata]

Answer it myself. My testing indicated that there was no need to pull Ollama models into a container if using Ollama models natively installed on the local host.

[muhammadbalawal]

Your conclusion is right, and it is worth writing down why, because there are two conditions that have to hold and they are easy to trip over later.

The containerised ollama in docker-compose-full-local.yml is a convenience bundle. It exists so someone with no local ollama can get a working stack from a single compose file. It is not a dependency of open-notebook itself. Open-notebook only needs an ollama HTTP endpoint it can reach, and it does not care whether that endpoint is a sibling container or the host daemon. So yes, you can drop the ollama service and its model volume and reclaim the disk.

The two conditions:

First, ollama has to be listening on an address the container can reach. By default it binds to 127.0.0.1:11434, which is the host loopback and is not reachable from inside a container. If yours is working already then something has widened that, but if it ever stops working after a reinstall or an upgrade, that is the usual cause. You set it with:

OLLAMA_HOST=0.0.0.0:11434

On macOS with the ollama app, this goes in launchctl setenv OLLAMA_HOST 0.0.0.0:11434 followed by a restart of the app, otherwise the setting does not survive.

Second, host.docker.internal is provided automatically by Docker Desktop on macOS and Windows, but not by plain Docker Engine on Linux. If you or anyone following this ever moves the stack to a Linux host, the same config silently breaks. The fix there is to add the mapping explicitly to the open-notebook service:

extra_hosts:
  - "host.docker.internal:host-gateway"

That makes the same http://host.docker.internal:11434 URL work on Linux too, so it is worth adding even on Docker Desktop for portability.

One thing you get for free by going this route: models pulled on the host are shared with every other tool on your machine rather than living in a container volume that only open-notebook can see. If you already run ollama for other things, the containerised copy would have been a second full set of weights on disk, which for anything in the 7B and up range is the bulk of the space you were asking about.