Cómo alojar Umami en un VPS

Umami es una alternativa ligera a Google Analytics: open source, sin cookies de rastreo, sin transferencia de datos a terceros. En un VPS, mantienes el control total — sin cuenta SaaS, sin límite de sitios, sin datos compartidos. La stack Docker es mínima: un contenedor Node.js para la aplicación y un contenedor PostgreSQL para la base de datos. La instalación completa toma menos de diez minutos en una VM estándar con acceso root, y tus datos permanecen en tu servidor.

Comparado con Google Analytics 4, Umami no requiere consentimiento para estadísticas anonimizadas en la mayoría de jurisdicciones europeas. Comparado con Matomo, su huella de memoria es significativamente menor, y su configuración Docker se reduce a un solo docker-compose.yml. Para una agencia que gestiona diez clientes, una única instancia Umami con diez sitios reemplaza una suscripción SaaS facturada por usuario o por dominio. La versión 2.14 (julio de 2026) añadió soporte nativo para eventos personalizados y un panel exportable en CSV — dos funciones largamente esperadas por los equipos de marketing.

Umami funciona en cualquier VPS con Docker instalado. El mínimo recomendado es 1 vCPU y 512 MB de RAM para uso personal o PYME; por encima de 200 000 páginas vistas mensuales, 1 GB de RAM evita ralentizaciones en PostgreSQL. Necesitarás: Docker Engine (≥ 20.10) y Docker Compose V2 (docker compose, no docker-compose), un dominio o subdominio apuntando a tu VPS, y un reverse proxy (nginx o Caddy) para servir Umami en HTTPS. Debian 12 y Ubuntu 22 son las distribuciones de referencia; los comandos siguientes asumen acceso root o sudo.

En el servidor, abre los puertos 80 y 443 en tu firewall (ufw allow 80/tcp && ufw allow 443/tcp). Umami solo necesita HTTPS expuesto externamente; el puerto de la aplicación (3000 por defecto) permanece interno y nunca se abre directamente. Si usas un VPS de ServOrbit, el grupo de seguridad predeterminado ya permite 80 y 443.

Tres causas concentran la gran mayoría de los fallos reportados en las guías de la comunidad en 2026. Aquí están con su diagnóstico y solución.

1. Bucle de reinicio «Can't reach database server» — DATABASE_URL no coincide con POSTGRES_PASSWORD

Este es el error de copiar-pegar más frecuente: DATABASE_URL contiene la contraseña en texto claro dentro de la cadena de conexión, y esa contraseña debe ser exactamente la misma que el valor de POSTGRES_PASSWORD en el servicio db. Si cambia uno sin el otro, Umami arranca, falla al conectar con la base de datos y se reinicia en bucle — sin ningún mensaje de error claro en los logs de Docker.

Verifique que ambas variables sean coherentes:

# en .env o en el compose
POSTGRES_PASSWORD=contraseña_fuerte

# en DATABASE_URL, la misma contraseña en posición 3
DATABASE_URL=postgresql://umami:contraseña_fuerte@db:5432/umami

Si utiliza interpolación de variables (${POSTGRES_PASSWORD}), asegúrese de que Docker Compose esté cargando realmente su fichero .env.

2. Umami se detiene 5-10 segundos después del arranque — depends_on sin healthcheck

Por defecto, depends_on: db solo espera a que el contenedor PostgreSQL esté iniciado, no a que esté listo para aceptar conexiones. Umami intenta entonces conectarse mientras PostgreSQL todavía está inicializando sus ficheros de datos, falla y se detiene.

Añada un healthcheck en el servicio db y un condition: service_healthy en el depends_on de Umami:

services:
  db:
    image: postgres:15-alpine
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U umami"]
      interval: 10s
      timeout: 5s
      retries: 5
  umami:
    image: ghcr.io/umami-software/umami:postgresql-latest
    depends_on:
      db:
        condition: service_healthy

Con esta configuración, Umami solo arranca una vez que PostgreSQL responde en su socket.

3. Error 502 tras docker compose pull — el puerto publicado ha cambiado

Tras una actualización (docker compose pull + docker compose up -d), nginx puede devolver un error 502 si la configuración cambió entre versiones de la imagen: el puerto interno puede haber sido reasignado o el binding del host modificado. Compruebe primero el estado real de los contenedores:

docker compose ps

Fíjese en la columna PORTS para confirmar que el contenedor Umami está publicando en el puerto esperado (3000 por defecto). Si el puerto ha cambiado, actualice la directiva proxy_pass (o reverse_proxy) en nginx o Caddy para reflejar el nuevo puerto, luego recargue el servicio (nginx -s reload o systemctl reload caddy).

4. docker-compose (v1) vs docker compose (v2) — fallo silencioso

Las guías publicadas antes de 2025 suelen usar docker-compose (guión), el cliente Python que ya no se mantiene. En una instalación nueva de Docker Engine, este comando no existe: el terminal simplemente devuelve command not found, sin indicar que v2 se llama docker compose (espacio). Comprueba con docker compose version — si responde, tienes v2. Todos los ejemplos de esta guía usan docker compose (v2).