¿Cómo despliegas una aplicación Django en producción?

Question

Accepted Answer

Desplegar Django en producción implica ejecutarlo detrás de un servidor **WSGI/ASGI** adecuado y un **servidor web**, servir archivos estáticos correctamente, asegurar la configuración y gestionar la base de datos — muy diferente del servidor de desarrollo integrado (que **no** es para producción).

## El stack de producción

```text
Client → NGINX (web server) → GUNICORN (WSGI app server) → DJANGO
           │                      (runs your Python app, multiple workers)
           └─ serves static/media files directly (efficient)

❌ NEVER use `python manage.py runserver` in production — it's single-threaded,
   insecure, and not built for load. Use Gunicorn (WSGI) or Uvicorn (ASGI for async).
```

El servidor de desarrollo no es apto para producción. El stack estándar: un **servidor de aplicaciones** (Gunicorn/uWSGI para WSGI, Uvicorn para ASGI/async) ejecuta Django con múltiples workers, detrás de un **servidor web** (nginx) que maneja conexiones entrantes, TLS y archivos estáticos.

## Configuración de producción (crítica para la seguridad)

```python
DEBUG = False                            # ❗ MUST be False — DEBUG=True leaks sensitive info
ALLOWED_HOSTS = ["example.com"]          # required when DEBUG=False
SECRET_KEY = os.environ["SECRET_KEY"]    # from the environment, NOT committed
SECURE_SSL_REDIRECT = True               # force HTTPS
SESSION_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 31536000
```

## Archivos estáticos

```bash
python manage.py collectstatic           # gather static files into STATIC_ROOT
# then serve them via nginx or a CDN — or use WhiteNoise to serve them from the app
# (Django does NOT serve static files itself in production)
```

## Base de datos y migraciones

```bash
python manage.py migrate                  # apply migrations to the production DB
# use a real database (PostgreSQL), connection pooling, regular backups
```

## Una lista de verificación típica de despliegue

```text
1. Set production environment variables (SECRET_KEY, DB credentials, DEBUG=False)
2. Run migrations (manage.py migrate)
3. Collect static files (collectstatic) → serve via nginx/CDN/WhiteNoise
4. Run the app with Gunicorn/Uvicorn (multiple workers, behind nginx)
5. Enable HTTPS (TLS certificates, e.g. Let's Encrypt)
6. Set up logging, error monitoring (Sentry), health checks
7. Add a process manager (systemd/supervisor) or use containers (Docker) + orchestration
8. Run `manage.py check --deploy` to audit security settings
```

## Enfoques modernos de despliegue

```text
✓ Containers (Docker) + orchestration (Kubernetes) or platforms (Heroku, Railway, Render)
✓ Managed databases, separate static/media storage (S3 + CDN)
✓ Background workers (Celery) + a broker (Redis) as separate services
✓ Horizontal scaling: multiple app instances behind a load balancer (keep app STATELESS)
```

## Por qué es importante

Desplegar Django en producción correctamente es conocimiento esencial para llevar aplicaciones del desarrollo al uso en el mundo real, e implica consideraciones importantes que difieren fundamentalmente del desarrollo local — hacer las cosas mal conduce a vulnerabilidades de seguridad, bajo rendimiento o aplicaciones rotas.

Comprender el **stack de producción** es fundamental: el servidor de desarrollo integrado (`runserver`) explícitamente no es para producción (es single-threaded, inseguro y no puede manejar carga), por lo que debes ejecutar Django detrás de un **servidor de aplicaciones** adecuado (Gunicorn/uWSGI para WSGI, o Uvicorn para ASGI/async) con múltiples workers, precedido por un **servidor web** (nginx) que maneja conexiones, TLS y servicio de archivos estáticos.

Varios aspectos son críticos para la seguridad y corrección: **configuración de producción** (especialmente `DEBUG=False`, que es obligatorio ya que `DEBUG=True` filtra tracebacks sensibles y configuración a atacantes, además de `ALLOWED_HOSTS`, una `SECRET_KEY` secreta del entorno y aplicación de HTTPS), **manejo de archivos estáticos** (ejecutar `collectstatic` y servir archivos vía nginx/CDN/WhiteNoise, ya que Django no los sirve en producción — un fallo de despliegue común), y **gestión de base de datos** (una base de datos real como PostgreSQL, aplicar migraciones, copias de seguridad).

Conocer la lista de verificación de despliegue, enfoques modernos (Docker/contenedores, plataformas gestionadas, almacenamiento en la nube para media, workers de Celery como servicios separados, escalado horizontal con una app sin estado) y las preocupaciones operacionales (logging, monitoreo con Sentry, health checks, gestión de procesos) es lo que separa un despliegue de producción funcional de uno frágil o inseguro.

Porque toda aplicación Django real debe eventualmente ser desplegada, y porque los errores de despliegue (dejar `DEBUG=True`, manejo incorrecto de archivos estáticos, exponer secretos, usar el servidor de desarrollo) causan problemas reales de seguridad y confiabilidad, entender cómo desplegar Django correctamente — el stack, la configuración crítica para la seguridad, manejo de archivos estáticos/media y prácticas de despliegue modernas — es conocimiento importante, de alto riesgo que refleja la capacidad de enviar aplicaciones listas para producción, un tema frecuentemente relevante y esencial profesionalmente para cualquier desarrollador de Django responsable de sistemas en vivo.