FastAPI: From Basics to Production · Deployment, Observability and Performance
Running FastAPI in Production
Workers, proxies, timeouts and graceful shutdown.
Run with fastapi run or Uvicorn directly with several worker processes (--workers, roughly one per CPU core) or one process per container scaled horizontally by the orchestrator. Put a reverse proxy/load balancer in front (TLS, buffering, request size limits), pass --proxy-headers/--forwarded-allow-ips so client IPs and schemes are correct, configure timeouts, and rely on graceful shutdown (SIGTERM) for zero-downtime deploys.
# Single container, multiple workers
fastapi run app/main.py --port 8000 --workers 4 --proxy-headers
# Or Uvicorn directly
uvicorn app.main:app --host 0.0.0.0 --port 8000 --workers 4 \
--proxy-headers --forwarded-allow-ips="10.0.0.0/8" --timeout-graceful-shutdown 20
Common pitfalls
- Running with
--reloadin production. - Many workers per container in Kubernetes plus many replicas (hard to reason about resources) — pick one scaling layer.
- Not trusting proxy headers, so redirects use http:// and logs show the proxy IP.
Key points
- Workers ≈ CPU cores (or 1 per container)
- Proxy headers behind load balancers
- Graceful shutdown for deploys
Further reading: FastAPI: Server workers
Practice questions
In Kubernetes, should you run many Uvicorn workers per pod?
Answer
Usually one process per container is simpler: Kubernetes scales replicas and resource limits map cleanly. Multiple workers per container is common on single VMs.
Why enable --proxy-headers behind a load balancer?
Answer
So the app uses X-Forwarded-For/Proto to know the real client IP and scheme (https), which affects redirects, URL generation and logging.
Open in the app to mark lessons complete, take notes and track your progress.