# Docker and Kubernetes

> How containers with Docker package trading bots and research environments, when Kubernetes helps, and when simpler setups are better for latency and reliability.

Source: https://learn.tradelabsai.com/infrastructure/docker-and-kubernetes/  
Track: Trading Infrastructure · Level: Advanced · Updated: 2026-10-03  
Publisher: TradeLabs AI (https://tradelabsai.com). Education, not financial advice.  
Cite as: TradeLabs Learn, "Docker and Kubernetes", https://learn.tradelabsai.com/infrastructure/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

| Benefit | Example |
|---|---|
| Same environment everywhere | A bot that runs on your laptop runs identically on the server |
| Reproducible research | A backtest can be rerun years later with the same library versions. See [Backtest Reproducibility](https://learn.tradelabsai.com/research/backtest-reproducibility/) |
| Easy deployment | Ship one image instead of installing packages by hand |
| Isolation | Separate bots do not conflict over library versions |
| Rollback | Return to the previous image if a release misbehaves |

## 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](https://learn.tradelabsai.com/infrastructure/redis-and-postgresql-for-trading/).

## What Kubernetes adds

| Feature | What it does |
|---|---|
| Scheduling | Places containers on machines with spare capacity |
| Self healing | Restarts failed containers and moves them off failed machines |
| Rolling deployments | Updates services gradually with rollback |
| Scaling | Runs more copies of a service under load |
| Configuration and secrets | Central management |

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

**Example: Research on demand**
A small quant team runs parameter sweeps that need 200 CPU cores for a few hours a week. Owning that hardware would leave it idle most of the time. Packaging the backtest as a container and running it as jobs on a cloud Kubernetes cluster lets them scale to 200 cores for the sweep and back to almost nothing afterwards. Each job records its image tag, data hash and parameters, so every result can be traced. See [Data Versioning, Lineage and Schemas](https://learn.tradelabsai.com/programming/data-versioning/) and [Parameter Optimization](https://learn.tradelabsai.com/research/parameter-optimization/).

## 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](https://learn.tradelabsai.com/infrastructure/cpu-affinity/) and [Kernel Bypass and Low-Latency Networking](https://learn.tradelabsai.com/infrastructure/kernel-bypass/).

## 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](https://learn.tradelabsai.com/infrastructure/high-availability/) and [Trade Accounting and Reconciliation](https://learn.tradelabsai.com/industry/trade-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](https://learn.tradelabsai.com/infrastructure/message-queues/).

## Continue learning

- Next lesson: [Message Queues](https://learn.tradelabsai.com/infrastructure/message-queues/)
- Previous lesson: [Networking for Traders](https://learn.tradelabsai.com/infrastructure/networking-for-traders/)
- Related: [Networking for Traders](https://learn.tradelabsai.com/infrastructure/networking-for-traders/): The networking basics behind trading: latency and distance, TCP versus UDP, multicast market data, packet loss, jitter and practical ways to improve connectivity.
- Related: [Linux for Traders](https://learn.tradelabsai.com/infrastructure/linux-for-traders/): The Linux skills traders need to run bots on servers: the command line, files, processes, services with systemd, logs, scheduling, SSH security and updates.
- Related: [Fault Tolerance, High Availability and Redundancy](https://learn.tradelabsai.com/infrastructure/high-availability/): High availability keeps trading systems running through hardware, network and software failures. Learn redundancy, failover, avoiding split brain and testing it.
- Related: [Monitoring and Logging Systems](https://learn.tradelabsai.com/infrastructure/monitoring-and-logging-systems/): The tools behind trading observability: structured logs, metrics, dashboards, tracing and alerting with Prometheus, Grafana and log stacks, and how to set them up.
- Related: [Backtest Reproducibility](https://learn.tradelabsai.com/research/backtest-reproducibility/): A reproducible backtest gives the same results every time from the same code and data. Learn version control, data snapshots, research logs and good habits.
- Related: [Data Versioning, Lineage and Schemas](https://learn.tradelabsai.com/programming/data-versioning/): Data versioning tracks exactly which data, code and settings produced each backtest. Learn snapshots, hashes, tools like git and DVC, and a simple workflow.