Configurar uWSGI con Python y NGINX te permite escalar tu aplicación Django más allá de lo que ofrece Gunicorn, controlando workers, procesos maestros y sockets de comunicación. Aquí verás cómo instalarlo, crear el archivo .ini, enlazarlo y validar que tu aplicación corre incluso después de reiniciar el servidor.

Por qué usar uWSGI en lugar de Gunicorn

uWSGI te da control sobre detalles que Gunicorn deja fuera. Puedes definir cuántos workers corren, manejar un proceso master que administra a los demás y mantener tu sitio en línea durante cada deploy.

A diferencia de Gunicorn, uWSGI funciona también con servidores como Apache, aunque en este flujo usamos NGINX. Esa flexibilidad lo hace popular en entornos de producción donde necesitas afinar memoria, número de procesos y comunicación vía socket.

¿Qué es uWSGI? Es un servidor de aplicaciones que ejecuta proyectos Python (y otros) detrás de un servidor web como NGINX, permitiendo configurar workers, procesos maestros y plugins específicos por lenguaje.

Cómo instalar uWSGI y el plugin de Python en el servidor

Conéctate al servidor con ssh usando tu llave de identificación, username e IP. Una vez dentro, ejecuta sudo apt install uwsgi para instalar el servidor base [01:00].

No basta con eso. Como tu aplicación es Python, necesitas instalar también el plugin correspondiente con sudo apt install uwsgi-plugin-python3. Este plugin es lo que le indica a uWSGI cómo ejecutar código Python específicamente.

Para validar la instalación, escribe uwsgi en la terminal. Verás todos los parámetros configurados por defecto: tamaño de memoria, número de procesos y límites operativos.

Cómo crear el archivo de configuración .ini en uWSGI

Los archivos de configuración viven en /etc/uwsgi, organizados en dos carpetas: apps-available (disponibles) y apps-enabled (habilitadas). Esta estructura es idéntica a la que NGINX usa para sus sitios.

Dentro de apps-available, crea tu archivo con sudo vim nombre-production.ini. El sufijo production te ayuda a diferenciar entornos cuando manejas varias aplicaciones [03:30].

Qué parámetros debe incluir tu archivo ini

El archivo arranca con [uwsgi] entre corchetes. A partir de ahí defines bloques clave para que tu aplicación corra:

• module: apunta al entry point de tu app, por ejemplo config.uwsgi:application. Lo encuentras en tu repositorio dentro de config/uwsgi.py.
• plugins: indica python3 para que uWSGI sepa qué intérprete usar.
• socket: archivo de comunicación con NGINX, ubicado en /tmp/deployWithPythonProduction.sock. Usa un nombre único porque /tmp lo comparten muchos procesos.
• chdir: ruta del proyecto, equivalente a hacer change directory hacia tu carpeta de aplicación.
• home: ruta del entorno virtual donde Python buscará librerías y dependencias.
• env: variables de entorno como DJANGO_SETTINGS_MODULE.
• master: en true, activa el proceso maestro que administra el resto.

Para qué sirve el proceso master en uWSGI

El master es la pieza que mantiene tu sitio activo durante un deploy. Cuando subes cambios, este proceso se encarga de eliminar los workers viejos y crear los nuevos, evitando que tu aplicación quede caída en la transición.

¿Qué es un socket en uWSGI? Es un archivo en /tmp que actúa como puente de comunicación entre uWSGI y NGINX, permitiendo que las peticiones del navegador lleguen a tu aplicación Python.

Cómo habilitar la aplicación con un link simbólico

Tener el archivo en apps-available no basta: la aplicación está disponible pero no activa. Para habilitarla, debes crear un link simbólico hacia apps-enabled.

Desde la carpeta apps-enabled, ejecuta:

bash sudo ln -s ../apps-available/deploy-production.ini .

Un error común es ejecutar el ln desde la carpeta equivocada o apuntar al archivo dentro de la misma apps-enabled. Si lo haces mal, verás el error Too many levels of symbolic links al intentar leer el archivo con cat [10:30].

Un truco útil cuando algo falla: ejecuta history | grep ln para revisar todos los comandos ln que has corrido y detectar cuál creaste mal.

Cómo validar que uWSGI está corriendo correctamente

Usa sudo service uwsgi status para revisar el estado del servicio. Si ves exit en lugar de procesos activos, algo en tu configuración o link simbólico falló.

La herramienta htop te muestra todos los procesos del servidor en tiempo real. Presiona F4 para filtrar por uwsgi y verás cuántos workers están activos. Por defecto aparecen tres: el master más dos workers.

Otra validación rápida: revisa que el socket exista en /tmp con ls /tmp. Si el archivo .sock está ahí, la conexión con NGINX queda lista.

Cómo aumentar el número de workers en uWSGI

Para escalar el número de procesos, edita tu archivo .ini con sudo vim y agrega:

ini processes = 4

Reinicia con sudo service uwsgi restart y valida con htop. Verás cinco procesos: un master y cuatro workers. Eso significa que tu aplicación puede manejar cuatro requests simultáneas en cada momento.

Con esta configuración, tu aplicación se ejecuta automáticamente incluso si reinicias el servidor, porque uWSGI corre como servicio de Linux y lee el archivo .ini al arrancar.

¿Cuántos workers configurarías para tu propio proyecto? Cuéntalo en los comentarios y comparte qué parámetros adicionales del manual oficial de uWSGI has probado.