Instalar GlitchTip en un VPS: rastreador de errores soberano

Sentry self-hosted 26.4.x sufre desde agosto de 2026 cinco regresiones simultáneas documentadas por la comunidad. Las issues #4301 y #4306 describen respectivamente consumers de Snuba que se reinician en bucle sin procesar ningún evento, y un deadlock en el monitor_consumer que bloquea el registro de los crons. La issue #4321 señala un fallo de autenticación del relay en las conexiones HTTP/2, lo que interrumpe la ingesta de eventos. Estas regresiones han llevado a varios equipos a documentar públicamente su migración a GlitchTip.

La objeción más frecuente es la compatibilidad: ha instrumentado sus aplicaciones con el SDK de Sentry (sentry-python, @sentry/node, sentry-rails…) y no desea reescribir esa instrumentación. GlitchTip implementa la API de Sentry y acepta los eventos enviados por esos mismos SDK. El intercambio se reduce a reemplazar el valor de su variable de entorno SENTRY_DSN por el DSN que GlitchTip proporciona al crear el proyecto. Cero cambios en el código de la aplicación.

GlitchTip v6 se apoya en cuatro contenedores: Django (el servidor web y la interfaz), Celery (las tareas asíncronas de procesamiento de eventos), PostgreSQL (la base de datos principal) y Redis (la cola de tareas). Necesita:

- Un VPS Linux con 2 GB de RAM como mínimo (4 GB resultan cómodos para un equipo de diez desarrolladores y un volumen de algunos cientos de errores al día).
- Docker y Docker Compose instalados — disponibles en todas las distribuciones recientes.
- Un nombre de dominio o subdominio apuntado a la IP de su VPS, para activar HTTPS a través de Let's Encrypt.
- Los puertos 80 y 443 abiertos en su cortafuegos.

En un VPS de ServOrbit, Docker viene preinstalado. El VPS Start (2 vCPU, 4 GB de RAM), nuestro plan más pequeño, cubre este perfil de carga con margen.

Tras el primer arranque, ajuste estos puntos en la interfaz de administración:

Variables de entorno complementarias. Active el envío de alertas por correo definiendo EMAIL_URL en su .env. Añada GLITCHTIP_MAX_EVENT_LIFE_DAYS=90 para limitar la retención de los eventos y controlar el crecimiento de la base de datos.

Acceso multiequipo. GlitchTip gestiona organizaciones y miembros con distintos niveles de permiso. Cree sus equipos desde Configuración → Miembros e invite a sus desarrolladores por correo.

Monitores de disponibilidad. En la sección Monitors de su proyecto, cree un monitor de ping para cada servicio expuesto: GlitchTip envía una petición HTTP a intervalos regulares y crea una issue si el servicio no responde en el tiempo configurado.

Alertas webhook hacia Slack o ntfy. Desde Configuración → Alertas, añada un destino de tipo "Webhook". Para Slack, pegue la URL de su Incoming Webhook (https://hooks.slack.com/services/…); para ntfy, use https://ntfy.sh/<su-topic> con el método POST. GlitchTip envía un JSON estructurado en cada nueva issue o superación de umbral.

Integración SDK — Python. Reemplace únicamente el valor del DSN; el resto del código permanece idéntico:

import sentry_sdk y luego sentry_sdk.init(dsn="https://<clave>@glitchtip.su-dominio.com/<id>", traces_sample_rate=1.0)

Integración SDK — React. Misma lógica en el front:

import * as Sentry from "@sentry/react" y luego Sentry.init({ dsn: "https://<clave>@glitchtip.su-dominio.com/<id>", tracesSampleRate: 1.0 })

GlitchTip recibe tanto las excepciones de Python/Node como los errores JavaScript capturados en el navegador, todo agrupado en la misma interfaz.

Retención de datos. La variable GLITCHTIP_MAX_EVENT_LIFE_DAYS (sin límite por defecto) controla la antigüedad máxima de los eventos conservados. En un SSD de 60 GB, una retención de 90 días para algunos cientos de errores al día raramente supera los 5 GB — monitorice con docker system df.

Error: relation "glitchtip_*" does not exist — La migración no se ha ejecutado. Lance docker compose run --rm web ./manage.py migrate y compruebe que el contenedor db está en buen estado con docker compose ps.

CSRF verification failed. Request aborted. — La variable GLITCHTIP_DOMAIN no coincide con el dominio desde el que accede a la interfaz. Compruebe que está definida sin barra final y reinicie los contenedores con docker compose restart.

Connection refused en el DSN desde su aplicación — El puerto 8000 no es accesible desde el exterior (es intencional). Verifique que nginx reenvía correctamente el tráfico HTTPS a 127.0.0.1:8000.

Los eventos aparecen en los logs de Celery pero no en la interfaz — El worker Celery arrancó antes de que terminaran las migraciones. Reinícielo con docker compose restart worker.

No such file or directory: '/etc/nginx/sites-enabled/glitchtip' — Olvidó crear el enlace simbólico. Ejecute ln -s /etc/nginx/sites-available/glitchtip /etc/nginx/sites-enabled/ y luego nginx -t && systemctl reload nginx.

celery.exceptions.WorkerLostError: Worker exited prematurely: signal 9 (SIGKILL) — El contenedor worker fue matado por el OOM killer del kernel. Su VPS se queda sin RAM: reduzca CELERY_WORKER_CONCURRENCY a 2 en .env, o pase a 4 GB de RAM. Confirme con docker compose logs worker --tail 50 y dmesg | grep -i oom.

django.db.utils.OperationalError: FATAL: remaining connection slots are reserved for non-replication superuser connections — PostgreSQL ha alcanzado su límite de max_connections (por defecto: 100). Añada CONN_MAX_AGE=60 en .env para activar el pool de conexiones de Django, o configure PgBouncer como intermediario. Este error aparece típicamente cuando varios workers Celery se ejecutan en paralelo sin pool de conexiones.

GlitchTip v6, publicado en febrero de 2026 bajo licencia GPL-3.0, se apoya en cuatro contenedores. Su compatibilidad con el SDK de Sentry lo convierte en una salida limpia de Sentry self-hosted cuando este acumula regresiones difíciles de sortear.

Para ir más lejos, consulte nuestra guía sobre la checklist de Docker Compose en producción para asegurar aún más su despliegue, y nuestro artículo sobre la rutina de parches de las aplicaciones autoalojadas para mantener GlitchTip al día sin interrupción del servicio.

Una instancia GlitchTip cabe en 2 GB de RAM: el VPS Start (2 vCPU, 4 GB de RAM) cubre este perfil con margen, con acceso root y elección de SO.