# Docker for Python: A Primer for Shipping AI Agents (2026)
> A Docker for Python primer: what images and containers are, how to write a Dockerfile for an app, and why agents ship in containers — explained simply.
*Source: https://www.infowok.com/docker-for-python-primer/ · Sukhveer Kaur · Published June 22, 2026*
---
The moment an agent tutorial says "now containerise it," a wall of new words shows up: image, container, Dockerfile, base image, layers. If Docker has always been the step you copy-paste and hope, the deploy chapters never quite click. This **Docker for Python** primer explains just enough of it that packaging an agent stops being a ritual and starts making sense.
You don't need to master containers to ship an agent. You need the mental model — what an image is, what a Dockerfile does, and why the order of lines matters — and the rest of any deploy guide reads cleanly. It's a smaller idea than the jargon suggests.
- You can run a Python script from the terminal — new to that? The [Python for AI agents primer](/ai-agents-from-scratch-python-part-0/) covers the basics
- A [virtual environment](/python-virtual-environment-primer/) habit helps the idea click, but isn't required
- **An image is the frozen package; a container is a running copy of it** — build once, run many.
- **A Dockerfile is the recipe:** pick a base image, install dependencies, copy code, set the start command.
- **Layer order matters:** install requirements *before* copying code so edits don't rebuild everything.
- **Agents ship in containers** so the server runs the exact Python and libraries you tested — no "works on my laptop."
## What Docker for Python actually is
**Docker** packages your application together with everything it needs to run — the Python version, every library, the system pieces — into one self-contained unit that behaves identically on any machine. That's the whole pitch: the container that runs on a cloud server is the same one that ran on your laptop, so the gap where "it worked locally" goes to die simply closes ([Docker docs](https://docs.docker.com/get-started/)).
The two words you'll read constantly are **image** and **container**. An *image* is the built, frozen package — a snapshot of your app and its dependencies. A *container* is a running instance of that image. **You build one image and start as many containers from it as you like** — the same way one class spawns many objects. Get that distinction and most Docker confusion evaporates.
Image = the recipe's finished, frozen result. Container = a live copy of it, actually running. You `build` an image once and `run` containers from it.
## The Dockerfile: a recipe for your app
A **Dockerfile** is a plain text file of steps Docker follows to build your image. For a Python app it's short and almost always the same shape: start from a Python base image, install dependencies, copy your code, say how to start.
```dockerfile
FROM python:3.11-slim # 1. base image: a minimal Python
WORKDIR /app # 2. work inside /app
COPY requirements.txt . # 3. copy the dependency list first
RUN pip install -r requirements.txt # 4. install them
COPY . . # 5. now copy the rest of your code
CMD ["python", "agent.py"] # 6. how to start the container
```
Read it top to bottom and it's just setup steps: pick Python, install packages, add code, run. **`FROM python:3.11-slim` is the key choice** — a small official Python image that keeps your build lean ([Python images](https://hub.docker.com/_/python)). `CMD` is the command that runs when a container starts.
## Why the order of lines matters
This is the one non-obvious bit, and it's the difference between fast builds and painfully slow ones. Docker builds an image in **layers**, one per instruction, and it caches them. If a layer's inputs haven't changed, Docker reuses the cache instead of redoing the work.
That's why `requirements.txt` is copied and installed *before* your code. Your dependencies change rarely; your code changes constantly. **Install dependencies first and Docker caches that expensive layer, so editing `agent.py` only rebuilds the quick final steps** — not a full reinstall every time ([best practices](https://docs.docker.com/build/building/best-practices/)). Flip the order and every one-character code change reinstalls everything.
Two commands cover the basics: `docker build -t my-agent .` builds the image from the Dockerfile in the current folder, and `docker run my-agent` starts a container from it. Add `-p 8000:8000` to expose a port when your agent serves an API.
## Why agents ship in containers
Pulling it together: an AI agent has a precise environment — a Python version, pinned libraries, sometimes system packages for things like database drivers. **A container freezes that exact environment, so the agent on the server runs identically to the one you tested.** That reliability is why every production deploy guide reaches for Docker, and why managed platforms take an image directly.
The [FastAPI, Docker & deploy tutorial](/build-agentic-ai-app-python-part-2/) containerises a real LangGraph agent with the exact Dockerfile shape above, and the [Cloud Run / Fly.io guide](/deploy-ai-agent-cloud-run-flyio/) pushes that image to a managed host. Once you read a Dockerfile as "pick Python, install, copy, run," both stop being walls.
## Quick recap
The whole primer, in five lines:
- **Docker** packages your app + its environment so it runs the same everywhere.
- **Image** = frozen package; **container** = a running copy of it.
- **A Dockerfile** picks a base image, installs deps, copies code, sets the start command.
- **Copy requirements and install before code** so caching keeps rebuilds fast.
- **Agents ship in containers** to guarantee the server matches your tested setup.
## Frequently Asked Questions
**What is Docker?** It packages your app with its exact environment into an image that runs identically anywhere, killing "works on my laptop" bugs.
**Image vs container?** An image is the frozen, built package; a container is a running instance of it. Build one image, run many containers.
**Do I need it to deploy an agent?** Not always, but it's the most reliable path, and managed hosts like Cloud Run and Fly.io take an image directly.
**Why is my image slow to build?** You likely copy code before installing deps. Copy `requirements.txt` and install first, then copy code, and use a slim base.
## Conclusion
Docker for Python is just a way to freeze your app and its environment into an image you can run anywhere, and a Dockerfile is the short recipe that builds it. Read the recipe top to bottom — base image, install, copy, run — and remember to install dependencies before copying code, and the "now containerise it" step in any agent deploy guide turns from a copy-paste ritual into something you actually understand.
**What's the first agent you'd put in a container — a local tool, an API, a scheduled job?** Tell me in the comments.
- **Need a clean local setup first?** The [virtual environments primer](/python-virtual-environment-primer/) covers venv, pip, and uv.
- **Containerise a real agent:** [FastAPI, Docker & deploy](/build-agentic-ai-app-python-part-2/) uses this exact Dockerfile.
- **Skip the server:** [deploy to Cloud Run or Fly.io](/deploy-ai-agent-cloud-run-flyio/) takes your image to a managed host.