Cuando despliegas un proyecto Django en producción, puede que el panel de administración se vea roto y aparezcan errores 404 en consola. La causa suele ser la misma: el servidor no está sirviendo los archivos estáticos que necesita la aplicación para verse bien. Aquí te muestro cómo solucionarlo configurando NGINX paso a paso.

¿Qué son los archivos estáticos en Django y por qué importan?

Los archivos estáticos son las imágenes, el CSS y el JavaScript alojados dentro del dominio de tu aplicación. Sin ellos, Django puede servir HTML, pero el resultado se ve sin estilos ni interactividad.

Si entras a tu aplicación en /admin y la ves sin formato, abre el debugger del navegador. Lo más probable es que varias URLs estén devolviendo 404 y que casi todas apunten a la ruta static [01:00]. Eso significa que tu servidor no sabe dónde encontrar esos recursos.

¿Qué son los archivos estáticos en Django? Son los recursos como CSS, JavaScript e imágenes que tu aplicación necesita para renderizarse correctamente en el navegador.

¿Cómo generar la carpeta static con collectstatic?

Antes de configurar NGINX, necesitas que los archivos existan físicamente en el servidor. Aquí entra en juego un comando clave de Django.

Conéctate por SSH a tu servidor, activa el entorno virtual y entra a la carpeta del proyecto. Haz git pull para traer los últimos cambios y lista los archivos del directorio. Verás que no existe ninguna carpeta static ni static_files [02:30].

Django trae un comando justo para esto: collectstatic. Al ejecutarlo, copia todos los archivos estáticos de tus apps a una sola carpeta de destino [02:50]. El comando te muestra la ruta exacta donde quedaron alojados.

• Conéctate por SSH al servidor.
• Activa el entorno virtual.
• Ejecuta python manage.py collectstatic.
• Verifica con ls que la carpeta exista.

Un detalle importante: aunque los archivos ya estén ahí, si recargas el sitio seguirás viendo el 404. Tener los archivos no es suficiente, necesitas un servidor web que los sirva.

¿Cómo configurar un location en NGINX para servir static?

Esta es la pieza que conecta todo. NGINX necesita una regla que diga: "cuando alguien pida algo en /static/, búscalo en esta carpeta del disco".

Edita el archivo de configuración con sudo vim /etc/nginx/sites-enabled/ y agrega un nuevo bloque location. Como en la aplicación la URL definida es static, el location debe coincidir: /static/. La ruta de origen apunta a donde collectstatic dejó los archivos, por ejemplo /server/apps/django-basic/production/static_files/ [04:10].

Agrega un slash al final para que NGINX tome todos los archivos del directorio. Y no olvides cerrar cada línea con punto y coma, es un detalle que rompe la configuración entera.

¿Para qué sirve el bloque location en NGINX? Define cómo responde el servidor a una ruta específica. En este caso, le dice a NGINX dónde buscar los archivos cuando la URL empieza con /static/.

Por qué validar antes de reiniciar NGINX

Antes de reiniciar el servicio, valida la configuración con sudo nginx -t. Si hay un error, te lo señala sin tumbar el sitio.

Si reinicias NGINX con una configuración inválida, tu sitio se cae. Pero si validas primero, el sitio sigue funcionando con la configuración anterior mientras corriges. Una vez que la validación pasa, ejecuta sudo service nginx restart y recarga el sitio. Verás cómo el admin de Django ahora se renderiza con todos sus estilos.

¿Conviene servir archivos estáticos desde NGINX o desde S3?

Servir los archivos desde tu propio servidor web es una buena práctica y funciona perfectamente para muchos proyectos. Pero hay una alternativa que puede ahorrarte dinero.

Cada request a un archivo estático consume recursos de tu servidor. Si tu sitio tiene mucho tráfico, mover esos recursos a un bucket de S3 reduce la carga y los costos asociados. El proyecto ya viene preparado para esto: existe una variable booleana que activa o desactiva el uso de S3 [01:30]. Si la pones en falso, NGINX se encarga; si la activas, los archivos se sirven desde Amazon.

• NGINX: más simple, sin dependencias externas, ideal para empezar.
• S3: menos requests al servidor, mejor para escalar tráfico alto.
• Recuerda actualizar el archivo .env si decides usar S3.

La decisión depende del volumen de tráfico y de cuánto quieras delegar a servicios externos. Si vas a probar con S3, revisa la documentación del bucket y conéctalo con las variables de entorno del proyecto.

¿Ya configuraste tus archivos estáticos en producción? Cuéntame en los comentarios qué método elegiste y si te topaste con algún error en el camino.