Por qué migrar a GlitchTip ahora
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: usted 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 cambio se reduce a sustituir el valor de su variable de entorno SENTRY_DSN por el DSN que GlitchTip le proporciona al crear el proyecto. Cero modificaciones de código de aplicación.
Lo que obtiene con GlitchTip v6 autoalojado
- Huella reducida — solo cuatro contenedores (Django, Celery, PostgreSQL, Redis), frente a la veintena de servicios de Sentry self-hosted.
- Compatibilidad con el SDK de Sentry — todos los SDK oficiales de Sentry funcionan sin modificación; solo cambia el DSN.
- Soberanía de los datos — las trazas de errores y los datos de usuario permanecen en su infraestructura, bajo su política de retención.
- Licencia GPL-3.0 — el código es auditable, sin componentes propietarios ni funciones reservadas a un plan de pago.
- Monitorización de disponibilidad — GlitchTip incluye monitores de tipo uptime (ping HTTP) sin dependencia externa.
- Interfaz de gestión del rendimiento — seguimiento de las transacciones, de las trazas N+1 y de las consultas lentas mediante la API compatible con Sentry.
- Bajo consumo de RAM — 2 GB de RAM bastan para un uso individual o de equipo pequeño, sin ajustes de configuración.
Requisitos previos antes de empezar
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 apuntando a la dirección IP de su VPS, para activar HTTPS mediante Let's Encrypt.
- Los puertos 80 y 443 abiertos en su cortafuegos.
En un VPS ServOrbit, Docker viene preinstalado. Los planes a partir de 2 vCPU y 2 GB de RAM cubren exactamente este perfil de carga.
Desplegar GlitchTip con Docker Compose
Crear el directorio de trabajo
Conéctese a su VPS por SSH y cree un directorio dedicado:
mkdir -p /opt/glitchtip && cd /opt/glitchtipCrear el archivo de variables de entorno
Cree un archivo
.envcon los valores de configuración:SECRET_KEY=<cadena-aleatoria-larga>— genérela conopenssl rand -hex 32.DATABASE_URL=postgresql://glitchtip:contrasena@db:5432/glitchtipREDIS_URL=redis://redis:6379/0GLITCHTIP_DOMAIN=https://glitchtip.su-dominio.com[email protected]EMAIL_URL=smtp://usuario:[email protected]:587Sustituya los valores por sus propias credenciales. El campo
GLITCHTIP_DOMAINdebe coincidir exactamente con el dominio que va a proteger con HTTPS — queda inscrito en los DSN generados.Crear el archivo docker-compose.yml
Cree un archivo
docker-compose.ymlcon el contenido siguiente (adaptado de la documentación oficial de GlitchTip):version: "3.8" x-environment: &default-environment env_file: .env services: db: image: postgres:16 environment: POSTGRES_DB: glitchtip POSTGRES_USER: glitchtip POSTGRES_PASSWORD: contrasena volumes: - pg_data:/var/lib/postgresql/data redis: image: redis:7 volumes: - redis_data:/data web: image: glitchtip/glitchtip:latest depends_on: [db, redis] ports: - "127.0.0.1:8000:8080" <<: *default-environment worker: image: glitchtip/glitchtip:latest command: ./bin/run-celery-with-beat.sh depends_on: [db, redis] <<: *default-environment volumes: pg_data: redis_data:Observe que el puerto 8000 está enlazado únicamente a
127.0.0.1: el servicio nunca se expondrá directamente, sino a través de un proxy inverso.Inicializar la base de datos
Ejecute las migraciones de Django para crear el esquema:
docker compose run --rm web ./manage.py migrateEste comando se lanza una sola vez en la instalación y, después, en cada actualización a una nueva versión de GlitchTip.
Crear el primer superusuario
Cree su cuenta de administrador:
docker compose run --rm web ./manage.py createsuperuserIntroduzca la dirección de correo y la contraseña cuando el asistente las solicite.
Iniciar la stack
Inicie todos los contenedores en segundo plano:
docker compose up -dCompruebe que los cuatro contenedores están en ejecución con
docker compose ps. El servicio web responde enhttp://127.0.0.1:8000.Configurar el proxy inverso nginx con HTTPS
Instale nginx y Certbot si aún no lo ha hecho:
apt install -y nginx certbot python3-certbot-nginxCree un vhost en
/etc/nginx/sites-available/glitchtipcon el bloqueserverque escucha en el puerto 80, defineserver_name glitchtip.su-dominio.comy reenvía el tráfico haciahttp://127.0.0.1:8000conproxy_pass. Active la configuración y obtenga después el certificado:certbot --nginx -d glitchtip.su-dominio.comCertbot actualiza automáticamente el vhost para redirigir HTTP hacia HTTPS y añade el bloque SSL.
Conectar el SDK de Sentry de sus aplicaciones
En la interfaz de GlitchTip, cree una organización y después un proyecto. GlitchTip genera un DSN con el formato
https://<clave>@glitchtip.su-dominio.com/<id-proyecto>.En cada una de sus aplicaciones, sustituya el valor de
SENTRY_DSN(o del parámetrodsnpasado aSentry.init()) por ese nuevo DSN. Reinicie sus procesos. Los eventos aparecen en GlitchTip sin ninguna otra modificación.
Configuración posterior a la instalación
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 electrónico.
Monitores de disponibilidad. En la sección Monitors de su proyecto, cree un monitor de tipo ping para cada uno de sus servicios expuestos: GlitchTip envía una petición HTTP a intervalos regulares y crea una issue si el servicio no responde en el plazo configurado.
Endurecimiento de la stack
Restrinja el acceso al puerto 8000 con ufw: ufw allow 80/tcp && ufw allow 443/tcp && ufw deny 8000/tcp. Añada SECURE_SSL_REDIRECT=True y SESSION_COOKIE_SECURE=True en su .env para forzar HTTPS a nivel de Django. Programe un pg_dump diario hacia una ubicación remota — el volumen pg_data contiene la totalidad de sus datos de errores y de configuración. Por último, consulte la guía de endurecimiento inicial de un servidor Linux antes de exponer la instancia a producción.
Resolución de los errores más comunes
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 intencionado). Compruebe que nginx reenvía correctamente el tráfico HTTPS hacia 127.0.0.1:8000: curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8000/api/0/ debe devolver 200.
Los eventos aparecen en los logs de Celery pero no en la interfaz — El worker de 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' — Ha olvidado crear el enlace simbólico. Ejecute ln -s /etc/nginx/sites-available/glitchtip /etc/nginx/sites-enabled/ y después nginx -t && systemctl reload nginx.
GlitchTip en producción en un VPS
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 de GlitchTip funciona con 2 GB de RAM: un VPS de 2 vCPU y 2 GB de RAM cubre exactamente ese perfil, con acceso root y elección del sistema operativo.