Run DeepSeek Locally With Docker

Docker can isolate an Ollama runtime and persist DeepSeek model files in a named volume. Bind the API to 127.0.0.1, not every network interface, and use the exact R1 tag you evaluated. Containers improve reproducibility but do not create authentication or make untrusted models safe.

Prerequisites

Install Docker from its official distribution for your operating system and confirm:

docker version

Plan storage before pulling model files. Verify GPU support separately. Docker Desktop on macOS does not provide the same GPU passthrough as Linux; Ollama’s documentation notes that Docker GPU acceleration is unavailable there.

Start a CPU container safely

docker run -d \
  --name ollama \
  --restart unless-stopped \
  -v ollama_models:/root/.ollama \
  -p 127.0.0.1:11434:11434 \
  ollama/ollama

The explicit 127.0.0.1 is important. Docker warns that a bare -p 11434:11434 publishes the port on host addresses and can expose it beyond the machine.

Pull and run a DeepSeek model

docker exec -it ollama ollama pull deepseek-r1:8b
docker exec -it ollama ollama run deepseek-r1:8b

Ollama’s library also lists 1.5B, 7B, 14B, 32B, 70B and 671B tags. Choose by actual storage and memory, not ambition. The 8B tag is a distilled model, not full R1.

Test the API

curl http://127.0.0.1:11434/api/chat \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-r1:8b",
    "messages": [{"role": "user", "content": "Return a two-item JSON array of testing risks."}],
    "stream": false
  }'

Keep the request synthetic until privacy and logging are reviewed. The local endpoint has no authentication by default.

NVIDIA and AMD variants

Ollama’s Docker guide uses --gpus=all after installing NVIDIA Container Toolkit. Its AMD example uses the ollama/ollama:rocm image and device mappings for /dev/kfd and /dev/dri. Hardware, drivers and platform support change; follow the current official commands.

Do not run --privileged just to make a GPU work. Grant only the devices and capabilities required. If acceleration fails, inspect container logs and driver compatibility before widening permissions.

Pin versions and verify images

The latest image can change. For reproducible production work, pin a tested image tag or digest and record the Ollama version. Pin the model digest as well. Scan images according to your organisation’s process.

Update in a staging environment, rerun evaluations and keep a rollback path. A newer model tag can change answers even when the container configuration is identical.

Add resource limits

Containers can consume significant memory and CPU. Use Docker resource controls appropriate to the host, for example a memory limit that leaves room for the operating system. An unrealistic limit will cause loading failures.

Monitor disk use in the named volume. Removing the container does not remove the volume, which protects models during upgrades but can surprise administrators expecting space to be reclaimed.

Secure remote access

Do not change the port binding to 0.0.0.0 and rely on a home router. If another machine must connect, use an authenticated TLS reverse proxy or a private network, restrict source addresses and apply per-user quotas. Keep the Docker daemon socket inaccessible to the application.

Docker daemon access can grant host-level control. Never mount /var/run/docker.sock into an AI agent container. The model does not need to administer Docker to answer prompts.

File access and tools

Do not mount an entire home directory. Create a dedicated read-only input directory and a separate limited output directory when a workflow needs files. Avoid mounting SSH keys, cloud credentials, source-control tokens or production configuration.

For agentic command execution, use an additional sandbox with no host credentials and require confirmation. A model instruction cannot substitute for filesystem isolation.

Logs and data lifecycle

Review docker logs ollama and client logs to understand what is retained. Avoid printing prompt content in application logs. Encrypt disks where appropriate and define how the volume is backed up or deleted.

To remove the container:

docker stop ollama
docker rm ollama

Delete the named volume only when you intentionally want to remove model data and have confirmed the target. Volume deletion is destructive.

Docker versus native Ollama

Docker is useful for reproducible deployment and Linux GPU servers. Native Ollama is often simpler for an individual Windows or macOS user and can provide better platform integration. The model quality is determined by the exact artifact and settings, not by Docker itself.

The Ollama guide covers native commands, while the platform guide compares operating systems.

If self-hosting is unnecessary, the DeepSeek API guide offers a managed alternative with different privacy and billing boundaries. Choose the route from requirements, not from the presence of a container image.

Conclusion

A secure Docker deployment uses an official image, persistent named storage, loopback-only publishing, minimal devices, pinned versions and restricted file access. Treat remote access and agent tools as separate security projects rather than toggles.