Docker Containers Explained: From Development to Production

It’s 2013, and a developer named Solomon Hykes gives a five-minute talk at PyCon. He shows a tool that can package an application and everything it needs to run — its libraries, its configuration, its runtime — into a portable box that runs identically on any machine with Linux. The audience applauds politely. Docker is open-sourced two months later. Within five years, it becomes one of the most influential technologies in the history of software development.

The problem Docker solved had plagued developers for as long as software has existed: “It works on my machine.” Code that runs perfectly on a developer’s laptop fails in staging. Applications that work in staging behave differently in production. New developers spend days setting up local environments that never quite match what runs in the cloud. Entire categories of bugs exist purely because the environments where code runs differ in invisible, hard-to-reproduce ways.

Docker’s answer to this problem is containers — isolated, reproducible runtime environments that package code and all its dependencies into a single artifact that behaves identically everywhere. A container built on a MacBook Pro will run identically on an Ubuntu server in AWS, a Windows workstation, or a Raspberry Pi running ARM Linux. Same behavior. Same dependencies. Same everything.

In 2026, Docker and container technology are not optional knowledge for professional developers — they are foundational. This guide will take you from first principles to production-ready patterns, covering the concepts and commands you need to actually use Docker in real projects, not just understand it abstractly.

Why Docker Changed Software Development Forever

To understand why Docker matters, you need to understand what it replaced. Before containers, deploying software meant one of two approaches:

Manual server configuration: SSHing into a server and installing dependencies by hand. Documenting the steps in a README and hoping the next person followed them correctly. Discovering that production had Python 3.8 when development used Python 3.11, and spending two days tracking down the subtle behavioral difference. This approach was slow, error-prone, and impossible to scale.

Virtual Machines (VMs): VMs solve the consistency problem by virtualizing the entire hardware stack — you package a complete operating system image and run it inside another OS. But VMs are heavyweight. A typical VM image is gigabytes in size and takes minutes to boot. Running 50 isolated services as separate VMs requires 50 copies of a full OS, consuming enormous resources.

Docker containers take a different approach: rather than virtualizing hardware, they virtualize the operating system. Containers share the host OS kernel but have isolated filesystems, processes, and network interfaces. The result is environments that are isolated like VMs but lightweight like processes — a container starts in milliseconds, not minutes, and uses megabytes of overhead, not gigabytes.

This performance characteristic unlocks patterns that were impractical with VMs: running 50 isolated microservices on a single server, spinning up ephemeral test environments for every pull request, deploying code updates by simply replacing containers rather than running update scripts. These patterns are now industry standard, and Docker is the technology that made them practical.

Core Concepts: Images, Containers, and Registries

Docker’s mental model is built around three core concepts. Confusing them is the most common source of beginner mistakes, so let’s define them precisely.

Docker Images: The Blueprint

A Docker image is a read-only template that contains everything needed to run an application: the OS filesystem, application code, libraries, environment variables, and startup commands. An image is built once and can be instantiated into many containers. Think of an image like a class definition in object-oriented programming — it’s the blueprint, not the thing itself.

Images are built in layers. Each instruction in a Dockerfile creates a new layer. Layers are cached and reused, meaning if you change your application code but not your dependencies, Docker only rebuilds the layers that changed. This layered cache is why Docker builds are fast after the first build.

Docker Containers: The Running Instance

A container is a running instance of an image. When you run an image, Docker creates a writable layer on top of the image’s read-only layers and starts the specified process. The container has an isolated filesystem, network interface, and process namespace. Multiple containers can run from the same image simultaneously, each with its own writable state.

The critical insight: containers are ephemeral by design. When a container stops, any data written to its filesystem is lost (unless stored in a volume — more on this later). This ephemerality is a feature, not a bug. It means you can destroy and recreate containers without worrying about state accumulating in unexpected ways. For persistent data, use volumes. For application state, use external databases.

Docker Registries: The Distribution Layer

A registry is a storage system for Docker images. Docker Hub is the default public registry — it hosts hundreds of thousands of community and official images (Ubuntu, Node.js, PostgreSQL, Redis, nginx). Private registries (AWS ECR, Google Artifact Registry, GitHub Container Registry) store proprietary images in your own infrastructure.

The workflow is: build an image locally → push to a registry → pull from the registry on any machine that needs to run it. This is how code gets from a developer’s laptop to a production server without manual file copying or SSH-based deployment scripts.

Writing Your First Dockerfile

A Dockerfile is a text file containing instructions for building a Docker image. Each instruction creates a layer. Let’s build a real-world Python web application image step by step:

# Start from an official Python runtime as the base image
FROM python:3.12-slim

# Set the working directory inside the container
WORKDIR /app

# Copy dependency files first (for better layer caching)
COPY requirements.txt .

# Install Python dependencies
RUN pip install --no-cache-dir -r requirements.txt

# Copy the rest of the application code
COPY . .

# Create a non-root user for security
RUN useradd --create-home appuser && chown -R appuser /app
USER appuser

# Tell Docker what port the app uses (documentation only)
EXPOSE 8000

# Command to run when container starts
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Several important decisions are embedded in this Dockerfile that matter for production:

python:3.12-slim instead of python:3.12: The slim variant removes documentation, test files, and other non-essential components, reducing image size from ~900MB to ~130MB. Smaller images build faster, transfer faster, and have a smaller attack surface.

Copying requirements.txt before the application code: Docker rebuilds only the layers that changed and all subsequent layers. By copying dependencies before source code, the expensive pip install step is cached as long as requirements.txt hasn’t changed — even if application code changed. This makes iterative builds much faster.

Running as a non-root user: By default, processes in containers run as root. This is a security risk — if an attacker exploits a vulnerability in your application, they get root access inside the container. Creating a non-root user and switching to it is a minimal-effort security improvement with meaningful impact.

Build and run this image:

# Build the image, tagging it as "myapp:latest"
docker build -t myapp:latest .

# Run the container, mapping host port 8080 to container port 8000
docker run -p 8080:8000 myapp:latest

# Run in detached mode (background)
docker run -d -p 8080:8000 --name myapp myapp:latest

# View running containers
docker ps

# View container logs
docker logs myapp

# Stop the container
docker stop myapp

Docker Compose: Multi-Container Applications

Real applications don’t run in isolation. A web application typically needs a database, a cache, perhaps a background worker, maybe a reverse proxy. Running and connecting these services manually with docker run commands becomes unmanageable quickly. Docker Compose is the solution: a tool that defines and runs multi-container applications using a single YAML configuration file.

Here’s a real-world docker-compose.yml for a FastAPI application with PostgreSQL and Redis:

services:
  # The web application
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgresql://postgres:secret@db:5432/appdb
      REDIS_URL: redis://redis:6379/0
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_started
    volumes:
      - ./src:/app/src  # Mount source for hot reload in development

  # PostgreSQL database
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: appdb
    volumes:
      - postgres_data:/var/lib/postgresql/data  # Persist data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

  # Redis cache
  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data

# Named volumes persist data between container restarts
volumes:
  postgres_data:
  redis_data:

Key patterns in this configuration:

Service discovery by name: Notice that the web service connects to the database using db as the hostname (in DATABASE_URL: postgresql://...@db:5432/...). Docker Compose creates an internal network where each service is reachable by its service name. No hardcoded IP addresses needed.

Health checks with depends_on: Simply declaring depends_on: db only waits for the database container to start — not for PostgreSQL to be ready to accept connections. The condition: service_healthy syntax combined with a health check ensures the web service doesn’t start until the database is actually responding.

Volume mounts for development: Mounting ./src:/app/src means changes to source code on your host machine are instantly reflected inside the container, enabling hot reload without rebuilding the image for every code change.

# Start all services (detached)
docker compose up -d

# View logs from all services
docker compose logs -f

# View logs from a specific service
docker compose logs -f web

# Stop all services
docker compose down

# Stop and remove volumes (WARNING: deletes data)
docker compose down -v

# Rebuild images after Dockerfile changes
docker compose up -d --build

# Run a one-off command in a service container
docker compose exec web python manage.py migrate

Networking: How Containers Talk to Each Other

Docker’s networking model has a few key concepts that trip up developers when they first encounter container networking:

Each container has its own network namespace. When you’re inside a container, localhost refers to the container itself, not the host machine. This catches many developers off-guard: your web server inside a container cannot connect to a database running on the host using localhost:5432. The database is not “local” from the container’s perspective.

Docker Compose creates a default network. All services in a docker-compose.yml file are automatically connected to a shared bridge network, where services can reach each other by service name. The web service connects to db using hostname db, not localhost.

Port publishing exposes containers to the host. The ports: - "8000:8000" syntax publishes container port 8000 on host port 8000. Without this, the service is only accessible from within the Docker network, not from your browser on the host machine.

Internal services should NOT publish ports in production. Your database container doesn’t need to be reachable from outside Docker in production — only your web application needs external access. Omitting port publishing for internal services (databases, caches, workers) reduces attack surface significantly.

Persistent Data with Volumes

Containers are ephemeral — when a container is removed, its writable layer disappears. Any data written directly to the container filesystem is lost. For databases, file uploads, configuration, and any other data that needs to survive container restarts, you need volumes.

Docker provides two persistence mechanisms:

Named volumes are managed by Docker and stored in Docker’s storage area on the host (typically /var/lib/docker/volumes/). They are the recommended way to persist database data, because Docker manages their lifecycle independently of any particular container. In the Compose example above, postgres_data and redis_data are named volumes.

Bind mounts map a specific directory on the host machine to a path inside the container. The ./src:/app/src mount in the development configuration is a bind mount. Changes on the host are immediately visible inside the container. Bind mounts are ideal for development (live code reload) but less suitable for production because they introduce a dependency on the host filesystem structure.

# List all volumes
docker volume ls

# Inspect a named volume (shows where data is stored on host)
docker volume inspect myapp_postgres_data

# Back up a named volume
docker run --rm \
  -v myapp_postgres_data:/data \
  -v $(pwd):/backup \
  alpine tar czf /backup/postgres_backup.tar.gz /data

# Remove unused volumes (careful — this deletes data!)
docker volume prune

Production Best Practices: What Changes When You Go Live

A Docker setup that works perfectly in development can still fail in production in unexpected ways. The gap between “it runs in Docker” and “it runs reliably in production Docker” involves several important practices:

Multi-Stage Builds: Separating Build from Runtime

Many applications require build tools that are not needed at runtime — compilers, test frameworks, build system dependencies. Multi-stage builds let you use a heavy build environment to produce artifacts, then copy only those artifacts into a minimal runtime image:

# Stage 1: Build stage (can be large)
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build  # Produces /app/dist

# Stage 2: Production runtime (minimal)
FROM node:20-alpine AS production
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev  # Only production dependencies
COPY --from=builder /app/dist ./dist  # Copy only build output
USER node
EXPOSE 3000
CMD ["node", "dist/server.js"]

The final image contains only the Node.js runtime, production dependencies, and compiled output — not the TypeScript compiler, dev dependencies, or source files. This can reduce image size from 1GB+ to under 200MB.

Never Put Secrets in Images

One of the most common security mistakes is embedding credentials, API keys, or passwords in a Dockerfile or in the image itself. Docker image layers are readable by anyone with access to the image — even if you add the secret in one layer and delete it in another, the secret remains in the intermediate layer’s history.

# WRONG: Secret baked into image
ENV API_KEY=sk-super-secret-key-12345

# RIGHT: Pass secrets at runtime as environment variables
# In docker run:
docker run -e API_KEY="${API_KEY}" myapp

# In Docker Compose with an .env file:
# .env file (never commit this to git):
# API_KEY=sk-super-secret-key-12345

# docker-compose.yml:
# environment:
#   API_KEY: ${API_KEY}  # Reads from .env file

Container Health Checks in Production

In production environments with container orchestration (Kubernetes, Docker Swarm, AWS ECS), the orchestrator needs a way to know if your container is healthy. Without a health check, the orchestrator assumes the container is healthy as long as the process is running — even if the application is responding to every request with 500 errors.

HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
  CMD curl -f http://localhost:8000/health || exit 1

Your application should expose a /health endpoint that returns HTTP 200 when the application is ready to serve requests and can connect to its dependencies. The orchestrator will restart unhealthy containers and route traffic away from them.

Resource Limits

Without resource limits, a misbehaving container can consume all available memory or CPU on a host, starving other services. Always set memory and CPU limits in production:

services:
  web:
    image: myapp:latest
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"
        reservations:
          memory: 256M
          cpus: "0.5"

Common Patterns: Web App, API + Database, Worker Queue

Pattern 1: Web App with Nginx Reverse Proxy

In production, it’s standard to run a reverse proxy (nginx or Caddy) in front of your application. The proxy handles SSL termination, static file serving, request buffering, and load balancing — leaving your application server to focus on business logic.

services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - ./certs:/etc/nginx/certs
    depends_on:
      - web

  web:
    build: .
    # Note: NO ports published — only nginx reaches this container
    expose:
      - "8000"

Pattern 2: Background Worker with Celery and Redis

Long-running tasks (sending emails, processing images, generating reports) should not block HTTP request handlers. The standard pattern is to queue these tasks and process them asynchronously with a worker process:

services:
  web:
    build: .
    command: uvicorn main:app --host 0.0.0.0 --port 8000

  worker:
    build: .  # Same image, different command
    command: celery -A tasks worker --loglevel=info
    depends_on:
      - redis
      - db

  redis:
    image: redis:7-alpine

  db:
    image: postgres:16-alpine

The web and worker services share the same Docker image but run different commands. This is a common pattern for Python applications — one image, multiple process types, all defined in a single Compose file.

Debugging Containers: When Things Go Wrong

Every Docker developer accumulates a toolkit of debugging commands. These are the most useful:

# Open an interactive shell inside a running container
docker exec -it container_name bash
# or if bash isn't available (Alpine-based images):
docker exec -it container_name sh

# Inspect container details (env vars, mounts, network settings)
docker inspect container_name

# View real-time resource usage (CPU, memory, network I/O)
docker stats

# Check what files are different from the base image
docker diff container_name

# Start a stopped container to investigate its state
docker start -ai container_name

# Run a debugging container with access to all host namespaces
docker run -it --rm --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh

# Build with verbose output (shows each layer build step)
docker build --progress=plain .

# Check why a layer is cache-busting (useful for slow builds)
docker history myapp:latest

The most common debugging scenario: a container exits immediately after starting. The fix is to run it interactively to see the error:

# Override the CMD to drop into a shell instead of running the app
docker run -it --rm myapp:latest bash

# Or check the logs of an exited container
docker logs container_name

From Development to Production: The Mental Model

Docker’s power lies not in any single feature but in the consistency it creates across the full software delivery lifecycle. The same image that runs on a developer’s laptop is the one that gets tested in CI and deployed to production. The environment — the OS, the libraries, the configuration structure — is defined once in a Dockerfile and reproduced exactly everywhere.

The mental model shift that Docker enables is treating infrastructure as code. Your Dockerfile is a precise, version-controlled specification of your application’s runtime environment. Your docker-compose.yml is a precise, version-controlled specification of how your services connect. Both live in your repository, reviewed in pull requests, and reproduced identically by any developer on the team in five minutes with docker compose up.

This consistency eliminates entire categories of bugs, dramatically simplifies onboarding, and makes the deployment pipeline reliable in ways that manual server configuration never could be. It’s why Docker adoption grew from zero to ubiquitous in less than a decade — it solved real problems that developers faced every day, with a tool that was actually pleasant to use.

The path from here to production-ready containers is straightforward: learn the Dockerfile instructions, understand Compose networking, master the debugging commands, and apply the production best practices. The concepts are few and the payoff is large. Start with a single application, containerize it, and experience firsthand why Solomon Hykes’ five-minute PyCon demo changed an industry.

References

• Docker Official Documentation — docs.docker.com
• Docker Dockerfile Best Practices
• Docker Compose File Reference
• OWASP Docker Security Cheat Sheet
• Kane, Sean P. and Karl Matthias. Docker: Up and Running, 3rd Edition. O’Reilly Media, 2023.
• Docker Awesome Compose — Official Sample Applications
• Aqua Security. “Docker Security Best Practices.” Aqua Security Blog, 2024.