// the find
tiangolo/uvicorn-gunicorn-fastapi-docker
Docker image with Uvicorn managed by Gunicorn for high-performance FastAPI web applications in Python with performance auto-tuning.
A Docker base image that wraps FastAPI with Gunicorn managing Uvicorn workers, with CPU-aware auto-tuning of worker count. The README leads with a deprecation notice: Uvicorn now handles multi-worker management natively, so this entire layer of indirection is no longer needed. Worth knowing it existed, not worth adopting it today.
- The author deprecated it honestly and prominently — the README tells you to use plain Uvicorn instead of pretending the image is still relevant.
- The env-var configuration surface (WORKERS_PER_CORE, MAX_WORKERS, WEB_CONCURRENCY, TIMEOUT, etc.) is well-designed and still shows up as a pattern worth copying if you're building your own base image.
- The Alpine warning section is genuinely useful advice that's often ignored — explains concretely why Alpine + pip is a bad combination.
- The /start-reload.sh development mode (single Uvicorn process with live reload, volume-mounted) was a clean pattern for local iteration.
- It's deprecated. The core premise — Gunicorn as a process manager for Uvicorn workers — was made obsolete when Uvicorn added --workers with worker restart support. There's no reason to build on this image for new projects.
- Only supports Python 3.10 and 3.11; 3.12 and 3.13 are missing, so anyone still using this is also stuck on older Python.
- Tight coupling to a single app layout (/app/app/main.py or /app/main.py) with magic auto-detection is convenient until it isn't — the convention breaks the moment your project structure differs and the error messages are opaque.
- The prestart.sh sleep 10 pattern shown in the docs for database migrations is a time-bomb in disguise — fixed sleeps before migrations is the kind of thing that fails in CI and never gets fixed properly.