Hosting Django i Python, bez stawiania serwera.

1. Django es el framework para quienes quieren controlar su servidor

Django se diseñó desde el principio pensando en un control total de la capa de datos, la autorización y la estructura del proyecto. Esto atrae de forma natural a desarrolladores que buscan ese mismo control sobre el entorno donde se ejecuta la aplicación, no solo sobre el código Python.

En Saplo, al desplegar una aplicación Django 5.x, eliges la versión de Python (3.11 o 3.12, 3.12 por defecto). La configuración del host virtual de nginx y de gunicorn como servidor WSGI es automática, así no tendrás que escribir desde cero los archivos de configuración de systemd o nginx.

El manifiesto declara un mínimo de 256 MB de RAM. Es un umbral bajo, pero las aplicaciones Django reales con ORM, sesiones y middleware rara vez rinden cómodamente con menos de 2 GB de RAM, especialmente con varios usuarios simultáneos. Por eso, Box M es el mínimo práctico para algo más que un prototipo.

2. SSH, migraciones y gestión de la aplicación desde el terminal

Desde Box M, el acceso SSH completo con sudo permite ejecutar directamente desde el terminal las operaciones estándar de Django: manage.py migrate, manage.py collectstatic y manage.py createsuperuser. No necesitas un panel de administración del hosting aparte que no entienda los comandos de Django.

Git deploy actualiza el código de la aplicación con cada push a la rama configurada. Pero las migraciones de la base de datos y otros pasos de despliegue, como reiniciar el proceso de gunicorn o recopilar los archivos estáticos, aún requieren ejecutar comandos manualmente por SSH. Para un desarrollador que conoce Django, es un paso estándar y conocido.

Celery y las tareas en segundo plano, como recordatorios, envío de correos o procesamiento de trabajos en cola, pueden desplegarse como un proceso separado en el mismo contenedor con una configuración adecuada de systemd. En aplicaciones Django con tareas asíncronas, esto suele ser un elemento estándar de la arquitectura. Conviene entonces supervisar por separado el consumo de memoria del proceso web y del worker de Celery, porque ambos compiten por el mismo límite de RAM asignado al contenedor de la aplicación en ese Box, especialmente cuando hay muchas tareas de Celery ejecutándose en paralelo en segundo plano.

3. Base de datos para Django

Django utiliza de forma predeterminada una base de datos relacional. En Saplo, Postgres y MySQL están disponibles como módulos de base de datos independientes que se despliegan como contenedores con tu propia configuración de Compose, sin añadir complementos de pago con una tarifa separada del hosting de la aplicación.

Para proyectos que necesitan Redis, por ejemplo como broker de Celery o caché de sesiones, hay un módulo Redis independiente que puedes desplegar en el mismo Box que la aplicación Django, sin conectarte a un servicio Redis externo fuera de la infraestructura de Saplo.

4. Django frente a las plataformas PaaS para Python

Las plataformas PaaS especializadas en Python suelen facturar por instancia o según los recursos consumidos por hora, con precios en dólares. Con tráfico real de producción en Polonia, esto complica la planificación del presupuesto en PLN y deja la factura expuesta a las fluctuaciones del tipo de cambio.

En Saplo, el precio es fijo y anual, se expresa en PLN y no depende de cuántas solicitudes por segundo gestione la aplicación en cada momento. Para un proyecto con tráfico irregular (por ejemplo, una aplicación interna de la empresa que solo se usa durante el horario laboral), esto resulta más sencillo de estimar que la facturación por recursos por hora.

5. Para quién es ideal

Para un desarrollador que crea una aplicación web o un sistema interno para la empresa con Django, Box M con SSH completo te ofrece un entorno de producción listo para ejecutar migraciones y configurar la aplicación sin montar un servidor desde cero.

Para un equipo que desarrolla una aplicación de mayor envergadura con Celery, Redis y una base de datos independiente, Box L ofrece RAM suficiente para varios procesos concurrentes en un mismo contenedor o para alojar además módulos de base de datos independientes.

Para una agencia que desarrolla sistemas B2B con Django para clientes, un Box puede alojar muchas instalaciones independientes de Django a la vez, cada una en su propio contenedor y con su propia base de datos.

6. Primer despliegue de una aplicación Django en Saplo

Tras desplegar la aplicación Django con la versión de Python elegida, conecta el repositorio Git para que el código se actualice automáticamente con cada push. Después, ejecuta por SSH los comandos manage.py migrate y manage.py createsuperuser para acceder al panel de administración de Django.

Configuras las variables de entorno (SECRET_KEY, cadena de conexión a la base de datos, claves de API externas) en el panel de la aplicación o en un archivo.env dentro del contenedor, de acuerdo con la práctica estándar de configurar Django fuera del repositorio de código.

Si tu aplicación usa Celery para tareas en segundo plano, configura procesos systemd adicionales en el contenedor: el worker y, opcionalmente, beat para las tareas programadas. Ambos usarán Redis como broker, desplegado como un módulo independiente en el mismo Box.

Configura los archivos estáticos (collectstatic) en el nginx virtual de Box para que el proceso gunicorn no tenga que atender archivos que el servidor web puede servir más rápido y con menor consumo de RAM.

Después del primer despliegue, supervisa por SSH los registros de gunicorn y Django para detectar errores de configuración (por ejemplo, un DEBUG=True olvidado en producción) antes de que la aplicación reciba tráfico real.

7. Django REST Framework y aplicaciones API en Saplo

Las aplicaciones Django desarrolladas como API (Django REST Framework) funcionan en el mismo Box de la misma forma que las aplicaciones clásicas con plantillas, porque la diferencia está en el código de Django, no en la forma de alojamiento de Saplo.

En una API que usa autorización por token, guarda los secretos (claves JWT, claves API de servicios externos) en variables de entorno del contenedor, no en el código del repositorio, como recomienda una buena práctica de seguridad.

Configura CORS y otros encabezados de seguridad en la propia aplicación Django (middleware). El proxy inverso de Saplo deja pasar esos encabezados sin modificarlos, así que la configuración estándar de Django funciona sin pasos adicionales.

Cuando una API da servicio a un frontend integrado en otro dominio (p. ej., una aplicación Next.js en un Box independiente o en un hosting externo), conviene revisar la configuración de ALLOWED_HOSTS y CORS_ALLOWED_ORIGINS en los ajustes de Django.

8. Seguridad de la configuración de Django en producción

El error más habitual al desplegar Django en producción es dejar DEBUG=True. Ante un error de la aplicación, esto muestra al usuario la pila completa de llamadas, junto con variables de entorno y fragmentos de código, lo que supone una fuga grave de información sobre la estructura interna de la aplicación.

El SECRET_KEY que utiliza Django para firmar sesiones y tokens debe ser único para cada despliegue y no debe guardarse en el repositorio de código, sino configurarse como una variable de entorno en la configuración de la aplicación en Saplo, fuera del propio código fuente.

ALLOWED_HOSTS debe contener exactamente los dominios en los que la aplicación está disponible, no un asterisco que permita todos los hosts. Esta es una protección básica contra la inyección de la cabecera Host, especialmente importante en aplicaciones que reciben datos de usuarios de internet.

Conviene separar lógicamente los archivos estáticos y los archivos multimedia subidos por los usuarios (uploads), sirviendo los archivos estáticos de la aplicación mediante nginx y los archivos cargados por los usuarios mediante un mecanismo independiente con los permisos adecuados. Así se evita que un usuario pueda subir y ejecutar un script malicioso en el servidor.

Actualizar Django y los paquetes de Python que uses (requirements.txt) debería ser una práctica habitual. Igual que en el ecosistema de Node.js, las dependencias obsoletas son un vector frecuente de vulnerabilidades conocidas que ya están corregidas y que los escáneres automatizados suelen detectar.

Para las aplicaciones que almacenan datos personales de usuarios, conviene configurar expresamente las opciones de sesión (tiempo de expiración, opciones Secure y HttpOnly de las cookies), algo que Django admite de forma nativa, pero que requiere una configuración explícita en los ajustes del proyecto y no da resultados correctos en todos los escenarios si se usan solo los valores predeterminados. Merece la pena revisar esta configuración junto con la lista completa de ajustes de seguridad de Django antes del primer despliegue en producción, en lugar de descubrir que falta un ajuste solo después de un incidente real de seguridad.

9. El ecosistema de Python y los paquetes que respaldan las aplicaciones Django

Python y Django cuentan con un amplio ecosistema de paquetes (PyPI) que cubren las necesidades habituales de las aplicaciones web: autorización, integraciones con API externas, generación de informes PDF y procesamiento de pagos. Así puedes ampliar tu aplicación con soluciones listas para usar y probadas, sin escribirlo todo desde cero.

En Saplo, el acceso SSH completo con sudo (desde Box M) te permite instalar cualquier paquete de Python mediante el gestor estándar pip, sin las limitaciones que impone la plataforma de hosting. Este enfoque se diferencia de algunos entornos PaaS cerrados que solo admiten una lista limitada de bibliotecas.

La elección entre las extensiones más populares de Django (Django REST Framework para API, Django Channels para WebSockets y Django CMS para gestionar contenidos) depende de ti como desarrollador de la aplicación, sin que el hosting te imponga de antemano restricciones de arquitectura.

Actualizar la versión de Python (de 3.11 a 3.12) está disponible como opción de configuración de la aplicación. Así puedes disfrutar de las nuevas funciones del lenguaje y de las mejoras de rendimiento sin migrar a otro proveedor solo porque necesites cambiar la versión del entorno de ejecución.

Para los equipos que desarrollan aplicaciones Django más complejas (con Celery, Redis y múltiples integraciones externas), el control total del entorno mediante SSH, combinado con los módulos de base de Saplo listos para usar, ofrece una flexibilidad similar a la de un VPS clásico, pero con un tiempo de despliegue más corto para el propio entorno base.

10. Probar las migraciones de la base de datos antes del despliegue en producción

Ejecuta primero en una copia de la base de datos las pruebas de las migraciones de Django que cambien su estructura (añadir una columna, cambiar el tipo de un campo), no directamente sobre la base de datos de producción. Un error en una migración puede provocar la pérdida de datos o dejar la aplicación inaccesible mientras se ejecuta.

Antes de una migración de gran envergadura, la copia de seguridad de Box, disponible desde Box L, ofrece una protección adicional y te permite volver al estado previo a la migración si algo sale mal. No obstante, también es una buena práctica crear manualmente una copia independiente de la base de datos justo antes de la propia operación de migración.

Las migraciones irreversibles (por ejemplo, eliminar una columna con datos) requieren una precaución especial, porque, si se produce un error, los datos eliminados solo pueden recuperarse de una copia de seguridad anterior a la migración. Revertir la migración en Django no es suficiente.

Para los equipos que trabajan con la misma base de datos, define un procedimiento claro para ejecutar migraciones en producción (quién, cuándo y después de qué prueba), para evitar que dos personas intenten aplicar migraciones conflictivas al mismo tiempo en la misma base de datos.

El acceso SSH completo con sudo en Saplo (desde Box M) te proporciona todas las herramientas necesarias para ejecutar migraciones de forma segura, pero la disciplina del proceso (prueba, copia de seguridad y solo después la migración de producción) sigue siendo responsabilidad del equipo de desarrollo.

11. Resumen: Django en Saplo para desarrolladores que buscan control

El acceso SSH completo con sudo, la elección de la versión de Python y la configuración lista de gunicorn y nginx te ofrecen exactamente la combinación de control y comodidad que buscas al desplegar una aplicación en producción: los comandos estándar de manage.py funcionan como deberían y toda la capa del servidor que los rodea ya está preparada, así que no tienes que montarla desde cero en cada proyecto nuevo de Django. Para los equipos que gestionan varios proyectos de Django a la vez, esta configuración reproducible significa que cada proyecto nuevo arranca con la misma rapidez que el primero, sin repetir los mismos pasos de configuración del servidor, ya conocidos. En la práctica, también deja menos margen para pequeñas diferencias de configuración entre proyectos, difíciles de detectar y que en servidores montados por cuenta propia suelen provocar errores de producción poco evidentes.