Ollama Docker Compose Setup: three containers, one compose file

What mythrantic/ollama-docker actually puts on your machine

Ollama ships as a single binary and a single container image; running it is not the hard part. The hard part is everything around it: a chat UI, a place to keep model weights between restarts, a Python environment with LangChain and ChromaDB if you want to build on top, and a way to reach the daemon from the host. This repository answers that by defining three services in docker-compose.yml.

The ollama service uses docker.io/ollama/ollama:latest and mounts ./ollama/ollama onto /root/.ollama, so downloaded models survive a container restart. The ollama-webui service uses ghcr.io/open-webui/open-webui:main and mounts ./ollama/ollama-webui onto /app/backend/data. The app service is built from the repository's own Dockerfile and runs a FastAPI application from src/main:app.

The audience is someone who wants a local chat endpoint plus a UI on one machine, and who is comfortable reading a Compose file. It is not aimed at cluster operators or at anyone who needs per-user accounts out of the box.

How the three containers talk to each other

All three services join a user-defined bridge network named ollama-docker, declared with external: false at the bottom of the file. Inside that network, containers resolve each other by service name, which is why the app service can list ollama and ollama-webui under depends_on and reach them without an IP address.

The WebUI does not use the service name, though. Its OLLAMA_BASE_URLS is set to http://host.docker.internal:7869, and the service carries an extra_hosts entry mapping host.docker.internal to host-gateway. That means the WebUI reaches Ollama through the host's published port rather than over the Compose network. The ollama service publishes 7869 on the host and maps it to 11434 inside the container, so the two numbers are deliberately different. If you change one, you must change the other, or the WebUI will start but show no models.

Ollama itself runs with OLLAMA_HOST=0.0.0.0 and OLLAMA_KEEP_ALIVE=24h, so the daemon listens on all interfaces and keeps a model resident for a day after the last request. On a machine with limited RAM, that keep-alive setting is what decides whether a second model can load at all.

Installing it and getting to a first chat

The README lists Docker as the only prerequisite, with the NVIDIA Container Toolkit as an optional extra for GPU users. Clone the repository and change into it:

git clone https://github.com/mythrantic/ollama-docker.git
cd ollama-docker

If you have a working NVIDIA setup, the README points at a separate compose file:

docker compose -f docker-compose-ollama-gpu.yaml up -d

Without a GPU, the plain file is used:

docker compose up -d

After the containers come up, the README says to open http://localhost:8080 for Ollama-webui. Model installation happens in the interface rather than the shell: navigate to settings, then model, and install one, with llava-phi3 given as the example. The README notes this can take a couple of minutes, which is the download time for the weights.

The app service is separate from the chat path. It builds from the repository Dockerfile, exposes 8000 and 5678, and runs uvicorn with --reload against the mounted source directory. Port 5678 is the debugpy port listed in requirements.txt, so the container is set up for attaching a debugger, not for production traffic.

GPU support and the AMD question

The README's GPU section is about the host, not the compose file. It gives the NVIDIA Container Toolkit install sequence for Debian and Ubuntu: fetching the GPG key, adding the repository list, installing nvidia-container-toolkit, running nvidia-ctk runtime configure --runtime=docker, restarting Docker, and finally testing with docker run --gpus all nvidia/cuda:11.5.2-base-ubuntu20.04 nvidia-smi. That last command is the useful part, because it tells you whether the runtime is wired up before you blame the compose file.

What the README does not say is how docker-compose-ollama-gpu.yaml requests the GPU. The file is not reproduced in the README, so the reservation stanza has to be read from the repository itself. There is also no mention of AMD anywhere in the README. The repository topics are docker, docker-compose and ollama, and the only acceleration path documented is NVIDIA. If you are on an AMD card, nothing here tells you whether it will work.

Where this setup gets in your way

The WebUI container is pinned to ghcr.io/open-webui/open-webui:main. That tag moves. A docker compose pull months from now can bring in a different WebUI than the one you started with, and the environment variables this compose file sets are not guaranteed to mean the same thing. There is no version pin to fall back to in the file.

Authentication is off. WEBUI_AUTH is set to False, and WEBUI_SECRET_KEY is the literal string t0p-s3cr3t. Combined with the published ports, that means anyone who can reach port 8080 on the host gets the interface, and anyone who can reach port 7869 gets the raw Ollama API. The README does not discuss this trade-off. For a laptop on a home network it is a reasonable default; for anything reachable from a shared network it is the first thing to change.

The app service also mounts the repository root onto /code and runs uvicorn with --reload. That is a development configuration. The README presents the app container as a place for LangChain experiments and as a devcontainer, and that framing is accurate, but it should not be mistaken for a deployment recipe.

How it compares with running the official Ollama image alone

The obvious alternative is the official Ollama image by itself: docker run with a volume for /root/.ollama and a published port. That gives you the daemon and the CLI, and nothing else. You would then add a UI separately, or talk to the HTTP API directly.

The difference is scope, not capability. This repository does not wrap or modify Ollama in any way; the ollama service is the upstream image with two environment variables set. What it adds is the WebUI container and its configuration, the shared network, and the Python app container with a prebuilt environment containing langchain, langchain-community, chromadb, gpt4all and beautifulsoup4 from requirements.txt.

If you only need the API, the single-container approach is fewer moving parts and one less image to keep current. If you want a chat interface and a Python playground without assembling them yourself, this repository saves that assembly work, at the cost of inheriting its defaults.

Licence, maintenance and what upgrading costs

The README states the project is licensed under the RSOSL, linking to LICENCE.md, and asks for a mention and credit. The repository's licence field reports NOASSERTION, which means the licence could not be matched to a standard identifier. RSOSL is not a licence I can characterise from the README, so read LICENCE.md before you depend on it, particularly if you plan to redistribute the compose files or ship the app container.

The last push to the default branch was on 2026-05-26. The repository is not archived, but that date is roughly four months before today, and there are no releases in the repository. Treat the compose file as something you own once you copy it: the WebUI tag will move, the Ollama image tag is latest, and there is no changelog to tell you what changed between pulls.

The practical upgrade cost is small but not zero. Pulling new images and running docker compose up -d again is the whole procedure, and the model volume at ./ollama/ollama is untouched by that. The risk sits in the WebUI: if a future main image changes how OLLAMA_BASE_URLS is interpreted, the interface will come up empty and the fix is in the compose file, not in Ollama.

Editorial conclusion

Adopt this if you want a browser chat interface in front of a local Ollama daemon without writing Compose yourself, and you accept that the WebUI container is pinned to ghcr.io/open-webui/open-webui:main, which moves. Do not adopt it if you need a hardened multi-user deployment: WEBUI_AUTH is set to False, the WebUI secret key is a literal string in the compose file, and the Ollama port is published beyond the Compose network. Before running it, open docker-compose.yml and confirm the OLLAMA_BASE_URLS value matches how you intend to reach the ollama container on your host; on Linux the host.docker.internal mapping relies on the extra_hosts entry, and that is the first thing to verify if the WebUI cannot list models.

Frequently asked questions

Official sources

1. Issues
2. mythrantic/ollama-docker on GitHub
3. Project website
4. README