Despliegue seguro de Umami Analytics con Docker y PostgreSQL

Una reciente guía técnica publicada el 18 de octubre de 2026 detalla los pasos específicos necesarios para alojar por su cuenta la versión 3.4.0 de Umami Analytics utilizando Docker y PostgreSQL. El artículo hace hincapié en las prácticas de configuración segura, especialmente en lo que respecta al enlace de red y la autenticación inicial, para evitar accesos no autorizados durante el proceso de instalación.

Qué ocurrió

La guía ofrece una explicación detallada paso a paso para desplegar Umami, una alternativa centrada en la privacidad frente a Google Analytics, dentro de un entorno contenedorizado. Especifica el uso de la imagen ghcr.io/umami-software/umami:3.4.0 junto con un contenedor de base de datos postgres:15.19-alpine. Un punto central de las instrucciones es la modificación de la configuración predeterminada de Docker Compose para mejorar la seguridad inmediatamente tras el despliegue.

El autor destaca un riesgo crítico de seguridad en la configuración predeterminada original, que vincula el puerto de la aplicación a todas las interfaces de red. Dado que los puertos publicados por Docker pueden eludir los firewalls del host, como ufw, mantener la configuración predeterminada intacta podría permitir que actores externos accedan a la aplicación antes de que el administrador tenga la oportunidad de protegerla. La guía recomienda vincular el puerto específicamente a 127.0.0.1, asegurando que solo los procesos locales, como un proxy inverso, puedan comunicarse con la instancia de Umami.

Otra parte significativa de la guía aborda las credenciales predeterminadas. Umami se inicializa con una combinación estándar de nombre de usuario y contraseña: admin y umami. Las instrucciones enfatizan que los administradores deben cambiar esta contraseña inmediatamente después del primer inicio de sesión. Si el puerto está expuesto a Internet público antes de este cambio, cualquier usuario que descubra el servicio podría iniciar sesión como administrador y comprometer la instancia.

Detalles clave

• Umami versión 3.4.0 no admite MySQL; PostgreSQL es el motor de base de datos requerido.
• Las credenciales de inicio de sesión administrativo predeterminadas son el nombre de usuario admin y la contraseña umami.
• Vincular el puerto de Docker a 127.0.0.1:3000 impide el acceso de red externo al puerto bruto de la aplicación.
• Los secretos como POSTGRES_PASSWORD, APP_SECRET y TWO_FACTOR_ENCRYPTION_KEY deben almacenarse en un archivo .env protegido.
• Cambiar la contraseña de PostgreSQL en las variables de entorno después de la creación inicial de la base de datos causará fallos de autenticación a menos que también se actualice manualmente la contraseña del usuario de la base de datos.
• La aplicación incluye un filtro de detección de bots que descarta silenciosamente las solicitudes de navegadores sin interfaz gráfica (headless), lo cual puede confundir a los desarrolladores durante las pruebas.

Contexto

Alojar por su cuenta software de análisis otorga a las organizaciones control sobre sus datos, pero también transfiere toda la responsabilidad de seguridad al equipo interno de TI. A diferencia de los servicios gestionados donde el proveedor se encarga de los parches y el control de acceso, las instancias autoalojadas requieren una configuración cuidadosa de los límites de red y los mecanismos de autenticación. Docker simplifica el despliegue de aplicaciones complejas como Umami al empaquetar la aplicación y sus dependencias en contenedores, pero introduce comportamientos de red específicos que los administradores deben comprender.

Un malentendido común es que los firewalls del host protegen automáticamente los contenedores de Docker. En muchas configuraciones predeterminadas, Docker gestiona sus propias reglas iptables, que pueden anular la configuración de firewall definida por el usuario, como ufw. Esto significa que si un contenedor expone un puerto al host, puede ser accesible desde la red más amplia incluso si el firewall del host parece bloquear ese tráfico. Comprender esta interacción es crucial para asegurar cualquier aplicación web autoalojada.

Por qué importa

Para los equipos que ejecutan su propio software, la diferencia entre un despliegue seguro y uno vulnerable a menudo radica en pequeños detalles de configuración. La recomendación de vincularse a localhost es una estrategia fundamental de defensa en profundidad. Garantiza que la aplicación no esté expuesta directamente a Internet, forzando todo el tráfico a través de un proxy inverso como Caddy o Nginx. Esta configuración permite que el proxy maneje la terminación TLS y encabezados de seguridad adicionales, mientras que la aplicación misma permanece aislada en la interfaz de bucle local.

El problema con las credenciales predeterminadas es otro desafío persistente en entornos autoalojados. Muchos proyectos de código abierto utilizan contraseñas predeterminadas simples para facilitar la configuración inicial y las pruebas. Sin embargo, si estos valores predeterminados no se cambian inmediatamente, se convierten en un punto de entrada bien conocido para los atacantes. Automatizar el proceso de generación de secretos, como sugiere la guía utilizando herramientas como openssl, reduce el riesgo de error humano y asegura que cada despliegue comience con credenciales únicas y fuertes.

Además, la nota de la guía sobre el filtrado de bots destaca la importancia de comprender la lógica de la aplicación durante la resolución de problemas. Los desarrolladores a menudo prueban nuevos despliegues utilizando herramientas automatizadas o navegadores sin interfaz gráfica, que Umami identifica como bots e ignora. Sin este conocimiento, los equipos podrían pasar mucho tiempo depurando por qué sus scripts de seguimiento parecen fallar, cuando en realidad el sistema está funcionando según lo diseñado para preservar la calidad de los datos.

Qué puede hacer

• Genere secretos aleatorios fuertes para POSTGRES_PASSWORD, APP_SECRET y TWO_FACTOR_ENCRYPTION_KEY antes de iniciar los contenedores.
• Modifique el archivo de Docker Compose para vincular el puerto de Umami a 127.0.0.1 en lugar de a todas las interfaces.
• Despliegue un proxy inverso como Caddy para manejar conexiones HTTPS y reenviar el tráfico a la instancia local de Umami.
• Inicie sesión inmediatamente después del primer arranque y cambie la contraseña de administrador predeterminada por un valor fuerte y único.
• Fije la etiqueta de la imagen de Docker a una versión específica como 3.4.0 en lugar de usar latest para garantizar actualizaciones predecibles.
• Pruebe la funcionalidad de seguimiento utilizando un navegador estándar con un agente de usuario normal para evitar ser filtrado por la detección de bots integrada.