Docker is useful when you need a repeatable Ollama runtime and a model volume that survives container replacement. It does not supply authentication, GPU compatibility or a production availability guarantee. Start with the CPU deployment below, verify networking, then add GPU access if your host supports it.

For native installation use the Ollama foundation. The local inference hub separates container deployment from editor integration and serving-engine selection.

A persistent, single-host deployment

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama_data:/root/.ollama \
  ollama/ollama
curl --fail http://127.0.0.1:11434/api/tags

The unqualified image is a bootstrap example. For a repeatable deployment, record and pin the image digest you validate, alongside model identifiers and driver versions. The loopback mapping deliberately avoids publishing an unauthenticated API to every host interface.

Replace MODEL_NAME with an exact supported tag:

docker exec ollama ollama pull MODEL_NAME
docker exec ollama ollama list
docker exec ollama ollama run MODEL_NAME
docker logs --tail 100 ollama

The named volume is the persistent model store. Back it up according to your recovery needs. Removing the container is different from removing the volume; do not use docker compose down -v as routine troubleshooting.

Know which localhost you mean

Caller	Endpoint for this setup
Host process	http://127.0.0.1:11434
Service sharing a Compose network	http://ollama:11434 when the service is named ollama
Another machine	Not exposed; add a controlled access layer first
Container contacting a native host installation	Platform-specific host networking; not the container’s localhost

For two containerized services, prefer a shared private Docker network. Do not expose the backend to solve a UI routing mistake. The Open WebUI guide gives that two-service layout without duplicating the model server on the host.

Add GPU access only after the host works

On a supported NVIDIA Linux host, verify the driver first with nvidia-smi, then install/configure the NVIDIA Container Toolkit for that distribution. Restarting Docker can disrupt other workloads; schedule it rather than doing it blindly.

A separate GPU container would add --gpus all to the run command. Do not start it with the same container name or published port while the CPU example is still running. AMD ROCm uses a different image and device mappings in the official Ollama Docker instructions. Native macOS GPU support should not be assumed to pass through a Docker Linux VM.

Inspect docker exec ollama ollama ps after generating a response. Host GPU visibility alone does not prove the container or model used it. For a failure at that boundary, follow GPU detection diagnosis.

Upgrade with a recovery path

Record the old image digest, volume mount and model list. Validate the new version against a small known request before reconnecting clients. A rollback may also require compatible persisted data; keeping an old image is not a complete backup strategy.

For shared use, add authentication, TLS, per-client limits, cancellation and monitoring outside the raw local API. Watch host memory as well as VRAM: context and concurrent requests can cause allocation failures even when a downloaded model fits.

If connectivity fails, inspect container status, logs and the caller’s network namespace. If the API responds but a model is absent, use model lookup troubleshooting, not firewall changes.

Sources checked November 10, 2026: Ollama Docker, local authentication behavior, Docker port publishing. These are deployment instructions, not a claim of hands-on production testing.