Alojar Django en un VPS: Gunicorn, Nginx y ajustes de producción

Si una herramienta de IA ha generado un proyecto Django, la vista previa pública no es el servidor de producción. Un sitio Django dinámico necesita Python y un servidor de aplicaciones; un VPS te permite instalar y mantenerlos a nivel de sistema operativo. Es un despliegue autogestionado: tú te encargas de actualizar el sistema, configurar servicios, proteger secretos y preparar copias de seguridad.

Esta guía usa Debian o Ubuntu, Gunicorn para un proyecto WSGI y Nginx delante. Es una plantilla, no un despliegue probado contra tu repositorio. Sustituye djangoapp, myproject, el dominio y las rutas por los valores del proyecto. Si solo funciona con ASGI, necesita workers o configura los archivos estáticos y subidos de otra forma, adapta el servidor.

1. Revisa el proyecto antes de elegir servidor

Localiza manage.py, requirements.txt o pyproject.toml, y el módulo WSGI/ASGI. Ejecuta la app en local y apunta las versiones de Python y base de datos que requiere. Revisa en los ajustes generados por IA DEBUG, SECRET_KEY, ALLOWED_HOSTS, los orígenes CSRF de confianza, las URL de base de datos, claves de API, archivos subidos y tareas en segundo plano. No subas .env ni secretos de producción a Git.

runserver de Django es para desarrollo, no para producción. Django recomienda un servidor WSGI o ASGI de producción y su lista vigente incluye manage.py check --deploy. Si el proyecto solo genera archivos estáticos, puede encajar en un hosting estático; este recorrido con VPS es para una app que necesita ejecutar Django con cada petición.

2. Prepara un VPS Linux y un usuario separado

Elige un VPS de Hostbrid con imagen Debian o Ubuntu compatible con la versión de Python del proyecto. Conéctate por SSH, instala actualizaciones y abre solo los puertos necesarios. Instala los paquetes del sistema y crea una cuenta de servicio, en vez de ejecutar Django como root:

sudo apt update
sudo apt install git python3-venv nginx
sudo adduser --system --group --home /srv/djangoapp djangoapp

Clona el repositorio en /srv/djangoapp/current con ese usuario. Si el repositorio es privado, utiliza una clave de despliegue de solo lectura y mantén su clave privada fuera del proyecto. Crea un entorno virtual e instala las versiones declaradas por la aplicación:

sudo -u djangoapp python3 -m venv /srv/djangoapp/venv
sudo -u djangoapp /srv/djangoapp/venv/bin/pip install -r /srv/djangoapp/current/requirements.txt

Comprueba que Gunicorn esté declarado como dependencia del proyecto y tenga una versión fijada. No instales paquetes globalmente para esta aplicación.

3. Configura producción y prepara la aplicación

Guarda las variables de producción en un archivo controlado por root y legible por la cuenta del servicio, nunca en Git. Usa los nombres de variables que realmente consuma tu configuración. Genera una clave secreta única; desactiva DEBUG; limita ALLOWED_HOSTS a tus dominios; configura los orígenes CSRF y HTTPS; y facilita las credenciales de la base de datos sin subirlas al repositorio.

Ejecuta estos comandos con el mismo módulo de ajustes de producción y las mismas variables de entorno que usará el servicio. De lo contrario, la comprobación podría revisar los valores de desarrollo y no la configuración real.

Antes de modificar una base de datos en uso, haz una copia y confirma cómo restaurarla. Después, activa el entorno, aplica migraciones, recopila estáticos y ejecuta las comprobaciones de despliegue de Django con los ajustes de producción:

cd /srv/djangoapp/current
sudo -u djangoapp /srv/djangoapp/venv/bin/python manage.py migrate
sudo -u djangoapp /srv/djangoapp/venv/bin/python manage.py collectstatic --noinput
sudo -u djangoapp /srv/djangoapp/venv/bin/python manage.py check --deploy

collectstatic requiere que configures STATIC_ROOT. Mantén los archivos subidos por usuarios separados de los estáticos; define permisos y copias, y trata esas subidas como archivos no confiables.

4. Ejecuta Gunicorn como servicio de systemd

Prueba primero el punto de entrada WSGI desde el directorio del proyecto. Sustituye myproject.wsgi:application por el módulo que contiene el objeto WSGI application de tu app:

cd /srv/djangoapp/current
sudo -u djangoapp /srv/djangoapp/venv/bin/gunicorn --bind 127.0.0.1:8000 myproject.wsgi:application

Cuando funcione, ejecútalo con systemd para que arranque al iniciar el VPS y pueda reiniciarse tras un fallo. Esta unidad mínima usa la ruta WSGI del proyecto y carga el archivo de variables protegido:

[Unit]
Description=Django application
After=network.target

[Service]
User=djangoapp
Group=djangoapp
WorkingDirectory=/srv/djangoapp/current
EnvironmentFile=/etc/djangoapp.env
ExecStart=/srv/djangoapp/venv/bin/gunicorn --bind 127.0.0.1:8000 myproject.wsgi:application
Restart=on-failure

[Install]
WantedBy=multi-user.target

Guárdala en /etc/systemd/system/djangoapp.service; ejecuta sudo systemctl daemon-reload, sudo systemctl enable --now djangoapp y revisa sudo systemctl status djangoapp y journalctl -u djangoapp. Ajusta workers y memoria después de medir los recursos del VPS y la carga de la app.

5. Coloca Nginx y HTTPS delante

Para un proyecto con STATIC_URL igual a /static/ y STATIC_ROOT en /srv/djangoapp/current/staticfiles, una configuración inicial de Nginx puede ser:

server {
    listen 80;
    server_name ejemplo.com www.ejemplo.com;

    location /static/ {
        alias /srv/djangoapp/current/staticfiles/;
    }

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Guarda el sitio en el directorio de configuración de Nginx de tu distribución, actívalo y ejecuta sudo nginx -t antes de recargar Nginx. Deja Gunicorn escuchando en loopback para que no quede expuesto a Internet. Apunta el dominio a la dirección del VPS, permite los puertos 80/443, emite un certificado con el método compatible con tu distribución y fuerza HTTPS antes de aceptar inicios de sesión o datos sensibles. Este bloque HTTP es el punto de partida del proxy, no una configuración HTTPS completa.

Si Django está detrás de un proxy, configura los ajustes de proxy seguro solo para la ruta de proxy que controlas. Prueba la portada, el acceso admin, una ruta interna, los estáticos, formularios e integraciones API. Tras reiniciar, revisa los logs y confirma que no se filtren secretos en el navegador o los registros.

Antes de abrir el sitio

Ejecuta la lista de despliegue de Django con los ajustes de producción, verifica las copias de la base de datos y los archivos subidos y prueba una restauración. Consulta también Django con Gunicorn y el módulo proxy de Nginx. Estas comprobaciones no configuran ni monitorizan el VPS por ti.

Este recorrido sirve para una app Python cuyo proceso quieres administrar. Si el proyecto usa Flask, consulta la guía de Flask con Gunicorn y Nginx. Hostbrid proporciona el VPS y el acceso root; tú instalas y operas Django, la base de datos, Nginx, HTTPS, actualizaciones y copias de seguridad. Compara las opciones VPS y los precios actuales con las necesidades de memoria, CPU y almacenamiento de la aplicación.