Sentry self-hosted em VPS: produção sem sustos

Resposta direta

Uma VPS para Sentry self-hosted em produção deve começar, na prática, com pelo menos 4 vCPUs, 8 GB de RAM e 100 GB de SSD, usando Docker e Docker Compose conforme o projeto oficial. Para times pequenos, essa base costuma suportar monitoramento de erros de algumas aplicações com retenção curta, por exemplo 7 a 14 dias, desde que a taxa de eventos seja controlada. Ambientes com muitos releases, frontend ruidoso, traces, replays ou retenção acima de 30 dias precisam de mais RAM, disco rápido e planejamento de limpeza. O ponto central não é apenas instalar o Sentry, mas operar Kafka, ClickHouse, Redis, PostgreSQL, workers e tarefas agendadas no mesmo host sem deixar o servidor entrar em swap ou encher o disco durante um pico de erros.

Resumo rápido

Rodar Sentry self-hosted em uma VPS é viável, mas exige tratar a stack como uma plataforma de observabilidade, não como um painel PHP simples. Antes de contratar o servidor, estime quantos projetos enviarão eventos, qual volume diário é aceitável, por quanto tempo os eventos ficarão armazenados e quem ficará responsável por atualização, backup e resposta a incidentes.

• Para produção pequena, use 4 vCPUs, 8 GB de RAM e 100 GB de SSD como ponto de partida mais seguro.
• Para times com várias aplicações, considere 8 vCPUs, 16 GB de RAM e 200 GB ou mais de SSD, de preferência com boa taxa de IOPS.
• Sentry self-hosted usa Docker Compose e vários serviços internos, incluindo PostgreSQL, Redis, Kafka, ClickHouse, Snuba, Relay, workers e cron.
• Retenção de eventos é o principal fator de crescimento do disco, junto com picos de erro em deploys problemáticos.
• Backups devem cobrir banco, arquivos de configuração, secrets, volumes persistentes e um procedimento testado de restauração.
• Se você já estudou VPS para Docker, o Sentry é um caso mais pesado, porque combina containers, filas, banco analítico e ingestão contínua.
• Para logs e busca textual, Sentry não substitui Loki, OpenSearch ou Elasticsearch, ele complementa essas ferramentas no diagnóstico de erros.

Quando faz sentido rodar Sentry self-hosted em VPS

Sentry self-hosted faz sentido quando a equipe quer controle sobre dados de erro, retenção, localização da infraestrutura e previsibilidade operacional. Em empresas que lidam com dados sensíveis, auditoria interna ou restrições contratuais, manter eventos em uma VPS própria pode ser mais confortável do que enviar stack traces, mensagens de exceção, URLs e metadados de usuário para um SaaS externo. Isso não elimina a necessidade de mascarar dados sensíveis no SDK, mas reduz a superfície de terceiros envolvidos no fluxo.

O segundo motivo é custo previsível. Em aplicações com muitos eventos, especialmente frontend web, mobile ou APIs públicas, um bug simples pode gerar milhares de eventos em minutos. No modelo self-hosted, o custo cresce principalmente em CPU, disco e manutenção. Em troca, a equipe assume responsabilidades que no SaaS já vêm resolvidas, como atualização, escalabilidade, retenção, disponibilidade e suporte a incidentes. Não existe almoço grátis aqui. A economia só aparece quando alguém tem maturidade para operar a plataforma.

Controle de dados, custo previsível e autonomia

Um exemplo comum é um time com três APIs Node.js, um painel React e um app mobile. Se cada aplicação enviar 5 mil eventos por dia em períodos normais, a ingestão total fica perto de 25 mil eventos diários. Com retenção de 14 dias, a operação é bem diferente de uma retenção de 90 dias. A primeira pode caber em uma VPS média, enquanto a segunda pede mais disco, limpeza disciplinada e monitoramento do próprio Sentry.

Outra vantagem é a autonomia de integração. A equipe pode configurar projetos, DSNs, alertas, integrações com GitHub ou GitLab e regras de amostragem sem depender de limite comercial específico. Mesmo assim, o Sentry self-hosted não deve virar depósito de todo tipo de telemetria. Logs brutos, métricas e traces de alto volume precisam de ferramentas adequadas. Para logs centralizados, faz mais sentido avaliar uma arquitetura parecida com a descrita em VPS para logs centralizados com Loki, deixando o Sentry focado em erros, releases e contexto de exceções.

Quando o SaaS ainda é mais simples

O SaaS continua sendo a opção mais simples para equipes sem tempo de operação. Se o time tem um único produto, baixa ingestão de eventos e não possui alguém responsável por Linux, Docker, backup e atualização, hospedar por conta própria pode sair mais caro em horas de engenharia. A VPS resolve controle e previsibilidade, mas não remove trabalho. Ela só desloca esse trabalho para dentro do time.

Arquitetura do Sentry self-hosted com Docker

A instalação self-hosted oficial do Sentry usa Docker e Docker Compose para subir um conjunto de serviços. Isso assusta quem espera um único container, porque a plataforma depende de várias peças trabalhando juntas. Em uma instalação típica aparecem PostgreSQL para dados relacionais, Redis para cache e filas, Kafka para ingestão de eventos, ClickHouse para armazenamento analítico, Snuba como camada de consulta, Relay para entrada de eventos, web para interface, workers para processamento assíncrono e cron para tarefas programadas.

Essa arquitetura explica por que uma VPS muito pequena costuma sofrer. Quando todos os serviços rodam no mesmo host, a RAM é disputada por bancos, filas e workers. O disco recebe escrita contínua. A CPU trabalha em rajadas quando há deploy com bug ou pico de tráfego. Em um site pequeno, isso pode passar despercebido. Em uma API com erro em loop, a ingestão aumenta rápido e o Sentry vira uma carga relevante no servidor.

Serviços principais que consomem recursos

ClickHouse costuma ser um dos componentes mais sensíveis a disco e memória, já que armazena e consulta dados de eventos em volume. Kafka também merece atenção, pois lida com filas de ingestão e retenção interna. PostgreSQL não costuma ser o maior consumidor no início, mas precisa de backup consistente e disco confiável. Redis pode parecer leve, até que filas acumuladas e jobs atrasados comecem a pressionar memória.

Um exemplo prático: em uma VPS com 4 vCPUs e 8 GB de RAM, você pode reservar algo como 2 a 3 GB para ClickHouse, 1 GB para PostgreSQL, 512 MB a 1 GB para Redis e Kafka, além do espaço dos serviços web, workers e sistema operacional. Esses números não são limites fixos do Sentry, são uma forma de pensar capacidade. Se o host já roda Nginx, exporters, antivírus, agente de backup e outras aplicações, a margem desaparece.

Como organizar o host para produção

Para produção, evite misturar o Sentry com a aplicação monitorada na mesma VPS. Se a aplicação entra em pane e consome todo o host, você perde também o sistema que deveria mostrar o erro. O ideal é uma VPS dedicada para observabilidade, com Docker instalado, volumes persistentes em disco rápido, firewall restritivo e proxy reverso separado. Quem ainda está estruturando a base de containers deve começar pelo artigo de VPS para Docker, porque os cuidados com volumes, logs do Docker, atualizações e limites de recursos aparecem com força no Sentry.

Também é prudente separar diretórios. Use uma pasta para o projeto self-hosted, outra para backups exportados, outra para scripts operacionais e logs do host. Configure rotação de logs do Docker para evitar que arquivos JSON cresçam sem controle. Uma configuração comum limita logs por container a 10 MB por arquivo e 3 arquivos rotacionados. Parece detalhe, mas em incidentes reais logs locais podem ocupar dezenas de GB antes de alguém perceber.

Dimensionamento de CPU, RAM, disco e rede

O dimensionamento de uma VPS para Sentry self-hosted depende de três perguntas: quantos eventos chegam por dia, por quanto tempo eles ficam retidos e quantas pessoas consultam a interface ao mesmo tempo. Um ambiente pequeno, com até 10 mil eventos por dia e retenção de 7 a 14 dias, pode começar com 4 vCPUs, 8 GB de RAM e 100 GB de SSD. Abaixo disso, especialmente com 2 vCPUs e 4 GB, a instalação pode até subir, mas a margem para produção fica apertada.

Para um time com 50 mil a 150 mil eventos por dia, o salto para 8 vCPUs, 16 GB de RAM e 200 a 400 GB de SSD é mais realista. Se houver picos agressivos, como um deploy frontend quebrado que multiplica eventos por 20 durante alguns minutos, a CPU e as filas precisam absorver a pancada sem travar a interface. O objetivo não é processar tudo instantaneamente, mas evitar backlog permanente, perda de eventos relevantes e pressão contínua em swap.

Configuração mínima realista

A configuração mínima que eu consideraria para produção básica é 4 vCPUs, 8 GB de RAM, 100 GB de SSD, Ubuntu LTS atual, Docker Engine recente e Docker Compose plugin. Reserve pelo menos 20 por cento de disco livre como margem operacional. Em um disco de 100 GB, isso significa tratar 80 GB como teto prático, já descontando sistema, imagens Docker, volumes, backups temporários e logs.

Um exemplo de divisão de uso seria 15 GB para sistema e imagens, 50 GB para dados persistentes do Sentry, 10 GB para backups locais temporários e 5 GB para logs e margem. Se a retenção ou ingestão crescer, esse arranjo fica pequeno rapidamente. Por isso, uma VPS com disco expansível ou upgrade simples ajuda. Cloud Server costuma ser mais flexível nesse ponto do que uma VPS tradicional presa a um plano fixo, mas a disponibilidade de expansão, snapshots e tipo de armazenamento precisa ser conferida no provedor antes da contratação.

Sinais de que o servidor ficou pequeno

Os sinais mais claros são swap constante, load average acima do número de vCPUs por longos períodos, filas atrasadas, interface lenta, consultas que expiram, disco acima de 80 por cento e containers reiniciando. Outro sintoma comum é o Sentry demorar para exibir eventos recém-chegados. Isso sugere gargalo em ingestão, processamento ou consulta.

Na rede, a maior preocupação não costuma ser largura de banda bruta, mas latência e estabilidade. Para aplicações usadas no Brasil, um datacenter brasileiro ou próximo pode reduzir tempo de envio dos eventos e melhorar acesso ao painel. Ainda assim, não adianta escolher apenas pela localização se CPU, disco e suporte operacional forem fracos. Latência ajuda, mas não compensa armazenamento lento nem falta de backup.

Retenção de eventos, armazenamento e banco de dados

Retenção é a alavanca mais importante de custo no Sentry self-hosted. Dois ambientes com a mesma quantidade de aplicações podem exigir servidores totalmente diferentes se um guarda eventos por 7 dias e o outro por 90 dias. O Sentry armazena eventos, issues, releases, breadcrumbs, contexto de ambiente, informações de usuário, tags e dados de consulta. Mesmo com compactação e estruturas otimizadas, o volume cresce quando há muitos projetos, muitos erros repetidos ou payloads grandes.

Uma política saudável começa com perguntas simples. O time realmente consulta erros de três meses atrás? Issues antigas ainda ajudam em debugging? Ambientes de staging precisam da mesma retenção de produção? Para muitos times, 14 a 30 dias resolvem a maior parte das investigações. Eventos mais antigos podem ser menos úteis se o código já mudou, a versão foi substituída e o deploy não existe mais.

Por que retenção muda o custo da VPS

Imagine uma aplicação que envia 20 mil eventos por dia. Se cada evento processado, com índices e metadados, ocupar em média alguns KB no armazenamento final, a diferença entre 14 e 90 dias pode representar dezenas ou centenas de GB ao longo do tempo. O número exato varia conforme payload, anexos, breadcrumbs, tags e configuração de amostragem. Por isso, qualquer estimativa precisa ser validada observando crescimento real do disco durante uma semana normal e uma semana de deploy intenso.

Uma prática simples é criar um painel interno com uso de disco por volume Docker, crescimento diário e alertas em 70, 80 e 90 por cento. O alerta de 70 por cento aciona investigação. O de 80 por cento aciona limpeza ou expansão planejada. O de 90 por cento é quase incidente. Bancos e filas não gostam de disco lotado, e o Sentry pode falhar justamente quando você mais precisa dele.

Disco, IOPS e limpeza programada

SSD é o mínimo aceitável. NVMe pode ajudar quando há muitas escritas e consultas, mas não deve ser tratado como solução mágica. A diferença aparece mais em ingestão alta, consultas pesadas e compactações internas. Para cargas pequenas, CPU e RAM podem ser gargalos antes do disco. Para cargas médias, disco lento vira problema em horários de pico.

Também é bom separar o papel do Sentry de motores de busca e logs. Se o objetivo é pesquisar logs de aplicações por texto livre, correlação ampla e retenção massiva, ferramentas baseadas em OpenSearch ou Elasticsearch têm outro perfil. O artigo sobre VPS para OpenSearch e Elasticsearch ajuda a entender por que heaps de JVM, shards e disco pedem planejamento próprio. Sentry deve receber eventos de erro com contexto rico, não todo log de debug produzido pela aplicação.

Deploy seguro com Docker, proxy e variáveis

O caminho recomendado é seguir o repositório oficial de self-hosted do Sentry, revisar os requisitos atuais e executar a instalação em uma VPS limpa. Em produção, não trate o comando de instalação como um ritual único. Antes de subir o serviço, atualize o sistema, configure usuário não root para operação diária, instale Docker a partir de fonte confiável, habilite firewall e defina DNS do domínio que apontará para a interface, por exemplo sentry.suaempresa.com.br.

As variáveis sensíveis merecem cuidado. Chaves secretas, senhas de banco, tokens de integração e credenciais SMTP não devem aparecer em repositório público, prints de documentação interna ou comandos compartilhados em chat. Use arquivos de ambiente com permissão restrita, cofre de senhas do time ou secret manager quando fizer sentido. Nunca cole chaves reais em exemplos de documentação. Para teste, use valores fictícios.

Boas práticas de instalação

Uma sequência prática seria criar a VPS, apontar o DNS, instalar Docker, clonar o repositório oficial, revisar o arquivo de configuração, definir domínio público, configurar SMTP e executar a instalação. Depois, suba o ambiente com Docker Compose e acompanhe logs dos serviços principais. Não exponha portas internas na internet. A interface web deve passar por proxy reverso, normalmente Nginx, Caddy ou Traefik, com TLS válido.

No Docker, configure rotação de logs. Um daemon sem limite pode gerar arquivos grandes em incidentes. Também monitore imagens antigas e volumes órfãos. Depois de atualizações, rode limpeza com critério, nunca removendo volumes persistentes sem backup. Uma operação segura separa limpeza de imagens, limpeza de containers parados e limpeza de volumes, porque cada comando tem impacto diferente.

TLS, firewall e acesso SSH

O firewall deve liberar apenas SSH, HTTP e HTTPS, ou apenas HTTPS se o certificado já estiver pronto e o proxy redirecionar tráfego. Portas internas de PostgreSQL, Redis, Kafka, ClickHouse e serviços auxiliares não devem ficar públicas. O SSH precisa usar chave, desabilitar senha quando possível e restringir usuários. Fail2ban ou mecanismo equivalente ajuda a reduzir ruído de tentativas automatizadas.

Na camada HTTP, configure limite de upload compatível com os payloads esperados, headers de segurança e redirecionamento para HTTPS. Se a VPS ficar atrás de balanceador ou proxy externo, revise cabeçalhos como X-Forwarded-Proto para o Sentry gerar URLs corretas. Pequenos erros de proxy causam problemas chatos, como links de callback quebrados, cookies inseguros ou redirecionamentos em loop.

Backups, restauração e operação diária

Backup de Sentry self-hosted não é só copiar a pasta do projeto. Você precisa preservar volumes persistentes, banco relacional, dados analíticos relevantes, arquivos de configuração, secrets e conhecimento operacional para restaurar tudo em outra VPS. Um backup sem teste de restauração é apenas uma esperança compactada. Para produção, programe ao menos um teste mensal de restauração em ambiente isolado, medindo tempo total até a interface voltar a abrir e eventos antigos aparecerem.

A frequência depende do uso. Para times pequenos, backup diário pode bastar. Para operação crítica, considere snapshots frequentes do disco combinados com dumps consistentes e cópia externa. Snapshots são úteis para rollback rápido, mas não substituem backup fora do provedor. Se uma exclusão acidental, falha de conta ou problema regional atingir o ambiente, ter cópia em outro destino muda o jogo.

O que realmente precisa entrar no backup

Inclua arquivos de configuração do self-hosted, variáveis de ambiente, secrets, configuração do proxy, scripts de operação, dumps ou volumes dos bancos e metadados necessários para recriar o ambiente. Registre também a versão do Sentry self-hosted usada no momento do backup. Restaurar dados antigos em uma versão muito diferente pode causar incompatibilidades. A documentação interna deve dizer quais comandos rodar, em que ordem e quais verificações confirmam sucesso.

Um exemplo de rotina: backup diário às 3h, cópia criptografada para storage externo, retenção de 7 cópias diárias e 4 semanais, teste de restauração no primeiro sábado do mês. Se o Sentry monitora aplicações críticas, adicione alerta de falha do próprio job de backup. Silêncio não significa sucesso.

Rotina de atualização sem susto

Atualizações precisam de janela planejada. Leia notas da versão, faça snapshot ou backup, confira espaço livre, atualize primeiro em ambiente de teste quando possível e acompanhe logs após subir. Se a equipe depende do Sentry durante deploys, evite atualizar a plataforma no mesmo horário de releases importantes.

Também monitore o próprio Sentry. Use métricas do host, como CPU, RAM, disco, swap, load average e tráfego. Acompanhe containers reiniciando e filas crescendo. Uma configuração simples com node exporter, Prometheus ou agente do provedor já ajuda. O ponto é não descobrir que a VPS está cheia apenas quando alguém tenta abrir um erro crítico e recebe timeout.

Tabela de recursos por cenário de uso

A tabela abaixo traz uma referência editorial para dimensionamento inicial. Ela não substitui teste de carga nem revisão do volume real de eventos, mas ajuda a evitar dois extremos comuns: contratar uma VPS minúscula que entra em swap no primeiro pico ou superdimensionar sem entender a retenção. Os números assumem Sentry self-hosted em host dedicado, Docker Compose, SSD, retenção controlada e tráfego vindo de aplicações em produção.

Cenário	Eventos por dia	Retenção sugerida	VPS inicial	Disco recomendado	Observações operacionais
Projeto pequeno	Até 10 mil	7 a 14 dias	4 vCPUs, 8 GB RAM	100 GB SSD	Bom para 1 a 3 aplicações, com alertas de disco e limpeza ativa
Time em crescimento	10 mil a 150 mil	14 a 30 dias	8 vCPUs, 16 GB RAM	200 a 400 GB SSD	Requer monitoramento de filas, controle de amostragem e backup externo
Produção crítica	Acima de 150 mil	30 dias ou mais	8 a 16 vCPUs, 32 GB RAM	500 GB SSD ou mais	Avaliar separação de componentes, disco rápido e plano de restauração testado
Ambiente de staging	Variável e ruidoso	3 a 7 dias	4 vCPUs, 8 GB RAM	80 a 100 GB SSD	Reduza retenção e filtre eventos repetitivos para não contaminar produção

Na prática, o volume de eventos pode mudar de um dia para o outro. Um deploy com exceção em loop no frontend pode transformar 2 mil eventos diários em 200 mil eventos durante uma tarde. Por isso, configure limites no SDK, ignore erros conhecidos sem valor, aplique sampling quando fizer sentido e separe ambientes. Não envie staging, desenvolvimento local e produção para o mesmo projeto sem tags claras.

Provedores como DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Hetzner, Hostinger, Locaweb, HostGator e LetsCloud podem oferecer VPS ou Cloud Servers capazes de rodar esse tipo de carga, dependendo do plano, região, disco e política de rede. Não publique comparação de preço sem revisão humana, porque valores, promoções, banda, snapshots e disponibilidade regional mudam. Para público brasileiro, localidade, latência, cobrança em reais e suporte podem pesar, mas cada item precisa ser confirmado nas páginas oficiais no momento da contratação.

Recomendações por perfil

Dev solo ou projeto pequeno

Para um dev solo que quer monitorar um SaaS pequeno, um painel administrativo e talvez uma API, a melhor escolha é começar simples, mas não frágil. Use uma VPS dedicada com 4 vCPUs, 8 GB de RAM e 100 GB de SSD. Configure retenção de 7 a 14 dias, alerte em 70 por cento de disco e filtre erros barulhentos no SDK. Evite colocar Sentry, banco da aplicação e aplicação principal no mesmo servidor. Essa economia costuma cobrar juros durante incidentes. Se o orçamento estiver apertado, reduza retenção antes de reduzir RAM.

Time de produto com aplicações em produção

Um time com várias aplicações, releases frequentes e plantão técnico deve mirar 8 vCPUs, 16 GB de RAM e pelo menos 200 GB de SSD. Aqui, o Sentry já vira parte da rotina de engenharia. Integre releases, commits e ambientes, defina ownership de issues e mantenha uma pessoa responsável pela operação da plataforma. Configure backup externo, teste restauração e revise volume de eventos depois de cada grande release. Se frontend gerar muito ruído, ajuste sampling e ignore erros causados por extensões de navegador, bots ou navegadores sem suporte.

Produção crítica com retenção longa

Para produção crítica, a conversa muda. Se o Sentry precisa estar disponível durante incidentes relevantes, pense em 8 a 16 vCPUs, 32 GB de RAM e 500 GB ou mais de SSD, com possibilidade de expansão. Avalie separar componentes pesados, usar disco de maior desempenho e manter plano de recuperação documentado. Retenção de 30, 60 ou 90 dias deve ser justificada por uso real, auditoria ou necessidade de investigação. Se a equipe não tem capacidade de operar essa stack, o SaaS ou uma solução gerenciada pode ser mais seguro do que uma VPS mal mantida.

Empresas com exigência de dados no Brasil

Empresas que preferem manter dados em infraestrutura nacional devem avaliar provedores com datacenter no Brasil ou região próxima, mas sem olhar apenas para o mapa. Confirme tipo de disco, política de backup, snapshots, banda, suporte, SLA e expansão de recursos. LetsCloud pode entrar na análise quando a exigência envolver infraestrutura brasileira ou cobrança local, mas recursos como NVMe, snapshots e localidades específicas devem ser verificados por plano antes de qualquer decisão. Para Sentry, previsibilidade operacional pesa tanto quanto latência.

Equipes que já usam stack de observabilidade

Se a equipe já usa Loki, Prometheus, Grafana, OpenSearch ou Elasticsearch, posicione o Sentry como camada de erro e contexto de release. Não tente substituir logs centralizados por eventos do Sentry, nem transformar Elasticsearch em ferramenta principal de exceções sem workflow de issues. Cada peça tem função. Sentry responde bem a perguntas como qual release introduziu este erro e quais usuários foram afetados. Logs respondem melhor a o que aconteceu antes e depois em todos os serviços. A VPS deve refletir essa divisão, com cargas separadas sempre que o volume justificar.