Week 13: Containerization & Deployment

Build the next production-ready layer of your FastAPI service through clear concepts, a focused implementation and a practical exercise.

Module 10 of 12Week 13 of 15~3-4 HoursHands-on Exercise Included

By the end of this week, you'll be able to

  • Small multi-stage Docker images
  • Non-root runtime and environment configuration
  • CI checks and production process models

1. Small multi-stage Docker images

Start with the contract: make inputs, outputs and failure behavior explicit before adding infrastructure. This keeps the feature easy to reason about and gives tests a stable boundary.

2. Non-root runtime and environment configuration

Apply the pattern through a small vertical slice. Keep framework wiring at the edge and business decisions in focused functions or services that can be tested without starting the whole application.

core example
FROM python:3.12-slim AS runtime
WORKDIR /app
RUN addgroup --system app && adduser --system --ingroup app app
COPY --from=builder /app/.venv /app/.venv
COPY app ./app
USER app
CMD ["/app/.venv/bin/uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

3. CI checks and production process models

Treat failure paths as part of the design. Add bounded resource usage, meaningful errors and a verification step so the behavior remains dependable under real production conditions.

4. Hands-on Exercise

Build the feature

Build a non-root image, add a health check, run migrations as a release step, and create a CI pipeline that tests before producing the image.

Definition of done

  • The happy path works through the real HTTP boundary.
  • At least one failure path is handled and tested.
  • Configuration and secrets stay outside source code.
  • The README explains how to run and verify the result.

5. Knowledge Check

Why should migrations not run independently in every web worker at startup?

Show answer

Concurrent workers can race on the schema; a single controlled release step makes migration ordering explicit.