Sentry self-hosted vs SaaS: quanto realmente economiza pra startup brasileira

A pergunta chega quase toda semana na caixa de entrada de quem acompanha o blog: vale a pena largar o Sentry SaaS e auto-hospedar? A resposta honesta começa com um "depende" — e a maior parte do conteúdo que circula sobre o assunto trata o "depende" como se fosse evasiva. Não é. Existem três variáveis duras que decidem a conta — volume de eventos, capacidade operacional do time e exigência de compliance — e cada uma delas tem um número que você consegue medir antes de tomar a decisão.

Esse post é a versão longa da resposta. Se você é CTO de uma startup brasileira no estágio entre cinco e cinquenta engenheiros, lendo a fatura do Sentry subir mês a mês, o que vem abaixo serve como uma calculadora explicada — não como sermão a favor ou contra self-hosted. No fim tem uma tabela com doze critérios, uma seção de FAQ pra perguntas que não couberam no corpo do texto, e três perfis bem definidos de quando cada caminho faz sentido.

TL;DR — versão de 30 segundos

Sentry SaaS começa em US$26/mês no plano Team — cobre 50 mil erros/mês e cinco usuários. Pra startup brasileira com tráfego sério, a conta sobe rápido pra faixa de US$80–200/mês (R$400–1.000/mês ao câmbio de R$5/USD), e em scale-up chega tranquilamente em US$300–500/mês (R$1,5k–2,5k/mês). É previsível e não pede nada do time além do cartão de crédito.

Self-hosted é "open-source gratuito" no marketing, mas o software roda dez a doze contêineres — PostgreSQL, Redis, Kafka, ZooKeeper, ClickHouse, Symbolicator e quatro processos Sentry distintos. Pede entre 8 GB de RAM e 4 vCPUs num servidor dedicado, mais armazenamento, backup, atualizações trimestrais e o tempo do dev que cuida disso tudo.

Vale auto-hospedar quando: (a) volume passou de 1 milhão de erros/mês e a fatura SaaS começou a doer, (b) o time tem capacidade operacional pra cuidar de stack complexa sem virar gargalo, ou (c) compliance exige dados em servidor próprio. Não vale pra time de uma a três pessoas focado em produto, ou volume baixo onde o SaaS é só ruído de orçamento.

Meio-termo interessante: GlitchTip — open-source MIT, compatível com o Sentry SDK existente, roda em Postgres + Redis (sem Kafka, sem ClickHouse, sem ZooKeeper). Cobre 80% do valor do Sentry com 20% do overhead operacional.

O que o Sentry SaaS faz bem

Antes de discutir custo, vale reconhecer pelo que você está pagando. O Sentry hospedado entrega uma combinação que é difícil reproduzir em casa sem investir vários trimestres do time:

• Stack pré-configurada. Você cria conta, instala o SDK na aplicação, e em quinze minutos tem erros chegando. Zero servidor, zero arquivo de configuração, zero backup pra agendar.
• Performance Monitoring integrado. Tracing distribuído, n+1 queries detection, slow database queries — tudo no mesmo dashboard onde você já está olhando os erros.
• Session Replay. Gravação anonimizada da sessão do usuário até o momento do erro. Vale ouro pra debugar cenários que não reproduzem em dev.
• Alerting maduro. Integração com Slack, PagerDuty, Microsoft Teams, e-mail e webhooks. Regras finas — alerta só quando taxa de erro dobra em 5 minutos, só em produção, só pra usuários autenticados.
• Issue tracking + sync. Linka issue pro Linear/Jira/GitHub Issues automaticamente. Resolve do lado do tracker, fecha do lado do Sentry.
• Continuous Profiling. Profile em produção sem overhead perceptível, descobrindo gargalos de CPU sem precisar reproduzir localmente. Disponível só na versão SaaS — self-hosted ainda não suporta.
• Suporte técnico. Dependendo do plano, time humano respondendo em até quatro horas úteis.

Esse pacote inteiro custa US$26/mês no plano de entrada. Pra um time de três pessoas começando uma SaaS, é literalmente o melhor uso de R$130/mês que existe na prateleira.

A conta SaaS, linha por linha

A pegadinha do Sentry SaaS não é o preço de entrada — é a curva. Vamos detalhar pra startup brasileira em três estágios diferentes:

Estágio 1 — primeiro produto, R$10–30k MRR.

• Plano Team: US$26/mês (50 mil erros/mês, 5 usuários)
• Total: R$130/mês

Essa é a faixa em que ninguém deveria estar pensando em self-hosted. R$130/mês é quase ruído de orçamento — gastar quatro horas do CTO instalando infraestrutura de monitoração custa mais do que dois anos de assinatura.

Estágio 2 — produto crescendo, R$50–100k MRR.

• Plano Business: US$80/mês (300 mil erros/mês incluídos)
• Performance events extras: US$15–30/mês
• Session Replay: US$25–50/mês
• Usuários adicionais (10 devs): US$50/mês
• Total: US$170–210/mês = R$850–1.050/mês

Aqui a fatura começa a aparecer no relatório financeiro mensal. Não dói ainda, mas você nota.

Estágio 3 — scale-up, R$200k+ MRR, 20+ engenheiros.

• Plano Business com ajustes: US$200–300/mês base
• Performance events: US$50–100/mês
• Session Replay: US$100/mês
• Usuários: US$100/mês
• Total: US$450–600/mês = R$2.250–3.000/mês

Nesse estágio, R$30 mil/ano em error tracking começa a competir com salário parcial de engenheiro. É o ponto em que a conversa "vale auto-hospedar?" deixa de ser teórica e vira reunião marcada.

A dor real do plano Business não é o preço base — é a multiplicação por add-ons. Performance, Replay, Profiling, Cron Monitoring, Code Coverage — cada um vem com sua própria contagem de eventos e sua própria conta. É previsível, mas não é barato.

Sentry self-hosted — o que é exatamente

A pasta oficial getsentry/self-hosted instala uma stack que tem a forma seguinte, em produção:

Soma: cerca de 8 GB de RAM em uso firme num cluster pequeno, 12 contêineres, e isso é o piso. Em volume maior, o Kafka e o ClickHouse ficam com fome bem rápido.

A pegadinha menos discutida é a licença: desde 2019, o Sentry licencia o produto auto-hospedado sob BSL 1.1 (Business Source License). É open-source na forma — você lê o código, modifica, contribui — mas tem uma cláusula que proíbe oferecer Sentry como serviço comercial pra terceiros. Pra empresa que usa internamente, é irrelevante. Pra agência que pensava em incluir error tracking no pacote vendido pro cliente, é proibitivo.

Setup em cluster — passos altos

A documentação oficial assume que você vai rodar ./install.sh num servidor Ubuntu, e em seguida o docker-compose up -d administra a stack. Pra quem opera cluster moderno, o caminho é levemente diferente:

1. Definir job spec com 12 contêineres. O HeroCtl aceita arquivo de configuração de até alguns milhares de linhas, e a tradução do compose oficial pra job spec é mecânica. Reserva um turno de trabalho pra fazer isso direito — incluindo depends_on, health checks, e ordens de boot (ZooKeeper antes de Kafka, Postgres antes de sentry-web, e por aí vai).
2. Volumes persistentes pra Postgres, ClickHouse e Kafka. Os três têm dados que você não pode perder. ClickHouse é o que mais cresce — eventos brutos viram linhas analíticas e o disco enche. Reserve 50 GB de SSD inicial, ajuste pra 200 GB depois de seis meses se o volume justificar.
3. Backup, e backup de cada um separadamente. O erro mais comum em self-hosted é fazer backup só do Postgres, esquecendo que os eventos vivem no ClickHouse. Postgres tem metadados (projeto, usuário, configuração de alerta); ClickHouse tem o histórico de erros. Backup só do Postgres recupera a interface vazia.
4. TLS automático no domínio interno. O painel precisa estar acessível pelos devs com certificado válido — sem -k no curl, sem aviso amarelo no Chrome. O cluster do HeroCtl resolve isso automaticamente com Let's Encrypt; em outros stacks você adiciona um operador ou configura manualmente.
5. Atualizações trimestrais. O Sentry libera versão major a cada três meses, e a auto-hospedada exige migração de schema do Postgres + reindex parcial do ClickHouse. Reserve uma janela de manutenção a cada release — em geral entre 15 minutos e duas horas, dependendo do volume acumulado.

Tempo total de instalação: 4 a 8 horas pra dev competente que conhece o produto, 2 a 3 dias pra alguém aprendendo do zero. Isso é o setup limpo. Adicione 50% pra debugar o caso real (DNS interno errado, volume não montado, Kafka travado por ZooKeeper que demorou pra subir).

GlitchTip — o "Sentry-lite" que muita gente esquece

GlitchTip é a alternativa que aparece pouco em comparativos e merece destaque. É open-source MIT (não BSL) — você usa pra qualquer fim, inclusive comercial, sem cláusula. Foi desenhado especificamente pra cobrir o caso 80/20 do Sentry.

Como funciona o "compatible com Sentry SDK": o SDK do Sentry envia eventos pra um endpoint HTTP padrão. O GlitchTip implementa esse mesmo endpoint. Você troca a URL no Sentry.init({ dsn: ... }) da sua aplicação pra apontar pro GlitchTip e nada mais muda — nem código, nem dependência, nem build. A migração reversa também é direta.

Stack do GlitchTip:

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

São 4 contêineres contra 12 do Sentry. Recursos: 2 GB de RAM, 1 vCPU. Roda confortável num droplet de US$12/mês. Aceita os mesmos SDKs (JavaScript, Python, Go, Ruby, PHP, Java, .NET, mobile) sem mudança.

O que GlitchTip não tem:

• Session Replay
• Continuous Profiling
• Performance Monitoring no nível de detalhe do Sentry (tem versão simplificada)
• Tracing distribuído com waterfall completo
• Code Coverage
• Cron monitoring sofisticado

O que GlitchTip tem:

• Error tracking completo, com agrupamento, frequência, primeiro/último visto
• Stack traces de qualquer linguagem suportada pelos SDKs Sentry
• Uptime monitoring básico
• Alerting via webhook, e-mail e integrações populares
• Issue tracking minimal — atribuir, resolver, ignorar
• Multi-projeto, multi-time, RBAC simples

Pra startup pequena ou média que não usa Replay nem Profiling avançado, GlitchTip cobre o que importa com uma fração da operação. É o caso mais subestimado da prateleira.

A conta self-hosted, sendo honesto

Se a sua premissa pra auto-hospedar é "vai sair de graça", você vai se decepcionar. Custos reais de auto-hospedar Sentry em provedor barato:

Compare:

• Versus SaaS Team (R$130/mês): prejuízo de R$300–500/mês. Self-hosted nesse estágio é hobby, não economia.
• Versus SaaS Business em uso médio (R$850/mês): economia de R$220–420/mês. Começa a fazer sentido.
• Versus SaaS scale-up (R$2.500/mês): economia de R$1.870–2.070/mês. Aí vale o esforço.

Pra GlitchTip, a conta é diferente — o servidor pode ser metade do tamanho (2 GB / 1 vCPU, R$30/mês) e a manutenção cai pra cerca de 1h/mês. Total honesto: R$150–200/mês. Aí o ponto de equilíbrio com o SaaS Team chega.

Tabela comparativa — 12 critérios

Quando ficar no SaaS

Quatro perfis em que pagar a Sentry todo mês é a decisão certa:

Volume abaixo de 100 mil erros/mês. O plano Team a US$26/mês cobre, sem add-ons. Self-hosted desse tamanho é projeto de hobby — você gasta mais tempo configurando do que economiza.

Time de 1 a 3 devs sem capacidade operacional. Cada hora gasta operando Sentry é hora não gasta no produto. Se você ainda não contratou o primeiro engenheiro de plataforma, pague o SaaS e siga em frente. A linha "primeiro contratar SRE pra rodar Sentry" não é estratégia, é distração.

Você usa Session Replay e Profiling. São features SaaS-only — auto-hospedar ainda não é opção. Se a sua workflow de debug depende dessas duas, a discussão termina.

Compliance exige só LGPD, sem residência de dados local. O Sentry tem opção de datacenter na União Europeia, em conformidade com GDPR e por extensão LGPD. Se o seu jurídico aceita transferência internacional de dados anonimizados, a conformidade não força auto-hospedar.

Quando auto-hospedar Sentry faz sentido

Três condições — você precisa de pelo menos duas pra justificar o esforço:

Volume passou de 1 milhão de erros/mês. Aí a fatura SaaS começa a competir com salário, e a economia paga o tempo do dev cuidando da infraestrutura.

Compliance exige dados em servidor controlado. Setores regulados (saúde, financeiro, governo, educação infantil) frequentemente têm cláusula de residência de dados que torna SaaS inviável. Self-hosted é o caminho.

Time tem 1+ dev com tempo recorrente pra cuidar. "Tempo recorrente" = pelo menos 4 horas por mês alocadas explicitamente, com pessoa nomeada e backup. Se for "ah, qualquer um cuida", em três meses ninguém cuida e o sistema vira ponto cego.

Bônus: você não precisa de Session Replay nem Profiling. Esses dois ficam no SaaS, então auto-hospedar significa abrir mão deles. Pra muitas equipes B2B com aplicações server-side, essa abertura de mão é trivial. Pra equipes B2C com app mobile/SPA complexo, pode ser deal-breaker.

Quando GlitchTip é a melhor escolha das três

O perfil ideal do GlitchTip é específico:

• Startup com R$10–50k MRR, time de 2 a 5 engenheiros.
• Aplicações relativamente simples — SaaS B2B, web app, backend de mobile, API.
• Não usa Session Replay (ou nunca usou, e não sente falta).
• Não usa Continuous Profiling.
• Quer self-hosted pelo controle e pela licença MIT, mas não quer operar 12 contêineres.
• Já usa o SDK do Sentry e não quer reescrever instrumentação.

Se três desses quatro pontos batem com o seu time, GlitchTip provavelmente economiza R$500/mês versus SaaS Business sem custar o overhead operacional do Sentry self-hosted. É o caso menos discutido e o mais frequentemente útil.

HeroCtl como camada operacional

Se você decidiu auto-hospedar (Sentry ou GlitchTip), o cluster onde isso roda importa quase tanto quanto a escolha do produto. Algumas observações sobre rodar error tracking sobre HeroCtl:

• Job spec com volumes persistentes é nativo do produto — Postgres, ClickHouse e Kafka têm onde gravar dados sem perder nada num rolling deploy.
• Backup gerenciado está disponível no plano Business, abrangendo bancos de dados rodando como jobs no cluster. Postgres + ClickHouse entram juntos no mesmo agendamento.
• Métricas integradas do próprio HeroCtl mostram CPU/RAM/IO de cada serviço do Sentry — você não precisa montar Prometheus por fora só pra saber se o ClickHouse está saudável.
• Roteador integrado com TLS automático cuida do sentry.suaempresa.com.br sem nenhum operador de certificado adicional.
• Plano de controle compacto — 200 a 400 MB por servidor, sobra muito recurso pra workload real (Sentry, no caso).

Pra cluster de 4 servidores cloud, isso significa: 8 GB de RAM disponíveis no servidor que hospeda o Sentry, métricas e backup vindo de graça do orquestrador, e zero operador externo a configurar. O ROI muda — porque parte do custo "honesto" de self-hosted é exatamente a infra que o cluster já oferece.

FAQ

Quanto consome de RAM o Sentry self-hosted? Em produção pequena, 8 GB de RAM é o piso firme — abaixo disso, o Kafka começa a OOM-killar processos sob carga. Recomendado: 12 GB pra ter folga. ClickHouse e Kafka são os dois maiores consumidores; juntos somam metade da memória total.

GlitchTip é compatível com o Sentry SDK existente? Sim. O GlitchTip implementa o mesmo endpoint HTTP que o Sentry recebe os eventos. Trocar a URL no Sentry.init({ dsn: 'https://...' }) apontando pro seu GlitchTip basta — o SDK não nota diferença. A migração reversa também é trivial. Os SDKs cobertos incluem JavaScript, Python, Go, Ruby, PHP, Java, .NET, iOS, Android e React Native.

Posso migrar de SaaS pra self-hosted sem perder histórico de erros? Tecnicamente sim, mas com ressalvas. O Sentry SaaS oferece exportação de eventos via API, e o self-hosted aceita ingestão. Na prática, a maioria das equipes simplesmente não migra histórico — começam zerados no novo, e mantêm SaaS read-only por uns 90 dias pra consultar incidentes antigos quando necessário. Histórico de erros velho costuma ter valor decrescente; o que importa é o que aconteceu nas últimas 4 semanas.

Sentry self-hosted tem suporte oficial? Não, em nenhum nível. A versão self-hosted é "best effort" da empresa Sentry — eles publicam a release, documentam, mas o suporte técnico só aparece nos planos pagos do SaaS. A comunidade no GitHub e no fórum oficial é ativa, e a maioria dos problemas comuns já foi resolvida lá. Pra problemas exóticos, você está sozinho — ou contrata uma consultoria especializada.

A licença BSL — posso usar pra SaaS comercial?Não. A BSL 1.1 do Sentry proíbe explicitamente oferecer o Sentry como serviço comercial pra terceiros. Você pode usar internamente sem limite, em qualquer empresa de qualquer tamanho. Mas se a sua ideia era incluir "error tracking dedicado" no pacote do seu cliente cobrando por isso, a licença bloqueia. Pra esse caso, GlitchTip (MIT) ou outras alternativas open-source MIT são o caminho.

Quanto tempo leva pra fazer setup do zero? Sentry self-hosted: 4 a 8 horas pra dev experiente, 2 a 3 dias pra alguém aprendendo. GlitchTip: 1 a 2 horas pra dev experiente, meio dia pra iniciante. Esses números cobrem instalação limpa, ingestão funcionando, alerta básico configurado, TLS pronto. Não inclui migração de SDKs (que é trivial) nem ajuste fino de regras de alerta (que toma semanas em qualquer produto).

ClickHouse é mesmo necessário, ou SQLite serve? Pra Sentry self-hosted: ClickHouse é mandatório. O produto usa o banco analítico pra queries de agregação que o Postgres não dá conta sob volume real. Pra GlitchTip: o produto usa só Postgres, e isso é parte do motivo dele ser dramaticamente mais leve. SQLite não serve pra nenhum dos dois em produção.

Performance impact no app cliente? O SDK do Sentry (e do GlitchTip, que usa o mesmo SDK) tem overhead abaixo de 1ms na maioria dos casos — captura erro local, envia em background sem bloquear. Em SPAs, o tamanho do bundle adiciona 30–60 KB gzipped dependendo das integrações. Pra apps server-side, o overhead é desprezível. O Performance Monitoring tem custo levemente maior (sampling de 10% costuma ser o padrão), mas sob configuração razoável fica abaixo de 5ms p99.

Fechando

A pergunta "Sentry SaaS vs self-hosted" tem uma resposta diferente em cada estágio da empresa. Pra startup pequena, SaaS sempre. Pra scale-up com volume alto e time competente, self-hosted economiza dinheiro real. Pra meio do caminho, GlitchTip costuma ser a escolha mais lúcida — economia significativa, complexidade operacional manejável, licença permissiva.

A conta é mensurável, não filosófica. Antes de decidir, confira três números:

1. Quantos erros/mês a sua aplicação gera hoje (qualquer dashboard de error tracking mostra).
2. Qual a fatura mensal Sentry projetada pra daqui 12 meses (multiplique tráfego previsto pelo plano correspondente).
3. Quantas horas/mês o seu time pode alocar pra operar infraestrutura sem prejuízo de produto.

Se número 1 está acima de 1 milhão, número 2 está acima de R$1.500, e número 3 está acima de 4 horas — auto-hospedar é decisão financeira sã. Caso contrário, fique no SaaS e use o tempo poupado pra entregar feature.

Pra rodar self-hosted (Sentry ou GlitchTip) num cluster que cuida de TLS, backup e métricas sem operador externo:

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

Posts relacionados:

• Observabilidade sem Datadog: stack honesta pra startup brasileira
• Postgres em produção: gerenciado vs self-hosted, a conta real