Comment déployer une application FastAPI en production ?

Question

Accepted Answer

FastAPI est une application **ASGI**, donc le déploiement en production utilise un serveur ASGI — typiquement **Uvicorn** (souvent géré par **Gunicorn** pour plusieurs workers), derrière un reverse proxy comme nginx. La conteneurisation (Docker) est l'approche moderne courante.

## La pile de serveur en production

```bash
# ❌ the dev server (with --reload) is NOT for production
uvicorn main:app --reload

# ✅ production: Gunicorn managing multiple Uvicorn workers (uses all CPU cores)
gunicorn main:app -w 4 -k uvicorn.workers.UvicornWorker --bind 0.0.0.0:8000
# -w 4 → 4 worker processes (rule of thumb: ~2 × CPU cores)
```

```text
Client → NGINX (reverse proxy: TLS, static files, load balancing)
           → GUNICORN (process manager) → UVICORN workers (run the ASGI app)
Multiple workers let FastAPI use multiple CPU cores (each worker = one process).
```

## Conteneuriser l'application (courant)

```dockerfile
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["gunicorn", "main:app", "-w", "4", "-k", "uvicorn.workers.UvicornWorker", "--bind", "0.0.0.0:8000"]
```

Un conteneur empaquette l'application et ses dépendances pour un déploiement cohérent sur tous les environnements (puis exécuté sur Kubernetes, ECS, ou une PaaS comme Railway/Render/Fly).

## La checklist de production

```text
1. Config & secrets via environment variables (not in code); validate at startup
2. Multiple workers (Gunicorn + Uvicorn workers) for CPU utilization
3. HTTPS/TLS (at nginx or the platform/load balancer)
4. A real database (PostgreSQL) + connection pooling; run migrations (Alembic)
5. CORS configured to an allowlist (not "*") for browser clients
6. Logging + error monitoring (Sentry) + health-check endpoint
7. A separate worker service (Celery/ARQ) + broker (Redis) for background jobs
8. Horizontal scaling: multiple instances behind a load balancer — keep app STATELESS
   (sessions/state in Redis, not process memory)
```

## Asynchrone et statefulness

```text
✓ Each worker runs its own event loop → workers give parallelism, async gives concurrency
✓ Keep the app STATELESS so you can run many instances behind a load balancer
```

## Pourquoi c'est important

Déployer FastAPI correctement est essentiel pour amener les applications en production, et cela implique des considérations importantes spécifiques à sa nature **ASGI** qui diffèrent de la configuration de développement.

Comprendre la pile de serveur en production est fondamental : le serveur de développement (`uvicorn --reload`) n'est pas pour la production, donc vous exécutez l'application via un serveur ASGI — **des workers Uvicorn gérés par Gunicorn** pour plusieurs processus (utilisant tous les cœurs CPU, puisque chaque worker exécute sa propre boucle d'événements), typiquement derrière nginx pour TLS et l'équilibrage de charge. **La conteneurisation (Docker)** est l'approche moderne courante pour des déploiements cohérents et portables.

Au-delà de la configuration du serveur, la checklist de production couvre des préoccupations critiques de sécurité et de fiabilité : configuration et secrets via des variables d'environnement (jamais dans le code), HTTPS, une vraie base de données avec migrations et pooling, CORS approprié, logging et monitoring, services workers séparés pour les travaux en arrière-plan, et — pour l'évolutivité — exécuter **plusieurs instances sans état** derrière un équilibreur de charge (en gardant l'état dans Redis, pas en mémoire de processus).

Savoir comment déployer FastAPI avec la bonne pile de serveur ASGI, la conteneurisation, plusieurs workers, et le renforcement de production est une connaissance importante au niveau senior, puisque chaque application FastAPI réelle doit être déployée correctement pour être performante, sécurisée et évolutive — rendant ce sujet fréquemment pertinent et professionnellement essentiel pour livrer des APIs de production.