Django en Netlify: lo que realmente sucede
Desplegar Django en Netlify es técnicamente posible, pero según un análisis publicado el 27 de mayo de 2026, vas a pasar más tiempo trabajando alrededor de las limitaciones de Netlify que construyendo tu app. La incompatibilidad es arquitectónica: Django necesita un proceso persistente, Netlify sirve archivos estáticos y funciones efímeras.
En 30 segundos
- Django es un framework server-side que requiere proceso persistente, conexiones a base de datos y sesiones. Netlify es una plataforma JAMstack para archivos estáticos y funciones serverless de corta duración.
- Hay dos workarounds populares: serverless-wsgi y static export. Ambos fallan en producción real por cold starts de 2-5 segundos, timeout de 10 segundos y problemas con conexiones a base de datos.
- El panel de administración de Django, las migraciones automáticas y el connection pooling directamente no funcionan en Netlify.
- Las alternativas reales en 2026 son Render, PythonAnywhere, Heroku, DigitalOcean App Platform o AWS con Serverless Framework.
- El único caso donde Netlify + Django tiene sentido es frontend estático en Netlify con la API Django en otro servidor separado.
Hosting es un servicio de infraestructura que permite almacenar y ejecutar sitios web y aplicaciones en servidores conectados a internet. Surgió a mediados de los 1990s como parte de la expansión de la World Wide Web.
¿Se puede desplegar Django en Netlify? La respuesta directa
Django es un framework web Python de arquitectura server-side que corre como proceso persistente, mantiene conexiones abiertas a la base de datos, maneja sesiones de usuario y ejecuta middleware en cada request. Netlify es una plataforma JAMstack diseñada para servir archivos estáticos y correr funciones serverless de vida corta. Esas dos cosas son incompatibles por diseño.
Sí, podés desplegar Django en Netlify. El mismo problema que tienen los desarrolladores al intentar Flask en Netlify aplica acá (son frameworks server-side Python que requieren runtime persistente, y Netlify no lo ofrece). La experiencia en producción es otra historia.
El atractivo es entendible: si ya usás Netlify para tu frontend React o Next.js, parece natural alojar también el backend Django. Una plataforma, una integración con GitHub, un dashboard. El free tier es generoso y el deploy-on-push es cómodo. El problema es que Netlify no fue construida para esto, y los parches disponibles tienen límites muy concretos.
Por qué Django y Netlify son incompatibles a nivel arquitectónico
No es una cuestión de configuración. Es diseño.
Django necesita cosas específicas para funcionar: un servidor WSGI o ASGI corriendo como proceso permanente, conexiones a PostgreSQL con connection pooling, manejo de sesiones que persisten entre requests, el admin panel con su propio conjunto de rutas y autenticación, y ejecución de middleware en cada request entrante. Todo eso asume que hay algo vivo y esperando del otro lado.
Netlify arranca una función, la corre, la mata. Sin estado. Sin persistencia. Sin proceso esperando el próximo request. Cada invocación de una Netlify Function es un contenedor nuevo que nace y muere en segundos. Eso funciona perfectamente para una API REST simple que no tiene estado. Para Django, que construyó toda su arquitectura alrededor de la persistencia, es un problema estructural. Cubrimos ese tema en detalle en explorar otras plataformas de cloud hosting.
Los dos workarounds (y dónde fallan)
Los desarrolladores que intentan este camino terminan en uno de dos lugares:
serverless-wsgi: cold starts y timeouts
La librería serverless-wsgi envuelve tu app Django para que corra dentro de una Netlify Function. En local parece que funciona. Subís a producción y empiezan los problemas.
Los cold starts toman entre 2 y 5 segundos. Para una app que el usuario abre por primera vez en el día, eso es eterno. Pero el problema más grave es el timeout de ejecución de 10 segundos que impone Netlify. Cualquier operación que tarde más que eso, cualquier query compleja, cualquier procesamiento de imágenes, cualquier envío de email sincrónico, falla. Sin excepciones, sin configuración que lo evite.
¿Y la base de datos? Cada invocación de la función abre una conexión nueva. Sin connection pooling real, con tráfico moderado empezás a agotar las conexiones disponibles de PostgreSQL. El límite de conexiones te va a explotar en la cara antes de lo que creés.
Static export con django-distill: solo para sitios de contenido
La otra opción es generar un sitio estático desde Django usando django-distill y servir eso desde Netlify. Técnicamente funciona, pero dejás de tener una app Django. Tenés un generador de HTML estático que alguna vez fue Django.
Sin formularios dinámicos. Sin autenticación real. Sin admin panel. Sin queries en tiempo real. Si tu “app Django” es básicamente un blog con contenido que cambia poco, zafa. Para cualquier otra cosa, es una solución que destruye el propósito de usar Django. Lo explicamos a fondo en solucionar problemas comunes de hosting.
Los problemas críticos que aparecen en producción real
Ponele que decidís ir con serverless-wsgi de todas formas. Estos son los problemas que encontrás:
- Admin panel disfuncional: El panel de administración de Django hace múltiples requests encadenados, carga assets estáticos y asume sesiones persistentes. Con funciones serverless efímeras, la experiencia es rota o directamente inaccesible.
- Agotamiento de conexiones a base de datos: Sin connection pooling, cada request abre y cierra una conexión. Con 50 usuarios simultáneos, PostgreSQL empieza a rechazar conexiones.
- Sin automatización de migraciones: Las migraciones de Django se corren manualmente o como parte del proceso de deploy. En Netlify no hay un hook claro ni un proceso persistente donde ejecutarlas de forma confiable.
- Timeout de 10 segundos, sin excepciones: Netlify corta la ejecución a los 10 segundos. Cualquier operación que tome más tiempo simplemente falla. No hay forma de extender ese límite.
¿Alguien hizo funcionar todo esto en producción a largo plazo? Hay casos aislados para demos o proyectos muy simples. Para apps reales con usuarios reales, los reportes en los foros de Netlify muestran consistentemente los mismos cuatro problemas.
Qué necesita Django que Netlify no tiene
La lista es corta pero no negociable:
- Un servidor WSGI (Gunicorn, uWSGI) o ASGI (Daphne, Uvicorn) corriendo como proceso persistente
- PostgreSQL con connection pooling (PgBouncer o similar)
- Ejecución automática de migraciones en cada deploy
- Colección de archivos estáticos (
collectstatic) integrada al proceso de deploy - Sin límites de ejecución por request (o límites de minutos, no de 10 segundos)
- Variables de entorno persistentes accesibles desde el proceso del servidor
Netlify cubre algunos de estos parcialmente. Cero de ellos completamente.
Alternativas reales para desplegar Django en 2026
Hay opciones buenas, algunas con free tier generoso:
| Plataforma | Free tier | Setup Django | PostgreSQL incluido | Mejor para |
|---|---|---|---|---|
| Render | Sí (con spin-down) | Nativo | Sí (90 días gratis) | Proyectos medianos, hobby |
| PythonAnywhere | Sí (limitado) | Muy fácil | MySQL gratis, PostgreSQL pago | Aprendizaje, proyectos pequeños |
| Heroku | No (desde 2023) | Nativo | Sí (add-on) | Proyectos con presupuesto |
| DigitalOcean App Platform | No | Nativo | Sí | Apps en producción, equipo |
| AWS Lambda + Serverless Framework | Tier generoso | Complejo | RDS separado | Escala alta, equipos con expertise AWS |
Render y PythonAnywhere son los que más se recomiendan para proyectos nuevos en 2026: setup directo, PostgreSQL incluido y documentación específica para Django. Si buscás hosting con soporte hispanohablante y opciones de infraestructura cloud para alojar tu servidor de aplicaciones, donweb.com tiene VPS y cloud servers donde podés correr Django con Gunicorn sin las restricciones de una plataforma serverless.
AWS Lambda con el Serverless Framework es una opción real para equipos que ya saben AWS y necesitan escala, pero el setup es considerablemente más complejo y los mismos problemas de cold start y conexiones de base de datos requieren soluciones específicas (Mangum como adaptador ASGI, RDS Proxy para connection pooling).
Cuándo sí tiene sentido usar Netlify con Django
Hay un caso válido, y es el que probablemente deberías considerar si ya estás en el ecosistema Netlify:
Frontend estático en Netlify + API Django en un servidor separado. Tu React o Next.js va a Netlify, con todas las ventajas que eso trae (CDN global, deploy automático, SSL gratuito). Tu Django corre en Render, DigitalOcean o donde corresponda, sirviendo una API REST o GraphQL. Los dos se comunican via HTTP normal. Ya lo cubrimos antes en estrategias modernas de cloud hosting.
Eso funciona bien porque cada parte hace lo que sabe hacer. Netlify sirve archivos estáticos y maneja el CDN (es para lo que fue construida). Django corre en un entorno que le da lo que necesita. El frontend llama a la API, la API responde, todos contentos.
La arquitectura agrega algo de complejidad operacional (dos plataformas en vez de una, CORS que configurar, dos deploys a coordinar), pero es una complejidad manejable que no te va a explotar en producción.
Errores comunes al intentar este deployment
Confundir “funciona en local” con “funciona en producción”
serverless-wsgi corre perfectamente en tu máquina porque ahí no hay cold starts ni timeouts de 10 segundos. El error es asumir que ese comportamiento local refleja lo que va a pasar en la infraestructura de Netlify. Probá siempre con la función deployada real, con tráfico simulado, antes de decir que funciona.
Usar SQLite en producción sobre Netlify
SQLite es la base de datos por defecto de Django en desarrollo. Las funciones serverless no tienen sistema de archivos persistente entre invocaciones, así que SQLite literalmente desaparece entre requests. Cada request arranca con una base de datos vacía. Es el tipo de bug que no aparece en los tests pero destruye la app en producción.
Ignorar el límite de tamaño del bundle de las funciones
Netlify tiene un límite de 50 MB para el bundle de funciones serverless (descomprimido). Django con sus dependencias (psycopg2, Pillow, Django REST Framework, etc.) fácilmente supera eso. Hay que compilar dependencias específicamente para Amazon Linux y usar capas Lambda si vas por esa vía, lo que agrega otra capa de complejidad. Esto se conecta con lo que analizamos en automatizar deployments con pipelines CI/CD.
Preguntas Frecuentes
¿Se puede desplegar Django en Netlify gratuitamente?
Técnicamente sí, usando serverless-wsgi con el free tier de Netlify Functions. En la práctica, el límite de 10 segundos de ejecución, los cold starts y la falta de connection pooling hacen que la experiencia sea inutilizable para cualquier cosa más allá de una demo muy simple. Para proyectos reales gratis, Render y PythonAnywhere son mejores opciones en 2026.
¿Por qué Django no funciona bien en Netlify?
Django necesita un proceso servidor persistente (WSGI/ASGI) que viva entre requests y mantenga conexiones a la base de datos. Netlify crea y destruye contenedores por cada invocación de función. Esa diferencia arquitectónica hace que el admin panel falle, las sesiones no persistan y las conexiones a PostgreSQL se agoten bajo carga real.
¿Cuáles son las mejores alternativas a Netlify para Django en 2026?
Render es la opción más recomendada para proyectos nuevos: setup nativo para Django, PostgreSQL incluido y deploy automático desde GitHub. PythonAnywhere tiene un free tier útil para proyectos pequeños y aprendizaje. Para producción con mayor control, DigitalOcean App Platform y AWS con Serverless Framework son opciones sólidas según el nivel de expertise del equipo.
¿Cómo despliego Django y uso Netlify al mismo tiempo?
La arquitectura que funciona es: frontend estático (React, Vue, Next.js estático) en Netlify, y Django corriendo como API REST en un servidor separado (Render, DigitalOcean, VPS). El frontend llama a la API via HTTP. Esta separación permite usar las ventajas de Netlify para el frontend sin las limitaciones que impone a Django.
¿Qué es el problema del cold start en Netlify Functions con Django?
Cada vez que una Netlify Function lleva tiempo sin recibir requests, el contenedor se apaga. El próximo request tiene que arrancar un contenedor nuevo, importar Django y todas sus dependencias, y recién entonces responder. Ese proceso toma entre 2 y 5 segundos. Para usuarios que visitan la app por primera vez en el día, ese delay es visible y degradante para la experiencia.
Conclusión
Desplegar Django en Netlify en 2026 sigue siendo un ejercicio de frustración con resultado predecible. No es que Netlify sea mala plataforma, es que fue construida para un caso de uso completamente distinto. Los workarounds existen, los tutoriales abundan, y los posts en Stack Overflow y los foros de Netlify documentan bien por qué cada workaround eventualmente falla en producción real.
Si ya usás Netlify para tu frontend y querés Django para el backend, la arquitectura separada (frontend en Netlify, API en Render o similar) es la opción que te ahorra tiempo y dolores de cabeza. Si arrancás de cero y buscás simplicidad, Render tiene el setup más directo para Django con PostgreSQL en 2026, con un free tier razonable para proyectos en desarrollo.
La lección que se repite en cada hilo de soporte de Netlify sobre Django es la misma: elegí la plataforma según la arquitectura de tu app, no al revés.
