Como escolher VPS para PostHog self-hosted

Resposta direta

Para rodar PostHog self-hosted em VPS, pense menos em painel de analytics e mais em pipeline de eventos. Um ambiente pequeno pode começar com 4 vCPUs, 8 GB de RAM e 160 GB de SSD, mas produção com tráfego real costuma pedir 8 vCPUs, 16 GB de RAM, disco NVMe ou SSD rápido e política clara de retenção. O ponto mais sensível é o ClickHouse, banco colunar usado para consultas analíticas e armazenamento de eventos. Se a aplicação envia muitos eventos por usuário, o gargalo aparece em disco, memória e ingestão antes de aparecer na interface. Para uso sério, monitore CPU, I/O, filas, espaço livre, backups testados e limite a retenção de eventos conforme necessidade de produto.

Resumo rápido

• PostHog self-hosted exige mais planejamento que Matomo ou ferramentas simples de web analytics, porque armazena eventos de produto em alto volume.
• Para laboratório ou validação, use pelo menos 4 vCPUs, 8 GB de RAM e 160 GB de SSD, com retenção curta e poucos projetos.
• Para produção inicial, considere 8 vCPUs, 16 GB de RAM e 300 GB ou mais de disco rápido, principalmente se houver autocapture ativo.
• ClickHouse é o componente mais crítico. Consultas, compressão, merges e ingestão dependem bastante de CPU, RAM e I/O.
• Retenção de 30, 90 ou 180 dias muda completamente o custo de disco e backup, mesmo com a mesma quantidade de usuários.
• Backup precisa incluir banco transacional, configuração e estratégia para dados analíticos, não apenas snapshot ocasional da VPS.
• Datacenter próximo ao público brasileiro ajuda na latência de captura, mas não substitui tuning, filas e boa política de eventos.

O que muda ao rodar PostHog self-hosted em VPS

Rodar PostHog self-hosted em VPS é uma decisão de controle. Você passa a controlar onde os eventos ficam, como a retenção é definida, quais integrações são ativadas e qual orçamento será gasto em infraestrutura. Em troca, também assume a operação de uma pilha bem mais exigente do que um blog WordPress ou uma API simples. PostHog combina interface web, captura de eventos, processamento assíncrono, banco relacional, Redis, filas e ClickHouse. O resultado é poderoso, mas a VPS precisa ser escolhida pensando em carga contínua, não só em acesso humano ao painel.

PostHog não é só um painel de analytics

Um erro comum é comparar PostHog com ferramentas tradicionais de métricas de página. O PostHog é uma plataforma de product analytics. Ele pode receber pageviews, cliques, eventos customizados, feature flags, sessões, funis, cohorts e gravações, dependendo da configuração. Se o SDK estiver com autocapture habilitado em um SaaS com 20 mil usuários mensais, o volume de eventos pode crescer rápido. Um único usuário pode gerar dezenas ou centenas de eventos por sessão. Isso muda a conta de CPU, disco e retenção.

Se o seu objetivo é analytics web mais clássico, vale comparar com alternativas antes de dimensionar. O guia de VPS para Matomo Analytics self-hosted no Brasil ajuda a entender um cenário com outro perfil de carga. Matomo costuma ser mais simples para tráfego web tradicional. PostHog faz mais sentido quando o time quer analisar comportamento dentro do produto, medir ativação, acompanhar funis e cruzar eventos com propriedades de usuário.

VPS tradicional, Cloud Server e cloud instance

Na prática, você pode rodar PostHog em uma VPS tradicional, em um Cloud Server ou em uma cloud instance de provedores globais. A diferença está na elasticidade, no painel, no tipo de storage, nas opções de snapshot e na facilidade de upgrade. Uma VPS simples pode funcionar para validação. Um Cloud Server com upgrade rápido, disco consistente e rede estável tende a ser melhor quando o produto começa a depender dos dados. LetsCloud, DigitalOcean, Vultr, Hetzner, Linode e AWS Lightsail podem entrar na análise, mas disponibilidade de região, storage, backup, preço e recursos variam por plano e precisam ser conferidos no site oficial antes da compra.

Requisitos de CPU, RAM e disco para PostHog

O dimensionamento de VPS para PostHog self-hosted precisa começar por três perguntas: quantos eventos serão recebidos por dia, por quanto tempo eles serão mantidos e quantas pessoas farão consultas no painel. Essas variáveis pesam mais do que número bruto de visitantes. Um produto B2B com 5 mil usuários ativos pode gerar mais eventos relevantes do que um site com 100 mil visitas, caso rastreie ações internas, etapas de onboarding, uso de recursos, cliques em botões e eventos de backend.

Ambiente pequeno

Para laboratório, prova de conceito ou produto em validação, uma configuração de 4 vCPUs, 8 GB de RAM e 160 GB de SSD é um ponto de partida mais seguro que planos mínimos de 1 ou 2 GB. Dá para testar ingestão, dashboards, funis e alguns eventos customizados sem transformar cada consulta em espera longa. Nesse cenário, limite a retenção para 30 dias, evite gravação de sessão se não for essencial e monitore espaço em disco desde o primeiro dia. Uma configuração menor até pode subir os containers, mas tende a sofrer quando ClickHouse faz merges, quando há picos de ingestão ou quando várias consultas rodam ao mesmo tempo.

Um exemplo simples: um SaaS em beta com 1.000 usuários ativos mensais, 20 eventos por usuário por dia e retenção de 30 dias teria algo perto de 600 mil eventos no período, sem contar eventos de sistema. Isso é viável em um nó único bem configurado. Se o autocapture estiver agressivo e esse número subir para 100 eventos por usuário por dia, o mesmo período já passa de 3 milhões de eventos. A interface continua parecida, mas o consumo de disco e CPU muda bastante.

Produção com tráfego real

Para produção inicial, mire em 8 vCPUs, 16 GB de RAM e 300 GB a 500 GB de SSD rápido ou NVMe quando disponível no plano e na localidade. Essa configuração dá margem para ClickHouse, Postgres, Redis, workers e interface web conviverem sem disputa constante por memória. O ideal é manter swap configurado apenas como proteção, não como parte normal da operação. Se o servidor usa swap o tempo todo, o painel fica lento e os processos de ingestão começam a atrasar.

Times que já usam Metabase, pipelines de dados ou dashboards internos devem prestar atenção ao padrão de consulta. Analytics de produto é diferente de BI tradicional, mas os gargalos conversam entre si. O artigo sobre VPS para Metabase e BI self-hosted mostra como consultas analíticas podem pressionar CPU, RAM e banco mesmo quando a interface parece leve. No PostHog, esse efeito aparece em funis longos, cohorts grandes, filtros por propriedades e janelas de tempo extensas.

Quando separar serviços

A partir do momento em que a ingestão fica constante, separar o ClickHouse em uma instância dedicada começa a fazer sentido. Uma arquitetura comum é manter aplicação, Redis e Postgres em uma VPS e mover ClickHouse para outra máquina com mais disco e I/O. Outra opção é manter tudo em uma cloud maior por simplicidade operacional, mas isso tem limite. Se o disco passa de 70 por cento de uso, se merges do ClickHouse ficam atrasados ou se consultas travam a ingestão, o nó único deixou de ser confortável.

ClickHouse, ingestão de eventos e retenção de dados

ClickHouse é o coração técnico do PostHog self-hosted. Ele foi desenhado para cargas analíticas colunares, com leitura rápida em grandes volumes e boa compressão. Isso combina com eventos de produto, porque você consulta intervalos de tempo, propriedades, usuários, funis e agregações. Só que essa eficiência não elimina custo de infraestrutura. ClickHouse precisa de disco rápido, CPU para merges e memória suficiente para consultas. Se a VPS for escolhida apenas pelo preço mensal mais baixo, a economia aparece como lentidão no painel, filas crescendo e risco de ficar sem espaço.

Por que o ClickHouse vira o centro do projeto

Em um PostHog com tráfego real, a interface web raramente é o maior problema. O trabalho pesado está em receber eventos, gravar em buffers, processar lotes, armazenar no ClickHouse e responder consultas. Durante o dia, a ingestão pode subir em horários de pico. À noite, tarefas de manutenção, compressão e merges continuam consumindo I/O. Por isso, métricas como IOPS, latência de disco, throughput de escrita e uso de CPU importam tanto quanto quantidade de RAM.

Um exemplo prático: se sua aplicação envia 2 milhões de eventos por dia, com retenção de 90 dias, você estará mantendo cerca de 180 milhões de eventos antes de considerar compressão, índices, metadados, eventos duplicados e crescimento. ClickHouse comprime bem, mas não existe compressão mágica para má modelagem de eventos. Eventos com muitas propriedades, strings longas, payloads grandes e cardinalidade alta podem aumentar custo de armazenamento e piorar consultas. A equipe deve padronizar nomes de eventos, evitar propriedades desnecessárias e revisar o que realmente precisa ser capturado.

Para quem está planejando analytics em tempo real além do PostHog, o guia de Cloud Server para ClickHouse e analytics em tempo real aprofunda pontos como disco, particionamento, CPU e perfil de consulta. Essa leitura é útil porque o PostHog abstrai parte da complexidade, mas não muda a natureza do ClickHouse. O banco continua precisando de infraestrutura coerente.

Como pensar em retenção

Retenção é uma decisão de produto e de custo. Guardar tudo para sempre parece confortável, até o disco crescer mais rápido que o orçamento. Para um produto em validação, 30 dias podem ser suficientes para analisar ativação, bugs de onboarding e uso inicial. Para um SaaS B2B com ciclos comerciais longos, 90 ou 180 dias podem ser necessários. Para auditoria ou análise anual, talvez faça sentido exportar dados agregados ou arquivar eventos brutos em armazenamento externo, em vez de manter tudo quente no ClickHouse.

Uma regra prática: defina retenção antes de abrir a captura para todos os usuários. Se você começar com autocapture amplo, sessão gravada e eventos customizados sem limite, será difícil reduzir custo depois sem apagar histórico. Também vale separar eventos críticos de eventos exploratórios. Eventos como signup_completed, project_created e subscription_started merecem retenção maior. Eventos de clique em elemento temporário de interface podem ter retenção curta ou nem ser enviados.

Arquitetura prática em uma VPS e quando evoluir

A arquitetura mais comum para começar com PostHog self-hosted é nó único via Docker, com todos os serviços na mesma VPS. É simples de instalar, fácil de entender e reduz custo operacional. Para um time pequeno, essa simplicidade vale bastante. O problema é que nó único concentra falhas. Se o disco lota, tudo para. Se ClickHouse consome CPU demais, a interface sofre. Se o backup é mal planejado, a restauração vira tentativa e erro em um momento de pressão.

Instalação em nó único

Em uma VPS de produção inicial, reserve recursos pensando nos containers principais. Uma base razoável é Ubuntu LTS, Docker atualizado, firewall liberando apenas portas necessárias, proxy reverso com TLS e monitoramento de uso de CPU, RAM, disco e containers. Em vez de expor serviços internos, deixe público apenas HTTPS na porta 443 e, se necessário, SSH restrito por IP ou chave. Postgres, Redis e ClickHouse não devem ficar abertos para a internet.

Uma configuração prática para começar seria: 8 vCPUs, 16 GB de RAM, 400 GB de SSD ou NVMe, swap de 4 GB como proteção, volume separado para dados persistentes e alertas quando disco passar de 70 por cento. Não trate snapshot da máquina como único backup. Snapshot ajuda em rollback rápido, mas não substitui exportações consistentes e testes de restauração. Também é prudente limitar logs do Docker, por exemplo com rotação de 100 MB por arquivo e poucos arquivos mantidos. Logs esquecidos conseguem encher disco antes dos eventos.

Na camada de aplicação, revise o SDK. Não capture campos sensíveis, tokens, e-mails desnecessários em texto livre ou payloads com dados pessoais sem base legal e consentimento. Se o produto atende usuários no Brasil, a LGPD entra na conversa. PostHog pode ser self-hosted, mas self-hosted não significa automaticamente compatível com privacidade. Você precisa definir finalidade, retenção, acesso interno e processo de exclusão.

Sinais de que chegou a hora de escalar

O melhor sinal não é uma queda completa, é degradação repetida. Se consultas simples demoram mais de 10 ou 15 segundos, se workers acumulam backlog, se o load average fica alto por horas, se o disco cresce de forma imprevisível ou se o ClickHouse mostra merges atrasados, chegou a hora de rever a arquitetura. A primeira evolução costuma ser aumentar verticalmente a VPS. A segunda é separar ClickHouse. A terceira é criar uma arquitetura mais próxima de cluster, com serviços isolados e políticas claras de manutenção.

Também observe o comportamento do time. Se cinco pessoas abrem funis pesados durante o horário comercial enquanto a aplicação recebe eventos, a infraestrutura precisa lidar com ingestão e leitura ao mesmo tempo. Nesse ponto, uma VPS barata com CPU compartilhada pode não entregar previsibilidade. Não é apenas questão de média de uso. Picos curtos de CPU roubada, I/O instável ou throttling podem gerar sintomas difíceis de diagnosticar.

Backup, segurança e manutenção operacional

PostHog self-hosted concentra dados sensíveis sobre comportamento de usuários. Isso exige uma rotina operacional mais séria que apenas manter a aplicação online. Segurança começa no acesso ao servidor, passa por rede, criptografia, atualização de pacotes, gerenciamento de segredos, permissões internas e termina em backup testado. Se o time não tem disciplina para restaurar um ambiente em uma VPS nova, o risco de perda de dados é maior do que parece.

Backups que realmente podem ser restaurados

Um plano mínimo de backup deve cobrir configuração, banco relacional, dados persistentes e estratégia para ClickHouse. Snapshots da VPS ajudam, mas podem capturar dados em estado inconsistente se feitos durante escrita intensa. Para Postgres, use dumps ou backup físico apropriado. Para ClickHouse, consulte a documentação oficial e teste o método escolhido em ambiente separado. O objetivo não é apenas ter arquivos de backup, é conseguir subir uma nova instância e validar login, dashboards, eventos recentes e consultas históricas.

Uma rotina realista para produção inicial pode ser: snapshot diário com retenção curta para rollback, backup lógico de Postgres diariamente, backup ou exportação planejada de ClickHouse conforme volume, cópia fora da mesma máquina e teste mensal de restauração. Se o volume de eventos for grande, backup completo diário do ClickHouse pode ficar caro e lento. Nesse caso, retenção menor, exportação incremental ou arquitetura de armazenamento externo precisam entrar no desenho.

Hardening básico para produção

No sistema operacional, use chaves SSH, desative login por senha, mantenha firewall ativo e limite portas expostas. Atualize pacotes regularmente, mas evite atualizar a pilha inteira sem janela de manutenção. Docker e imagens também precisam de revisão. Variáveis de ambiente com segredos não devem aparecer em repositórios, prints, documentação pública ou tickets. Se possível, use um cofre de segredos ou, no mínimo, arquivos protegidos por permissão adequada.

Na aplicação, controle quem acessa o PostHog. Analytics de produto pode revelar receita, comportamento de clientes, funis de conversão e dados operacionais. Crie contas individuais, remova usuários antigos e use autenticação forte quando disponível. Também revise eventos enviados pelo frontend. Não envie senha, token, documento, cartão, cabeçalho de autenticação ou conteúdo privado de formulário. Um erro de instrumentação pode transformar o ClickHouse em depósito de dados que nunca deveriam ter sido coletados.

Monitoramento fecha o ciclo. Configure alertas para CPU sustentada acima de 80 por cento, RAM próxima do limite, uso de swap, disco acima de 70 e 85 por cento, containers reiniciando e latência de resposta do painel. Se o provedor oferece métricas nativas, use como primeira camada. Para ambientes mais maduros, Prometheus, Grafana e alertas externos ajudam a detectar problemas antes que o time de produto perceba dados atrasados.

Comparativo de perfis de infraestrutura

A escolha da VPS para PostHog self-hosted fica mais simples quando você separa perfis. Não existe uma configuração universal, porque cada produto captura eventos de forma diferente. Um e-commerce pode gerar muitos eventos anônimos de navegação. Um SaaS B2B pode ter menos usuários, mas eventos ricos e consultas complexas por conta, plano e funcionalidade. Um app mobile pode ter picos por campanha. A tabela abaixo não substitui teste de carga, mas dá uma base prática para conversar com desenvolvimento, produto e financeiro.

Tabela de dimensionamento

Perfil de uso	Eventos estimados	VPS ou Cloud Server sugerido	Retenção prática	Pontos de atenção
Laboratório e validação	Até 500 mil eventos por mês	4 vCPUs, 8 GB RAM, 160 GB SSD	30 dias	Evitar autocapture amplo, sem sessão gravada contínua, monitorar disco semanalmente
Produção inicial	1 a 10 milhões de eventos por mês	8 vCPUs, 16 GB RAM, 300 a 500 GB SSD ou NVMe	30 a 90 dias	Alertas de I/O, backups testados, rotação de logs, revisão de eventos customizados
Produto em crescimento	10 a 50 milhões de eventos por mês	8 a 16 vCPUs, 32 GB RAM, 1 TB de disco rápido ou ClickHouse separado	60 a 180 dias	Separar ClickHouse, limitar consultas pesadas, planejar arquivamento
Analytics crítico	Acima de 50 milhões de eventos por mês	Arquitetura dedicada com ClickHouse isolado e storage planejado	Conforme política de dados	Teste de carga, observabilidade, restauração ensaiada, revisão humana de custos

Como interpretar os perfis

Use a tabela como ponto de partida, não como promessa de capacidade. Dois ambientes com 10 milhões de eventos por mês podem se comportar de formas bem diferentes. Eventos pequenos, com poucas propriedades e baixa cardinalidade, comprimem melhor e consultam mais rápido. Eventos com payloads grandes, propriedades variadas e filtros complexos exigem mais do ClickHouse. O mesmo vale para número de usuários internos. Uma pessoa olhando dashboards simples pesa pouco. Um time inteiro criando funis longos em janelas de 180 dias pesa muito mais.

Provedores também variam. DigitalOcean, Vultr, Linode, Hetzner, AWS Lightsail, Locaweb, Hostinger, HostGator e LetsCloud possuem propostas diferentes de painel, localidade, cobrança, storage e suporte. Não publique decisão apenas por preço de vitrine. Preço, franquia de transferência, tipo de disco, região brasileira, snapshots, backup automático e SLA são dados voláteis e devem ser verificados nas páginas oficiais no dia da contratação. LetsCloud pode fazer sentido quando localidade no Brasil, cobrança nacional ou proximidade com usuários brasileiros for requisito, mas recursos como NVMe, snapshots e backups precisam ser confirmados por plano e localidade.

Um bom teste antes de migrar produção é criar um ambiente espelho com volume sintético. Envie eventos simulados por alguns dias, execute consultas reais, observe crescimento de disco e meça tempo de resposta dos dashboards. Se o ambiente já sofre no teste controlado, não espere que melhore com usuários reais. Infraestrutura analítica costuma degradar aos poucos, até o dia em que uma campanha, release ou bug de instrumentação multiplica o volume de eventos.

Recomendações por perfil

Dev solo ou produto em validação

Se você é dev solo ou está validando um produto, comece simples, mas não comece pequeno demais. Uma VPS com 4 vCPUs, 8 GB de RAM e 160 GB de SSD permite testar PostHog com mais folga que planos básicos. Use retenção de 30 dias, desative captura que não será analisada e crie poucos dashboards. O foco nessa fase é aprender quais eventos importam: signup_started, signup_completed, workspace_created, invite_sent e activation_reached, por exemplo. Evite transformar o PostHog em lixeira de cliques. Faça backup básico, documente instalação e mantenha uma forma de recriar o ambiente do zero.

Time pequeno com produto em crescimento

Para um time pequeno com SaaS em produção, a escolha mais equilibrada costuma ser 8 vCPUs, 16 GB de RAM e 300 GB a 500 GB de disco rápido. Essa configuração atende muitos produtos em fase inicial, desde que a instrumentação seja disciplinada. Defina dono dos eventos, padronize nomes e revise propriedades antes de enviar tudo para produção. Configure alertas de disco, CPU e containers. Também vale separar ambientes: não use o mesmo PostHog para testes bagunçados e analytics oficial. Se o time usa dados para priorizar roadmap, a confiabilidade da coleta precisa ser tratada como parte do produto.

Produção crítica com dados de produto

Quando PostHog vira ferramenta diária de produto, growth, suporte ou receita, planeje além de uma única VPS. Considere ClickHouse separado, mais RAM, disco de alta performance, backups testados e política formal de retenção. Uma base comum é 16 vCPUs, 32 GB de RAM e 1 TB de disco rápido para a camada analítica, ajustando conforme eventos e consultas. Para cargas maiores, avalie arquitetura dedicada e revisão humana de custo. Também crie processo de mudança para eventos. Um deploy que duplica eventos por acidente pode gerar custo, lentidão e ruído analítico. Em produção crítica, governança de dados vale tanto quanto CPU.

Agência ou consultoria que atende vários clientes

Agências que querem oferecer analytics self-hosted para vários clientes precisam tomar cuidado com isolamento. Colocar todos os clientes no mesmo PostHog pode parecer econômico, mas complica permissões, retenção, privacidade e restauração. Em muitos casos, é melhor separar instâncias por cliente relevante ou por faixa de criticidade. Para clientes pequenos, uma VPS de 4 vCPUs e 8 GB pode bastar com retenção curta. Para clientes com produto digital ativo, trate como produção inicial. Documente quem acessa o quê, como eventos são nomeados e qual o prazo de retenção contratado. Sem esse controle, a operação fica difícil de sustentar.

Empresa com requisitos de privacidade e compliance

Empresas com LGPD, contratos corporativos ou dados sensíveis devem começar pelo mapa de dados. Antes de escolher CPU e disco, defina quais eventos podem ser coletados, quais propriedades são permitidas, quem acessa os dashboards e como usuários podem solicitar exclusão. Depois disso, escolha a infraestrutura. Datacenter no Brasil pode ajudar em requisitos de latência e preferência de residência, mas não resolve compliance sozinho. Use HTTPS, controle de acesso, logs de administração, backups protegidos e processo de descarte. Se houver dados pessoais em eventos, reduza payloads e prefira identificadores internos. Quanto menos dado sensível entra, menor o risco operacional.