Sentry auto-hospedado vs SaaS: cuánto se ahorra realmente

La pregunta llega casi todas las semanas a la bandeja de entrada de quien acompaña el blog: ¿vale la pena dejar Sentry SaaS y auto-hospedar? La respuesta honesta empieza con un "depende" — y la mayor parte del contenido que circula sobre el tema trata el "depende" como si fuera evasiva. No lo es. Existen tres variables duras que deciden la cuenta — volumen de eventos, capacidad operacional del equipo y exigencia de compliance — y cada una de ellas tiene un número que consigues medir antes de tomar la decisión.

Este post es la versión larga de la respuesta. Si eres CTO de una startup en la etapa entre cinco y cincuenta ingenieros, leyendo la factura de Sentry subir mes a mes, lo que viene abajo sirve como una calculadora explicada — no como sermón a favor o en contra de auto-hospedado. Al final tiene una tabla con doce criterios, una sección de FAQ para preguntas que no cupieron en el cuerpo del texto, y tres perfiles bien definidos de cuándo cada camino tiene sentido.

TL;DR — versión de 30 segundos

Sentry SaaS empieza en US$26/mes en el plan Team — cubre 50 mil errores/mes y cinco usuarios. Para startup con tráfico serio, la cuenta sube rápido al rango de US$80–200/mes (R$400–1.000/mes al cambio de R$5/USD), y en scale-up llega tranquilamente en US$300–500/mes (R$1,5k–2,5k/mes). Es predecible y no pide nada al equipo más allá de la tarjeta de crédito.

Auto-hospedado es "open-source gratuito" en el marketing, pero el software corre diez a doce contenedores — PostgreSQL, Redis, Kafka, ZooKeeper, ClickHouse, Symbolicator y cuatro procesos Sentry distintos. Pide entre 8 GB de RAM y 4 vCPUs en un servidor dedicado, más almacenamiento, backup, actualizaciones trimestrales y el tiempo del dev que cuida de eso todo.

Vale auto-hospedar cuando: (a) volumen pasó de 1 millón de errores/mes y la factura SaaS empezó a doler, (b) el equipo tiene capacidad operacional para cuidar de stack complejo sin volverse cuello de botella, o (c) compliance exige datos en servidor propio. No vale para equipo de una a tres personas enfocado en producto, o volumen bajo donde el SaaS es solo ruido de presupuesto.

Término medio interesante: GlitchTip — open-source MIT, compatible con el Sentry SDK existente, corre en Postgres + Redis (sin Kafka, sin ClickHouse, sin ZooKeeper). Cubre 80% del valor de Sentry con 20% del overhead operacional.

Lo que Sentry SaaS hace bien

Antes de discutir coste, vale la pena reconocer por qué estás pagando. Sentry hospedado entrega una combinación que es difícil de reproducir en casa sin invertir varios trimestres del equipo:

• Stack pre-configurada. Creas cuenta, instalas el SDK en la aplicación, y en quince minutos tienes errores llegando. Cero servidor, cero archivo de configuración, cero backup para agendar.
• Performance Monitoring integrado. Tracing distribuido, n+1 queries detection, slow database queries — todo en el mismo dashboard donde ya estás mirando los errores.
• Session Replay. Grabación anonimizada de la sesión del usuario hasta el momento del error. Vale oro para debugar escenarios que no se reproducen en dev.
• Alerting maduro. Integración con Slack, PagerDuty, Microsoft Teams, e-mail y webhooks. Reglas finas — alerta solo cuando tasa de error duplica en 5 minutos, solo en producción, solo para usuarios autenticados.
• Issue tracking + sync. Linka issue al Linear/Jira/GitHub Issues automáticamente. Resuelve del lado del tracker, cierra del lado de Sentry.
• Continuous Profiling. Profile en producción sin overhead perceptible, descubriendo cuellos de botella de CPU sin necesidad de reproducir localmente. Disponible solo en la versión SaaS — auto-hospedado aún no soporta.
• Soporte técnico. Dependiendo del plan, equipo humano respondiendo en hasta cuatro horas útiles.

Ese paquete entero cuesta US$26/mes en el plan de entrada. Para un equipo de tres personas empezando un SaaS, es literalmente el mejor uso de R$130/mes que existe en la estantería.

La cuenta SaaS, línea por línea

La trampa de Sentry SaaS no es el precio de entrada — es la curva. Vamos a detallar para startup en tres etapas distintas:

Etapa 1 — primer producto, R$10–30k MRR.

• Plan Team: US$26/mes (50 mil errores/mes, 5 usuarios)
• Total: R$130/mes

Esa es el rango en que nadie debería estar pensando en auto-hospedado. R$130/mes es casi ruido de presupuesto — gastar cuatro horas del CTO instalando infraestructura de monitoreo cuesta más que dos años de suscripción.

Etapa 2 — producto creciendo, R$50–100k MRR.

• Plan Business: US$80/mes (300 mil errores/mes incluidos)
• Performance events extras: US$15–30/mes
• Session Replay: US$25–50/mes
• Usuarios adicionales (10 devs): US$50/mes
• Total: US$170–210/mes = R$850–1.050/mes

Aquí la factura empieza a aparecer en el reporte financiero mensual. No duele aún, pero notas.

Etapa 3 — scale-up, R$200k+ MRR, 20+ ingenieros.

• Plan Business con ajustes: US$200–300/mes base
• Performance events: US$50–100/mes
• Session Replay: US$100/mes
• Usuarios: US$100/mes
• Total: US$450–600/mes = R$2.250–3.000/mes

En esa etapa, R$30 mil/año en error tracking empieza a competir con salario parcial de ingeniero. Es el punto en que la conversación "¿vale auto-hospedar?" deja de ser teórica y se vuelve reunión agendada.

El dolor real del plan Business no es el precio base — es la multiplicación por add-ons. Performance, Replay, Profiling, Cron Monitoring, Code Coverage — cada uno viene con su propio conteo de eventos y su propia cuenta. Es predecible, pero no es barato.

Sentry auto-hospedado — qué es exactamente

La carpeta oficial getsentry/self-hosted instala un stack que tiene la forma siguiente, en producción:

Suma: cerca de 8 GB de RAM en uso firme en un cluster pequeño, 12 contenedores, y eso es el piso. En volumen mayor, Kafka y ClickHouse quedan con hambre bien rápido.

La trampa menos discutida es la licencia: desde 2019, Sentry licencia el producto auto-hospedado bajo BSL 1.1 (Business Source License). Es open-source en la forma — lees el código, modificas, contribuyes — pero tiene una cláusula que prohíbe ofrecer Sentry como servicio comercial a terceros. Para empresa que usa internamente, es irrelevante. Para agencia que pensaba incluir error tracking en el paquete vendido al cliente, es prohibitivo.

Setup en cluster — pasos altos

La documentación oficial asume que vas a correr ./install.sh en un servidor Ubuntu, y enseguida el docker-compose up -d administra el stack. Para quien opera cluster moderno, el camino es ligeramente distinto:

1. Definir job spec con 12 contenedores. HeroCtl acepta archivo de configuración de hasta algunos miles de líneas, y la traducción del compose oficial al job spec es mecánica. Reserva un turno de trabajo para hacer eso bien — incluyendo depends_on, health checks, y órdenes de boot (ZooKeeper antes de Kafka, Postgres antes de sentry-web, y así sucesivamente).
2. Volúmenes persistentes para Postgres, ClickHouse y Kafka. Los tres tienen datos que no puedes perder. ClickHouse es el que más crece — eventos brutos se vuelven líneas analíticas y el disco llena. Reserva 50 GB de SSD inicial, ajusta a 200 GB después de seis meses si el volumen lo justifica.
3. Backup, y backup de cada uno por separado. El error más común en auto-hospedado es hacer backup solo de Postgres, olvidando que los eventos viven en ClickHouse. Postgres tiene metadatos (proyecto, usuario, configuración de alerta); ClickHouse tiene el historial de errores. Backup solo de Postgres recupera la interfaz vacía.
4. TLS automático en el dominio interno. El panel necesita estar accesible para los devs con certificado válido — sin -k en el curl, sin aviso amarillo en Chrome. El cluster de HeroCtl resuelve eso automáticamente con Let's Encrypt; en otros stacks añades un operador o configuras manualmente.
5. Actualizaciones trimestrales. Sentry libera versión major cada tres meses, y la auto-hospedada exige migración de schema de Postgres + reindex parcial de ClickHouse. Reserva una ventana de mantenimiento en cada release — en general entre 15 minutos y dos horas, dependiendo del volumen acumulado.

Tiempo total de instalación: 4 a 8 horas para dev competente que conoce el producto, 2 a 3 días para alguien aprendiendo desde cero. Eso es el setup limpio. Añade 50% para debugar el caso real (DNS interno errado, volumen no montado, Kafka trabado por ZooKeeper que tardó en subir).

GlitchTip — el "Sentry-lite" que mucha gente olvida

GlitchTip es la alternativa que aparece poco en comparativos y merece destaque. Es open-source MIT (no BSL) — usas para cualquier fin, incluso comercial, sin cláusula. Fue diseñado específicamente para cubrir el caso 80/20 de Sentry.

Cómo funciona el "compatible con Sentry SDK": el SDK de Sentry envía eventos a un endpoint HTTP estándar. GlitchTip implementa ese mismo endpoint. Cambias la URL en el Sentry.init({ dsn: ... }) de tu aplicación para apuntar a GlitchTip y nada más cambia — ni código, ni dependencia, ni build. La migración inversa también es directa.

Stack de GlitchTip:

• PostgreSQL
• Redis (colas)
• Django web
• Celery worker

Son 4 contenedores contra 12 de Sentry. Recursos: 2 GB de RAM, 1 vCPU. Corre cómodo en un droplet de US$12/mes. Acepta los mismos SDKs (JavaScript, Python, Go, Ruby, PHP, Java, .NET, mobile) sin cambio.

Lo que GlitchTip no tiene:

• Session Replay
• Continuous Profiling
• Performance Monitoring al nivel de detalle de Sentry (tiene versión simplificada)
• Tracing distribuido con waterfall completo
• Code Coverage
• Cron monitoring sofisticado

Lo que GlitchTip tiene:

• Error tracking completo, con agrupamiento, frecuencia, primero/último visto
• Stack traces de cualquier lenguaje soportado por los SDKs Sentry
• Uptime monitoring básico
• Alerting vía webhook, e-mail e integraciones populares
• Issue tracking minimal — asignar, resolver, ignorar
• Multi-proyecto, multi-equipo, RBAC simple

Para startup pequeña o mediana que no usa Replay ni Profiling avanzado, GlitchTip cubre lo que importa con una fracción de la operación. Es el caso más subestimado de la estantería.

La cuenta auto-hospedado, siendo honesto

Si tu premisa para auto-hospedar es "va a salir gratis", te vas a decepcionar. Costes reales de auto-hospedar Sentry en proveedor barato:

Compara:

• Versus SaaS Team (R$130/mes): perjuicio de R$300–500/mes. Auto-hospedado en esa etapa es hobby, no economía.
• Versus SaaS Business en uso medio (R$850/mes): economía de R$220–420/mes. Empieza a tener sentido.
• Versus SaaS scale-up (R$2.500/mes): economía de R$1.870–2.070/mes. Ahí vale el esfuerzo.

Para GlitchTip, la cuenta es distinta — el servidor puede ser la mitad del tamaño (2 GB / 1 vCPU, R$30/mes) y el mantenimiento cae a cerca de 1h/mes. Total honesto: R$150–200/mes. Ahí el punto de equilibrio con SaaS Team llega.

Tabla comparativa — 12 criterios

Cuándo quedarse en el SaaS

Cuatro perfiles en que pagar a Sentry todos los meses es la decisión correcta:

Volumen por debajo de 100 mil errores/mes. El plan Team a US$26/mes cubre, sin add-ons. Auto-hospedado de ese tamaño es proyecto de hobby — gastas más tiempo configurando de lo que ahorras.

Equipo de 1 a 3 devs sin capacidad operacional. Cada hora gastada operando Sentry es hora no gastada en el producto. Si aún no contrataste al primer ingeniero de plataforma, paga el SaaS y sigue adelante. La línea "primero contratar SRE para correr Sentry" no es estrategia, es distracción.

Usas Session Replay y Profiling. Son features SaaS-only — auto-hospedar aún no es opción. Si tu workflow de debug depende de esas dos, la discusión termina.

Compliance exige solo LGPD, sin residencia de datos local. Sentry tiene opción de datacenter en la Unión Europea, en conformidad con GDPR y por extensión LGPD. Si tu jurídico acepta transferencia internacional de datos anonimizados, la conformidad no fuerza auto-hospedar.

Cuándo auto-hospedar Sentry tiene sentido

Tres condiciones — necesitas al menos dos para justificar el esfuerzo:

Volumen pasó de 1 millón de errores/mes. Ahí la factura SaaS empieza a competir con salario, y la economía paga el tiempo del dev cuidando de la infraestructura.

Compliance exige datos en servidor controlado. Sectores regulados (salud, financiero, gobierno, educación infantil) frecuentemente tienen cláusula de residencia de datos que vuelve SaaS inviable. Auto-hospedado es el camino.

Equipo tiene 1+ dev con tiempo recurrente para cuidar. "Tiempo recurrente" = al menos 4 horas al mes asignadas explícitamente, con persona nombrada y backup. Si fuera "ah, cualquiera cuida", en tres meses nadie cuida y el sistema se vuelve punto ciego.

Bono: no necesitas Session Replay ni Profiling. Esos dos quedan en el SaaS, así que auto-hospedar significa renunciar a ellos. Para muchos equipos B2B con aplicaciones server-side, esa renuncia es trivial. Para equipos B2C con app mobile/SPA complejo, puede ser deal-breaker.

Cuándo GlitchTip es la mejor elección de las tres

El perfil ideal de GlitchTip es específico:

• Startup con R$10–50k MRR, equipo de 2 a 5 ingenieros.
• Aplicaciones relativamente simples — SaaS B2B, web app, backend de mobile, API.
• No usa Session Replay (o nunca usó, y no siente falta).
• No usa Continuous Profiling.
• Quiere auto-hospedado por el control y la licencia MIT, pero no quiere operar 12 contenedores.
• Ya usa el SDK de Sentry y no quiere reescribir instrumentación.

Si tres de esos cuatro puntos pegan con tu equipo, GlitchTip probablemente ahorra R$500/mes versus SaaS Business sin costar el overhead operacional de Sentry auto-hospedado. Es el caso menos discutido y el más frecuentemente útil.

HeroCtl como capa operacional

Si decidiste auto-hospedar (Sentry o GlitchTip), el cluster donde eso corre importa casi tanto como la elección del producto. Algunas observaciones sobre correr error tracking sobre HeroCtl:

• Job spec con volúmenes persistentes es nativo del producto — Postgres, ClickHouse y Kafka tienen donde grabar datos sin perder nada en un rolling update.
• Backup gestionado está disponible en el plan Business, abarcando bases de datos corriendo como jobs en el cluster. Postgres + ClickHouse entran juntos en el mismo agendamiento.
• Métricas integradas del propio HeroCtl muestran CPU/RAM/IO de cada servicio de Sentry — no necesitas montar Prometheus por fuera solo para saber si ClickHouse está saludable.
• Router integrado con TLS automático cuida del sentry.tuempresa.com sin ningún operador de certificado adicional.
• Plano de control compacto — 200 a 400 MB por servidor, sobra mucho recurso para workload real (Sentry, en el caso).

Para cluster de 4 servidores cloud, eso significa: 8 GB de RAM disponibles en el servidor que aloja Sentry, métricas y backup viniendo gratis del orquestador, y cero operador externo a configurar. El ROI cambia — porque parte del coste "honesto" de auto-hospedado es exactamente la infra que el cluster ya ofrece.

FAQ

¿Cuánto consume de RAM Sentry auto-hospedado? En producción pequeña, 8 GB de RAM es el piso firme — debajo de eso, Kafka empieza a OOM-killar procesos bajo carga. Recomendado: 12 GB para tener holgura. ClickHouse y Kafka son los dos mayores consumidores; juntos suman la mitad de la memoria total.

¿GlitchTip es compatible con el Sentry SDK existente? Sí. GlitchTip implementa el mismo endpoint HTTP que Sentry recibe los eventos. Cambiar la URL en el Sentry.init({ dsn: 'https://...' }) apuntando a tu GlitchTip basta — el SDK no nota diferencia. La migración inversa también es trivial. Los SDKs cubiertos incluyen JavaScript, Python, Go, Ruby, PHP, Java, .NET, iOS, Android y React Native.

¿Puedo migrar de SaaS a auto-hospedado sin perder historial de errores? Técnicamente sí, pero con reservas. Sentry SaaS ofrece exportación de eventos vía API, y el auto-hospedado acepta ingestión. En la práctica, la mayoría de los equipos simplemente no migra historial — empiezan a cero en el nuevo, y mantienen SaaS read-only por unos 90 días para consultar incidentes antiguos cuando necesario. Historial de errores viejo suele tener valor decreciente; lo que importa es lo que pasó en las últimas 4 semanas.

¿Sentry auto-hospedado tiene soporte oficial? No, en ningún nivel. La versión auto-hospedada es "best effort" de la empresa Sentry — publican la release, documentan, pero el soporte técnico solo aparece en los planes pagos del SaaS. La comunidad en GitHub y en el foro oficial es activa, y la mayoría de los problemas comunes ya fue resuelta allí. Para problemas exóticos, estás solo — o contratas una consultoría especializada.

La licencia BSL — ¿puedo usar para SaaS comercial?No. La BSL 1.1 de Sentry prohíbe explícitamente ofrecer Sentry como servicio comercial a terceros. Puedes usar internamente sin límite, en cualquier empresa de cualquier tamaño. Pero si tu idea era incluir "error tracking dedicado" en el paquete de tu cliente cobrando por ello, la licencia bloquea. Para ese caso, GlitchTip (MIT) u otras alternativas open-source MIT son el camino.

¿Cuánto tiempo lleva hacer setup desde cero? Sentry auto-hospedado: 4 a 8 horas para dev experimentado, 2 a 3 días para alguien aprendiendo. GlitchTip: 1 a 2 horas para dev experimentado, medio día para principiante. Esos números cubren instalación limpia, ingestión funcionando, alerta básica configurada, TLS listo. No incluye migración de SDKs (que es trivial) ni ajuste fino de reglas de alerta (que toma semanas en cualquier producto).

¿ClickHouse es realmente necesario, o SQLite sirve? Para Sentry auto-hospedado: ClickHouse es mandatorio. El producto usa la base analítica para queries de agregación que Postgres no da abasto bajo volumen real. Para GlitchTip: el producto usa solo Postgres, y eso es parte del motivo de él ser dramáticamente más ligero. SQLite no sirve para ninguno de los dos en producción.

¿Performance impact en el app cliente? El SDK de Sentry (y de GlitchTip, que usa el mismo SDK) tiene overhead debajo de 1ms en la mayoría de los casos — captura error local, envía en background sin bloquear. En SPAs, el tamaño del bundle añade 30–60 KB gzipped dependiendo de las integraciones. Para apps server-side, el overhead es despreciable. El Performance Monitoring tiene coste ligeramente mayor (sampling de 10% suele ser el default), pero bajo configuración razonable queda debajo de 5ms p99.

Cierre

La pregunta "Sentry SaaS vs auto-hospedado" tiene una respuesta distinta en cada etapa de la empresa. Para startup pequeña, SaaS siempre. Para scale-up con volumen alto y equipo competente, auto-hospedado ahorra dinero real. Para medio de camino, GlitchTip suele ser la elección más lúcida — economía significativa, complejidad operacional manejable, licencia permisiva.

La cuenta es mensurable, no filosófica. Antes de decidir, comprueba tres números:

1. Cuántos errores/mes tu aplicación genera hoy (cualquier dashboard de error tracking muestra).
2. Cuál la factura mensual Sentry proyectada para dentro de 12 meses (multiplica tráfico previsto por el plan correspondiente).
3. Cuántas horas/mes tu equipo puede asignar para operar infraestructura sin perjuicio de producto.

Si número 1 está por encima de 1 millón, número 2 está por encima de R$1.500, y número 3 está por encima de 4 horas — auto-hospedar es decisión financiera sana. Caso contrario, quédate en el SaaS y usa el tiempo ahorrado para entregar feature.

Para correr auto-hospedado (Sentry o GlitchTip) en un cluster que cuida de TLS, backup y métricas sin operador externo:

curl -sSL get.heroctl.com/install.sh | sh

Posts relacionados:

• Observabilidad sin Datadog: stack honesto para startup
• Postgres en producción: gestionado vs auto-hospedado, la cuenta real