python Manage.py RunServer 0.0.0.0:8000 expuesto en Internet con DEBUG=True. La base de datos SQLite en producción. Subidas al repositorio. Tres errores que convierten un prometedor proyecto Django en una fuga de datos pendiente. Se conoce el camino mínimo para una implementación limpia, pero no lo acorte por fatiga.
Django en producción no es más complejo que cualquier otro marco web. Es sobre todo una cuestión de disciplina: separar entornos, subcontratar archivos y nunca confundir lo que funcionó localmente con lo que es aceptable para el público.
Viaje mínimo en siete pasos
| Paso | Comando/acción | Olvidado con frecuencia |
|---|---|---|
| Configuración del producto | Módulo settings/production.py, DEBUG=False | Clave secreta comprometida |
| Básico | PostgreSQL o MySQL | SQLite en producción |
| Estático | collectstatic → nginx/CDN | Estática servida por Django |
| Medios | Almacenamiento de objetos o volumen dedicado | Medios en git |
| WSGI | Gunicorn + enchufe o puerto | servidor de ejecución |
| Apoderado | nginx TLS + encabezados | Sin redirección HTTPS |
| Migración | migrar con copia de seguridad | migrar sin revertir la prueba |
Django en producción significa ya no hacer lo que era práctico a nivel local.
Tipo de pila
Internet → nginx (TLS, estático) → Gunicorn (trabajadores) → Django
↓
PostgreSQL
↓
Redis (caché opcional/apio)
Trabajadores de Gunicorn: regla (2 × CPU) + 1 como punto de partida; ajuste según la memoria y las consultas pesadas.
Variables y secretos
Establezca DJANGO_SETTINGS_MODULE en la configuración de producción. Utilice una SECRET_KEY única por entorno. Enumere explícitamente ALLOWED_HOSTS, sin comodín *. Configure el backend del correo electrónico (SMTP o API transaccional). Agregue CSRF_TRUSTED_ORIGINS si presta servicio a varios dominios. Inyecte las variables a través del host o un archivo fuera del repositorio.
Apio y tareas asincrónicas
Si envía correos electrónicos, inicia exportaciones o procesa webhooks pesados, planifique un broker Redis o RabbitMQ, un trabajador supervisado, monitoreo de tareas fallidas y un trabajador web separado y un trabajador por lotes si la carga lo justifica.
Sin Celery, una exportación CSV de diez mil líneas bloqueará a un trabajador de Gunicorn durante el procesamiento; otros visitantes esperarán. Con Celery, la solicitud HTTP devuelve inmediatamente un ID de tarea; el trabajador por lotes procesa en segundo plano. No es obligatorio desde el primer día, pero planificar Redis desde el principio cuesta menos que refactorizar bajo carga.
Alojamiento: criterios para Django
Un host Django creíble permite al menos: Python 3.x con virtualenv o contenedor, PostgreSQL accesible (idealmente administrado), implementación SSH o Git y suficiente RAM para los trabajadores de Gunicorn y Celery si es necesario. Evite la tenencia múltiple sin acceso WSGI: no controlará Gunicorn ni las variables de entorno.
Python PaaS (alwaysdata, Clever Cloud, Platform.sh) simplifica la primera implementación al encapsular Gunicorn, TLS y, a veces, PostgreSQL administrado. Un VPS requiere más configuración inicial pero ofrece más control: elección de arquitectura, no calidad intrínseca.
Lista de verificación posterior a la implementación
Después de ponerlo en producción, verifique: redirección HTTPS forzada, encabezados de seguridad (HSTS). Esta lista de verificación demora treinta minutos; evita incidentes que duran los fines de semana.
La cumbre: Django prod es aburrido por diseño
Consulte Hosting Node.js para conocer la cultura de proceso largo: los principios de proxy más trabajador son similares.
Decide y avanza sin puntos ciegos
Cree un módulo de producción de configuración independiente y no permita "DEBUG=True" en producción. Actualice a PostgreSQL con copias de seguridad probadas periódicamente. Configure nginx plus Gunicorn en systemd o equivalente. Integre Collectstatic en el proceso de implementación. Supervise los errores 5xx y el espacio en el disco multimedia. Explore los hosts de Python en el directorio.
Preguntas frecuentes
¿Puede Django ejecutarse sin Gunicorn?
No en producción: Gunicorn, uWSGI o ASGI detrás de un proxy inverso. El servidor de desarrollo integrado no está diseñado para tráfico público.
¿Dónde servir estática y multimedia?
Estático a través de nginx o CDN después de Collectstatic; medios a través del almacenamiento de objetos o un volumen de copia de seguridad dedicado.
¿Debería ser necesario el apio desde el principio?
De tareas asincrónicas; de lo contrario, pospóngalas con Redis planificado si sabe que está sucediendo.
¿Qué host para una primera aplicación Django?
PaaS Python o VPS con PostgreSQL administrado. Evite el multiinquilino sin el control de WSGI.
Un Django en producción no puede ser reconocido por su URL; puede ser reconocido por la ausencia de "runserver" en "ps aux".