Docker and Kubernetes

Containers package an application together with everything it needs to run: the right Python version, libraries and system tools. Docker is the most common tool for building and running containers. Kubernetes is a system for running many containers across many machines, handling restarts, scaling and deployment. In trading, containers make research reproducible and deployments consistent. They also add complexity, and for latency critical systems, some firms avoid them on the trading path itself.

Why containers help traders#

A simple Dockerfile for a Python bot#

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "main.py"]

Build with docker build -t mybot:1.4.0 . and run with docker run -d --restart unless-stopped --env-file .env mybot:1.4.0. The --restart flag restarts the container after crashes or reboots. Keep secrets in environment files or a secrets manager, never inside the image.

Docker Compose for small stacks#

A retail setup often has a bot, a database and a monitoring tool. Docker Compose describes them in one file and starts them together, which suits a single server well. See Redis and PostgreSQL for Trading.

What Kubernetes adds#

Kubernetes shines for research platforms, data pipelines and many services. For one or two bots, it is usually more complexity than needed.

Containers and latency#

Containers on Linux share the host's kernel, so their compute overhead is small. Networking can add overhead depending on configuration, and orchestrators may move or throttle workloads. For latency critical trading, firms often run on dedicated, tuned machines, sometimes with containers using host networking and pinned CPUs, sometimes without containers at all. See CPU Affinity, NUMA and Cache Optimization and Kernel Bypass and Low-Latency Networking.

Stateful trading systems#

Trading bots hold state: positions, open orders and recent data. Orchestrators that restart or move containers freely must be paired with persistent storage and startup reconciliation, so a restarted bot never forgets what it holds. Running two copies of a bot by accident can double orders; use leader election or locks so only one instance trades. See Fault Tolerance, High Availability and Redundancy and Trade Accounting and Reconciliation.

Common mistakes#

1. Secrets baked into images that get pushed to shared registries.
2. Using the "latest" tag, so you do not know which version is running.
3. No resource limits, letting one container starve others.
4. Two bot instances running after a careless redeploy.
5. Over engineering a single bot with a full cluster.

Frequently asked questions#

Should I use Docker for my trading bot?#

It is a good choice for consistent deployments and easy rollback, especially when running several services, though a simple systemd service also works well.

Do trading firms use Kubernetes?#

Many use it for research, data pipelines and internal services; latency critical trading systems often run on dedicated tuned machines instead.

Do containers slow down trading systems?#

Compute overhead is small; networking and orchestration can add latency, which matters only for very latency sensitive strategies.

Next, learn how components pass messages to each other in Message Queues.