Containerization, Multi-Stage Docker & Security Hardening

An API that runs on your laptop can fail on a server because of a different Python version, a missing system library (libgomp for XGBoost), different package versions, or environment variables you forgot existed.

A Docker image packages everything the app needs — OS libraries, the Python runtime, pinned packages, your code and model — into one immutable artifact. A container is a running instance of that image. The same image runs identically on your laptop, in CI and in production.

Each Dockerfile instruction creates a layer. Docker caches layers and reuses them if the instruction and its inputs haven't changed. Because a change invalidates that layer and every layer after it, order matters:

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .                     # changes rarely
RUN pip install --no-cache-dir -r requirements.txt
COPY app/ app/                              # changes often

With this order, editing your code rebuilds only the last layer (seconds). If you COPY . . before pip install, every code change reinstalls all dependencies (minutes). A .dockerignore keeps .git, .env, notebooks and datasets out of the build context — smaller, faster, and no leaked secrets.

Some packages need compilers (gcc, g++, build headers) to install. Those tools are hundreds of MB and are pure attack surface once the app is built.

A multi-stage build uses a heavy builder stage to compile, then copies only the results into a clean, minimal runtime stage:

FROM python:3.11 AS builder
COPY requirements.txt .
RUN pip wheel --wheel-dir /wheels -r requirements.txt

FROM python:3.11-slim
COPY --from=builder /wheels /wheels
RUN pip install --no-cache-dir /wheels/* && rm -rf /wheels
COPY app/ app/

Typical result: a ~1.2 GB image becomes ~150–200 MB — faster to push, pull and start, and with no compilers for an attacker to use. Base image choice matters too: python:3.11-slim (Debian, glibc) is the safe default; Alpine is tiny but uses musl, so NumPy/XGBoost wheels often must compile from source — slow builds and subtle bugs.

By default a container's process runs as root. If an attacker exploits a vulnerability in your code, a dependency — or a malicious pickle — they get root inside the container, which makes escaping to the host or tampering with mounted volumes much easier.

RUN useradd --create-home appuser
USER appuser
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Other hardening worth naming in an exam: pin base image versions (or digests), scan images for CVEs (Trivy, Docker Scout), keep secrets out of the image (inject them as environment variables at runtime), add a HEALTHCHECK, and keep the image minimal.