Desplegar una aplicación Django en un servidor remoto requiere clonar el repositorio con seguridad, instalar dependencias en un entorno virtual y servir el proyecto con Gunicorn. Esta guía muestra el flujo completo para desarrolladores backend que quieran llevar su aplicación Python a producción usando una instancia en AWS, claves SSH y reglas de firewall correctamente configuradas.

¿Cómo clonar un repositorio privado en un servidor con SSH key?

Clonar un proyecto Django dentro de un servidor empieza por preparar la carpeta destino y autenticar el acceso a GitHub mediante una deploy key.

El primer paso es crear el directorio donde vivirán las aplicaciones. Dentro de /srv se ejecuta sudo mkdir apps y luego se cambia el propietario con sudo chown ubuntu:ubuntu apps. Sin esos permisos, el usuario ubuntu no podrá clonar nada y verás un error de acceso denegado [01:30].

El siguiente bloqueo aparece al intentar git clone con la URL SSH: GitHub rechaza la conexión porque el servidor aún no tiene una llave autorizada. Aquí entra el concepto de deploy key, una llave pensada exclusivamente para despliegue.

¿Qué es una deploy key en GitHub? Es una llave SSH asociada a un repositorio específico que permite clonar el código solo desde un servidor autorizado. Por defecto es de solo lectura, lo que la hace ideal para producción.

¿Cómo generar la llave SSH y registrarla en GitHub?

Dentro del servidor se ejecuta ssh-keygen -t indicando el formato y -C con un correo identificador [03:40]. La llave se guarda en ~/.ssh y genera dos archivos: la privada y la pública.

Con cat se imprime la llave pública y se copia en GitHub, en Settings > Deploy keys. Una recomendación clave: no marques la opción de escritura. Todos los cambios deben pasar por code review y pull request desde un equipo local, nunca desde el servidor.

GitHub pedirá un código de two factor authentication antes de guardar la llave, capa de seguridad imprescindible para evitar accesos no autorizados.

¿Cómo configurar el entorno virtual de Python en Ubuntu?

Una vez clonado el repositorio, el proyecto se trata como cualquier instalación local: entorno virtual aislado e instalación de dependencias.

Se crea una carpeta oculta con mkdir .envs para alojar todos los entornos virtuales del servidor. Dentro se ejecuta python3 -m venv con el nombre de la aplicación. La imagen base de Ubuntu no incluye todos los paquetes de Python necesarios, por lo que el sistema mostrará un comando sugerido para instalar las dependencias faltantes [05:50].

Después se activa el entorno con source apuntando al activate correspondiente. El prompt cambia para mostrar el entorno activo, señal de que cualquier instalación quedará aislada del sistema.

Finalmente se instalan las dependencias del proyecto con:

• pip install -r requirements.txt para leer el archivo de dependencias.
• Django 5.1.2 y el resto de librerías quedan disponibles dentro del entorno.
• El entorno virtual evita conflictos entre versiones de paquetes.

Un detalle de organización: nombrar la carpeta del proyecto incluyendo el entorno, por ejemplo django-basic-production, ayuda a identificar rápidamente en qué servidor estás trabajando cuando manejas varias instancias.

¿Cómo servir Django con Gunicorn en un servidor de producción?

Gunicorn es la librería que convierte una aplicación WSGI de Django en un servidor web capaz de atender peticiones reales.

La instalación se hace con pip install gunicorn dentro del entorno virtual activo. Para ejecutarlo se pasan dos parámetros principales: el --bind con la dirección y puerto, y la ruta al objeto application.

El comando queda así: gunicorn --bind 0.0.0.0:8000 config.wsgi:application. El 0.0.0.0 indica que el servidor escucha en todas las IPs disponibles, y config.wsgi:application apunta al objeto WSGI dentro del módulo de configuración del proyecto [08:30].

¿Qué hace Gunicorn en un despliegue Django? Toma el archivo wsgi.py de Django y expone la aplicación como un servidor HTTP. Gestiona los workers que procesan las peticiones en producción.

¿Por qué no carga mi sitio Django después de levantar Gunicorn?

Dos errores típicos aparecen al primer intento de acceso. El primero es que el navegador queda cargando indefinidamente: el security group de AWS no permite tráfico al puerto 8000.

La solución es editar las reglas en Security Groups, agregar una regla Custom TCP con puerto 8000 abierta a todas las IPs y guardar. Solo después el servidor empezará a responder.

El segundo error es un mensaje de Django indicando que la IP no está en ALLOWED_HOSTS. Hay que editar el archivo config/settings.py y añadir la IP pública del servidor. Un detalle importante: se agrega solo la IP, sin el puerto [11:50]. Incluir el puerto provoca que Django siga rechazando la petición.

Tras corregir y reiniciar Gunicorn, la aplicación responde correctamente desde el navegador. El despliegue manual quedó funcional, aunque en producción real conviene automatizar este comando como servicio del sistema y usar un dominio en lugar de una IP cruda.

¿Ya probaste cambiar la cantidad de workers de Gunicorn para medir el rendimiento? Cuéntame en los comentarios qué configuración te dio mejores resultados.