12.2.3.4 Flask Container

A Flask container packages a Flask application along with its dependencies and a production-appropriate WSGI server, following the general Python containerization pattern while specifically replacing Flask's own built-in development server with something suitable for actual production traffic.

A Typical Flask Dockerfile

The Dockerfile installs dependencies, copies application code, and runs the application through Gunicorn rather than Flask's built-in server.

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "app:app"]

flask==3.0.2
gunicorn==21.2.0

Gunicorn is included as an explicit dependency, specifically for running the application in this container's production context.

Why Flask's Own Development Server Shouldn't Run in Production

Flask's built-in development server, conveniently used for local development via flask run, explicitly warns against production use, lacking the concurrency and robustness Gunicorn provides.

flask run --host=0.0.0.0

This command is appropriate only for local development, not for the container's actual production deployment.

Structuring a Development-Specific Variant

A separate development configuration can use Flask's own development server, with debug mode and auto-reload enabled, appropriate specifically for that local context.

services:
  app:
    build: .
    volumes:
      - .:/app
    command: flask run --host=0.0.0.0 --debug
    environment:
      - FLASK_APP=app.py

Why a Flask Container's Production Configuration Matters

Properly distinguishing between Flask's convenient development server and a production-appropriate WSGI server like Gunicorn is essential for a Flask application's container to function correctly and reliably once actually deployed, rather than relying on tooling explicitly intended only for local development.