¿Cómo despliegas una aplicación FastAPI a producción?

Question

Accepted Answer

FastAPI es una aplicación **ASGI**, por lo que el despliegue en producción utiliza un servidor ASGI — típicamente **Uvicorn** (frecuentemente gestionado por **Gunicorn** para múltiples workers), detrás de un proxy inverso como nginx. La containerización (Docker) es el enfoque moderno común.

## La pila de servidor de producción

```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).
```

## Dockerizar la aplicación (común)

```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 contenedor empaqueta la aplicación y sus dependencias para un despliegue consistente entre entornos (luego ejecutar en Kubernetes, ECS o un PaaS como Railway/Render/Fly).

## La lista de verificación de producción

```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)
```

## Async y sin estado

```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
```

## Por qué es importante

Desplegar FastAPI correctamente es esencial para llevar aplicaciones a producción, e implica consideraciones importantes específicas de su naturaleza **ASGI** que difieren de la configuración de desarrollo.

Comprender la pila de servidor de producción es fundamental: el servidor de desarrollo (`uvicorn --reload`) no es para producción, así que ejecutas la aplicación a través de un servidor ASGI — **workers Uvicorn gestionados por Gunicorn** para múltiples procesos (utilizando todos los núcleos de CPU, ya que cada worker ejecuta su propio event loop), típicamente detrás de nginx para TLS y balanceo de carga. **La containerización (Docker)** es el enfoque moderno común para despliegues consistentes y portátiles.

Más allá de la configuración del servidor, la lista de verificación de producción cubre preocupaciones críticas de seguridad y confiabilidad: configuración y secretos mediante variables de entorno (nunca en código), HTTPS, una base de datos real con migraciones y pooling, CORS adecuado, logging y monitoreo, servicios de worker separados para trabajos en segundo plano, y — para escalar — ejecutar **múltiples instancias sin estado** detrás de un balanceador de carga (manteniendo el estado en Redis, no en memoria de proceso).

Saber cómo desplegar FastAPI con la pila de servidor ASGI correcta, containerización, múltiples workers y endurecimiento de producción es conocimiento importante a nivel senior, ya que toda aplicación FastAPI real debe desplegarse correctamente para ser performante, segura y escalable — haciendo de este un tema frecuentemente relevante y profesionalmente esencial para entregar API de producción.