El ecosistema de observabilidad y seguimiento de errores sigue llenándose de herramientas que intentan resolver un problema muy concreto: capturar fallos de aplicaciones sin obligar a las empresas a desplegar plataformas cada vez más pesadas. En ese contexto aparece gosnag, un servicio autohospedado de seguimiento de errores que se presenta como compatible con los SDK oficiales de Sentry y como un reemplazo directo para quienes quieren seguir usando esos clientes, pero con una infraestructura más simple y bajo su propio control. El proyecto está publicado en GitHub bajo licencia MIT y se define como un sistema self-hosted que recibe errores desde cualquier cliente Sentry y los muestra en un dashboard propio para monitorizar, clasificar y resolver incidencias.
La propuesta técnica de gosnag es clara y bastante fácil de entender. Su README oficial lo describe como un single binary con backend en Go, frontend en React embebido y migraciones SQL incluidas, con soporte para autenticación mediante Google Sign-In, panel en tiempo real, gestión de incidencias, alertas por SMTP y Slack, retención configurable de eventos, limitación de tasa por IP y control de acceso por roles entre administradores y miembros. Para un equipo pequeño o mediano, esa combinación resulta atractiva porque concentra en una sola aplicación lo que muchas veces obliga a desplegar una pila bastante más compleja.
Lo más interesante es que no obliga a cambiar el lado cliente. La documentación pública explica que basta con reutilizar el DSN del proyecto en cualquier SDK compatible con Sentry, con ejemplos tanto en JavaScript como en Python. Eso significa que, al menos en el enfoque del proyecto, la migración desde un entorno que ya reporta a Sentry podría ser relativamente sencilla: cambiar el destino del DSN y empezar a ingerir eventos en una instancia propia de gosnag. Esa compatibilidad con los SDK oficiales de Sentry es, sin duda, el principal gancho del producto.
Una apuesta por lo ligero frente a los despliegues más pesados
gosnag parece moverse en un espacio muy específico del mercado: el de equipos que quieren control del dato y autohospedaje, pero sin asumir toda la complejidad de una plataforma de observabilidad más grande. Su documentación marca como requisitos PostgreSQL, un cliente de Google para autenticación y, en entorno de compilación, Go 1.25+ y Node 20+. La vía recomendada de arranque es Docker Compose, lo que lo sitúa en una categoría bastante asequible para desarrolladores, SaaS pequeños o equipos internos que solo necesitan trazabilidad de errores y un panel razonable para triarlos.
Ahí aparece inevitablemente la comparación con Sentry. El proyecto oficial getsentry/self-hosted se presenta como una distribución self-hosted “feature-complete” de Sentry para despliegues de bajo volumen y pruebas de concepto. gosnag no afirma competir en toda esa amplitud funcional, y tampoco presume de cubrir el mismo abanico de producto. Más bien apunta a una solución más acotada: seguimiento de errores, incidencias, stack traces, alertas y dashboard, con una instalación más ligera. La comparación exacta de capacidades dependerá del caso de uso, pero la diferencia de ambición entre ambos proyectos es bastante evidente.
Qué ofrece hoy y qué no parece ofrecer
La ficha pública de gosnag deja claro qué terreno pisa. Hay compatibilidad con SDKs de Sentry, dashboard en tiempo real, asignación de issues, estados como resuelto o en snooze, detección de regresiones, notificaciones y limpieza automática de eventos antiguos. También incorpora rate limiting por IP en los endpoints de ingestión y un esquema de usuarios con primer usuario promovido automáticamente a administrador. Eso lo hace especialmente interesante para equipos que necesitan un servicio autocontenido de seguimiento de errores y no quieren depender de una plataforma de terceros para cada evento que capturan.
Al mismo tiempo, el propio README no habla de una plataforma completa de observabilidad, ni de un producto equivalente a toda la oferta de Sentry. No hay una promesa explícita de trazas distribuidas, profiling avanzado o una capa más amplia de APM en la descripción pública del proyecto. Por eso la lectura más razonable es entender gosnag como una herramienta enfocada en error tracking compatible con Sentry, no como una sustitución total de todo el ecosistema de observabilidad que puede ofrecer una plataforma más madura o más extensa. Esa diferencia es importante, sobre todo para no sobredimensionar expectativas.
A quién puede interesarle
gosnag parece especialmente bien orientado a tres perfiles. El primero es el de pequeños equipos de producto que ya usan SDKs de Sentry y quieren dejar de depender de un servicio externo para errores. El segundo es el de empresas con requisitos de residencia del dato o políticas más estrictas sobre qué información sale de su infraestructura. El tercero es el de desarrolladores que quieren algo más ligero que una instalación self-hosted completa de Sentry, sin renunciar a la compatibilidad con sus SDKs. Esa es una inferencia bastante razonable a partir del diseño del proyecto y de cómo se presenta públicamente.
También hay un punto práctico que juega a su favor: el modelo de configuración es muy directo. Todo se controla mediante variables de entorno y la lista es bastante clara: base de datos, cliente OAuth, puerto, nivel de log, secreto de sesión, tiempos de cooldown, retención, límites de ingestión y parámetros para correo o Slack. Para operaciones y DevOps, esa simplicidad suele ser más valiosa de lo que parece.
Preguntas frecuentes
¿Qué es gosnag exactamente?
Es un servicio autohospedado de seguimiento de errores que se presenta como compatible con los SDK oficiales de Sentry y como una alternativa más simple para monitorizar, clasificar y resolver incidencias desde un dashboard propio.
¿Hace falta cambiar el código cliente si ya uso Sentry SDKs?
En principio, no mucho. El proyecto indica que funciona con los SDK oficiales de Sentry y muestra ejemplos donde basta con usar el DSN del proyecto de gosnag en lugar del destino anterior.
¿Qué necesita para funcionar?
La documentación pública pide PostgreSQL y un Google OAuth client ID como requisitos principales de configuración. Para desarrollo o compilación desde código fuente también cita Go 1.25+ y Node 20+.
¿Es una alternativa completa a todo Sentry?
No parece plantearse así. gosnag está centrado en error tracking compatible con Sentry, dashboard, gestión de incidencias y alertas. El proyecto self-hosted oficial de Sentry se presenta como una distribución “feature-complete”, por lo que ambos juegan en escalas distintas.
