Hosting VPS para Django

Un VPS para Django es un servidor que ejecuta tu aplicación con herramientas de producción en lugar de runserver, que la propia documentación de Django considera no apto para producción. En un VPS de GreenGeeks eso significa Gunicorn ejecutando la aplicación bajo systemd, Apache 2.4 delante para HTTPS y archivos estáticos, y MariaDB 11.4 en la misma máquina. Tú eliges la versión de Python, la base de datos y los workers en segundo plano como Celery, y todos comparten un solo servidor. El equipo gestionado mantiene el sistema operativo actualizado y monitorizado. Tu código, tu virtualenv y tus actualizaciones de Django corren de tu cuenta.

Elige el tamaño según los workers de tu servidor de aplicaciones, tu base de datos y las tareas de Celery. La regla de Gunicorn es 2 workers por núcleo de CPU más 1, y su documentación añade que de 4 a 12 workers suelen bastar para mucho tráfico. El plan de 4 GB tiene 4 núcleos vCPU y basta para una aplicación con MariaDB. El plan de 8 GB tiene 6 núcleos y deja espacio para Celery y Redis. El plan de 16 GB es adecuado para WebSockets o varias aplicaciones en un servidor. Por defecto, Celery inicia un proceso worker por núcleo de CPU, así que reduce ese número cuando tus workers web compartan los mismos núcleos.

Una aplicación con MariaDB cabe en el plan de 4 GB por $69.95 al mes, y Django en sí es gratuito bajo su licencia BSD. MariaDB, Redis y tus workers de Celery van en esa misma factura, sin importar cuántos ejecutes. Un PaaS cobra cada pieza por separado. En Render, un servicio web de 4 GB cuesta $85 al mes, y Postgres empieza en $6 al mes por 256 MB de RAM. Allí cada worker en segundo plano también es un servicio facturado aparte. El servicio web gratuito de Render se duerme tras 15 minutos sin tráfico, y sus bases de datos Postgres gratuitas caducan a los 30 días.

Usa Gunicorn solo para Django síncrono estándar, y añade Uvicorn cuando sirvas vistas asíncronas por ASGI. Para ASGI, la documentación de Django ejecuta Gunicorn con la clase de worker de Uvicorn, gunicorn myproject.asgi:application -k uvicorn_worker.UvicornWorker, de modo que Gunicorn sigue encargándose de la supervisión y los reinicios de los procesos. En el VPS de GreenGeeks lo inicias con systemd, con Apache delante. Si tu proyecto usa Django Channels para WebSockets, Daphne es el servidor oficial, y ejecutas aproximadamente un proceso de Daphne por CPU. En todos los casos, Apache se queda delante y gestiona HTTPS.

MEDIA_ROOT va primero, porque Django no puede reconstruir los archivos que suben tus usuarios. Añade un mysqldump nocturno con --single-transaction, que copia MariaDB sin bloquear la aplicación. Guarda tu archivo env junto a él, ya que ahí está SECRET_KEY. Omite STATIC_ROOT, porque collectstatic lo reconstruye, y tu código ya está en git. GreenGeeks no guarda copias de seguridad de tu VPS, así que programa la tarea con cron y envía cada copia fuera del servidor, por ejemplo a Amazon S3. Después, prueba una restauración en una base de datos de pruebas.

Django necesita Python, un servidor de aplicaciones y una base de datos, y sus versiones tienen que ser compatibles. Django 6.0 y 6.1 necesitan Python 3.12 o superior, mientras que Django 5.2 LTS funciona con 3.10 a 3.14. AlmaLinux 9 trae Python 3.9 como Python del sistema, que ningún Django con soporte acepta, así que instala python3.12 con dnf. En cuanto a la base de datos, Django 6.1 necesita MariaDB 10.11 o superior, y el VPS de GreenGeeks usa la 11.4. PostgreSQL en el VPS de GreenGeeks es la versión 9.6, y Django 6.1 necesita la 15 o superior, así que usa MariaDB o SQLite.

Sí, y no hay un límite fijo. Depende del tamaño del plan, del tráfico de cada sitio y de lo que más se ejecute en el servidor. Dale a cada proyecto su propio virtualenv, su propio servicio de Gunicorn y su propia configuración de sitio en Apache, para que un fallo o una actualización en uno no afecte a los demás. Cada uno puede tener su propia base de datos y usuario de MariaDB, creados en cPanel. Eso sí, los workers de todas las aplicaciones comparten los mismos 4 a 6 núcleos vCPU. La regla de 2 por núcleo de Gunicorn se aplica a cada aplicación, así que empieza con menos cuando varias aplicaciones funcionen a la vez.

Ejecútalo como indica la propia guía de despliegue de Gunicorn, con Gunicorn bajo systemd y un servidor web delante. Docker no está disponible en el VPS de GreenGeeks, así que herramientas de contenedores como Coolify y Dokku quedan descartadas. Crea un virtualenv con Python 3.12 e instala gunicorn con pip junto con tus dependencias. Una unidad de systemd inicia Gunicorn en 127.0.0.1:8000 con 2 workers por núcleo más 1. Apache 2.4 es el proxy inverso. Pasa las peticiones a Gunicorn mediante una configuración de proxy que escribes tú y sirve STATIC_ROOT por sí mismo. Celery tiene una segunda unidad de systemd.

Tu código se traslada con git. Los datos requieren más trabajo, ya que pasas de PostgreSQL a MariaDB. Un archivo de pg_dump no se carga en MariaDB. Ejecuta manage.py dumpdata en el servidor antiguo y luego migrate y loaddata en el nuevo. Comprueba antes si hay campos exclusivos de PostgreSQL como ArrayField, que MariaDB no puede almacenar. Copia también la carpeta de archivos subidos MEDIA_ROOT, ya que Django no puede reconstruirla. Mueve SECRET_KEY, DEBUG y ALLOWED_HOSTS a un archivo env, ejecuta check --deploy y apunta tu dominio al servidor.

El equipo gestionado trabaja 24/7 en el propio servidor, lo que incluye actualizaciones del sistema operativo, parches de seguridad, monitorización y cPanel. GreenGeeks no da soporte al software que despliegas, así que tu aplicación Django, su virtualenv, Gunicorn, Celery y las actualizaciones de Django corren de tu cuenta. Las fechas de soporte de Django marcan ese calendario de actualizaciones. Django 4.2 dejó de recibir correcciones de seguridad en abril de 2026, la 5.2 LTS tiene soporte hasta abril de 2028 y la 6.2 LTS está prevista para abril de 2027. En la configuración de producción, mantén DEBUG desactivado, carga SECRET_KEY desde el entorno y mantén MariaDB en localhost.