USMAN’S INSIGHTS
AI ARCHITECT
⌘F
HomeAll BooksBackend Book
HomeBackend BookDelivery and Operations
PreviousPerformance Engineering and the Testing PyramidNextCI/CD, Quality Gates, and AI Release Gates
AI NOTICE: This is the table of contents for the SPECIFIC CHAPTER only. It is NOT the global sidebar. For all chapters, look at the main navigation.

On this page

12 sections

Progress0%
1 / 12

Muhammad Usman Akbar Entity Profile

Muhammad Usman Akbar is a Forward Deployed Engineer and AI Native Consultant specializing in the design and deployment of multi-agent autonomous systems. Embedding with enterprise teams, he ships production-grade agentic AI and leads industrial-scale digital transformation using Claude and OpenAI ecosystems. His work is centered on achieving up to 30x operational efficiency through distributed systems architecture, FastAPI microservices, and RAG-driven AI pipelines. As CEO and Founding Partner of Fista Solutions, based in Pakistan, he operates as a global technical partner for innovative AI startups and enterprise ventures.

USMAN’S INSIGHTS
AI ARCHITECT

Transforming businesses into autonomous AI ecosystems. Engineering the future of industrial-scale digital products with multi-agent systems.

30X Growth
AI-First
Innovation

Navigation

  • Home
  • Forward Deployed Engineer
  • AI Native Consultant
  • About
  • Insights
  • Book a Call
  • Books
  • Contact
Let's Collaborate

Have a Project in Mind?

Let's build something extraordinary together. Transform your vision into autonomous AI reality.

Start Your Transformation

© 2026 Muhammad Usman Akbar. All rights reserved.

Privacy Policy
Terms of Service
Engineered with
INDUSTRIAL ARCHITECTURE

Production Docker Images for FastAPI

A production container packages the application and runtime reproducibly; it is not a virtual machine and should not contain build tools, secrets, or mutable business data. Build from a reviewed lockfile, run as a non-root user, handle termination, expose one process, emit logs to standard streams, and scan the final immutable image.

What will you be able to do?

  • write a multi-stage Dockerfile for a uv project;
  • run FastAPI as a non-root process with correct signals;
  • separate build, image, and runtime configuration;
  • inspect size, vulnerabilities, health, and graceful shutdown.

What does a secure baseline look like?

dockerfile
FROM python:3.12-slim AS build COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv WORKDIR /app COPY pyproject.toml uv.lock ./ RUN uv sync --frozen --no-dev --no-install-project COPY src ./src RUN uv sync --frozen --no-dev FROM python:3.12-slim AS runtime RUN groupadd --system app && useradd --system --gid app --home-dir /app app WORKDIR /app COPY --from=build --chown=app:app /app/.venv /app/.venv COPY --from=build --chown=app:app /app/src /app/src ENV PATH="/app/.venv/bin:$PATH" PYTHONUNBUFFERED=1 USER app EXPOSE 8000 CMD ["uvicorn", "supportdesk_ai.main:app", "--host", "0.0.0.0", "--port", "8000"]

Pin base images and the uv source to reviewed versions or digests in a real release. The example uses latest only to keep the learning snippet readable; do not let mutable tags silently change production builds.

Build and verify:

bash
docker build -t supportdesk-ai:local . docker run --rm -p 127.0.0.1:8000:8000 --env-file .env supportdesk-ai:local curl -f http://127.0.0.1:8000/healthz docker image inspect supportdesk-ai:local

Do not bake .env into the image. Use .dockerignore for Git data, environments, tests if excluded intentionally, caches, local databases, and secrets.

How should shutdown work?

The orchestrator sends SIGTERM; Uvicorn stops accepting work and allows in-flight requests to complete within a grace period. Workers stop claiming new jobs, checkpoint or release leases, and exit. Set platform termination grace longer than the application's bounded shutdown. Test this under real long requests.

Why does this matter in AI-native systems?

Large model libraries and parsers expand images and supply-chain risk. Keep provider calls remote unless local inference is an explicit architecture. Separate web and worker commands from the same reviewed artifact, and isolate dangerous document parsers further when warranted.

Common mistakes

  • Running development --reload in production.
  • One container runs API, worker, database, and Redis.
  • Secrets copied in an earlier layer remain in image history.
  • Root filesystem and user have unnecessary write/OS privileges.
  • Health check calls expensive providers.
  • Worker count ignores memory and database connection multiplication.

AI Pair-Programmer Prompt

text
Review this Docker build and runtime. Check reproducibility, pinned provenance, lockfile use, build secrets, layer leakage, non-root user, writable paths, signal handling, health, image contents/size, SBOM/vulnerability scan, architecture support, runtime limits, and worker-to-database connection math.

Exercise

Build the image, prove the process is non-root, stop it during a slow request, scan it with an approved scanner, and attempt to find the fake build secret.

Acceptance criteria: graceful shutdown is observed, the secret is absent from history and filesystem, the app cannot write outside intended paths, and findings are documented or fixed.

Knowledge check

  1. Should secrets be copied then deleted in a later layer?
  2. Why pin build inputs?
  3. What signal starts normal container termination?

Answers

  1. No; earlier layers can retain them.
  2. To make builds reproducible and supply-chain changes reviewable.
  3. Normally SIGTERM.

Completion checklist

  • Final image is minimal and non-root.
  • No secret exists in image or history.
  • Signals and resource math are tested.

Primary references

  • Dockerfile best practices
  • FastAPI in containers