PostHog self-hosted em VPS: analytics de produto vale o trabalho?

PostHog em VPS vale a pena quando você precisa entender eventos, funis, flags ou replay e consegue operar a pilha inteira. Para medir só visitas, ou para um micro-SaaS dentro da franquia Cloud, a versão gerenciada tende a ser mais racional. Self-hosted não é um contador de pageviews barato: é uma operação de dados.

A licença open source e o Docker Compose podem sugerir um atalho. Não são. O PostHog resolve perguntas de produto que um contador de visitas não resolve, mas troca mensalidade por responsabilidade técnica.

A decisão começa antes da VPS: quais eventos precisam orientar uma decisão real? Se a resposta for vaga, a infraestrutura será apenas mais uma coisa para atualizar num sábado.

A decisão começa pelo evento que muda o produto, não pela compra do servidor.

PostHog em VPS vale a pena? A resposta curta

Vale quando a equipe precisa de analytics de produto e aceita manter infraestrutura. O PostHog mede comportamento por eventos, com autocapture ou instrumentação manual, e permite analisar esse comportamento em visualizações ou SQL. O projeto também separa esse uso de web analytics, voltado a tráfego, sessões, conversão, web vitals e receita. Essa distinção aparece no repositório oficial do PostHog.

Portanto, a pergunta não é “uma VPS sai mais barata?”. A pergunta é se cadastro, ativação, uso de recurso, conversão ou abandono precisam virar decisões de produto. Se você só quer saber de onde veio o tráfego, PostHog pode ser uma pilha grande demais.

A própria documentação orienta a maioria dos usuários para Cloud. Para projetos abaixo de 1 milhão de eventos mensais e 5 mil recordings, a recomendação é considerar a franquia Cloud. A página oficial de preços informa uma franquia mensal de 1 milhão de eventos de Analytics, 5 mil recordings e 1 milhão de requisições de feature flags. Os limites reiniciam mensalmente e podem mudar, então precisam de nova checagem antes da publicação.

Isso não elimina o self-host. Há casos de autonomia técnica, preferência por operar os próprios dados ou necessidade de uma arquitetura específica. Só elimina a ideia de que VPS é automaticamente a escolha econômica para todo micro-SaaS.

PostHog resolve analytics de produto, não apenas tráfego

Analytics de produto acompanha ações que importam para o produto. Um evento pode ser uma conta criada, uma integração concluída, uma função usada ou uma assinatura iniciada. O valor está em ligar essas ações a uma pergunta concreta: onde a ativação falha? Qual fluxo antecede a conversão? Que recurso fica abandonado?

Esse tipo de análise justifica funis, feature flags e session replay quando eles ajudam a mudar uma decisão de produto. Sem essa pergunta, o dado acumulado vira painel decorativo. É por isso que uma ferramenta mais completa não é automaticamente uma ferramenta melhor.

Quando eventos e funis justificam a ferramenta

PostHog faz sentido quando o produto tem etapas que precisam ser observadas. Um SaaS pode acompanhar cadastro, primeira configuração e uso recorrente. Uma aplicação com experimento pode usar feature flags. Um fluxo difícil de reproduzir pode exigir replay, desde que os dados exibidos sejam revisados.

A leitura do Runzos é direta: a ferramenta deve ser escolhida pela decisão que ela permite tomar. Não pelo desejo de ter um dashboard parecido com o de empresas maiores.

Quando Plausible, Umami ou Matomo fazem mais sentido

Para tráfego, origem e conversão de site, uma solução de web analytics pode ser suficiente. O Plausible CE é uma opção AGPL auto-hospedada, mas também transfere manutenção, upgrades, capacidade, uptime, backup, segurança e estabilidade ao operador.

O Umami documenta uma instalação por Docker Compose com aplicação e PostgreSQL. Isso pode ser uma pilha mais simples quando eventos, funis e replay não são necessários. Já o Matomo On-Premise mantém documentação própria para requisitos, autoarquivamento, segurança, atualização, desempenho e arquitetura escalável.

Não é um ranking de “melhor ferramenta”. É uma escolha entre o trabalho que você quer fazer e o dado que precisa obter.

A arquitetura real que uma VPS assume

O self-host oficial do PostHog é distribuído via Docker Compose sob licença MIT. Para planejamento, a documentação recomenda uma VM Ubuntu equivalente a 4 vCPU, 16 GB de RAM e mais de 30 GB de armazenamento. O instalador hobby alerta para 8 GB ou mais, mas isso não transforma 8 GB em recomendação de produção. O requisito conservador é o que deve orientar a decisão, conforme a documentação de self-host.

O Compose hobby oficial não descreve um único container. Ele lista PostgreSQL, Redis, Valkey, ClickHouse, ZooKeeper, Kafka, web e worker, além de componentes relacionados a armazenamento de objetos e replay. Você pode conferir a composição no arquivo oficial do Compose hobby.

Banco analítico, mensageria e armazenamento persistente

PostgreSQL é o banco relacional da pilha. ClickHouse entra como banco analítico de eventos. Kafka e ZooKeeper participam da mensageria e coordenação. Redis e Valkey atendem funções de cache ou fila. Cada item adiciona volume persistente, atualização e um novo lugar onde uma falha pode aparecer.

Session replay amplia essa responsabilidade. No deployment hobby, os replays usam armazenamento de blobs. Quando o object storage é usado, a retenção precisa ser definida por lifecycle policies do provedor de blobs. Não existe segurança implícita em guardar tudo para sempre.

Proxy e endpoints que precisam continuar acessíveis

Colocar o painel atrás de proxy não é apenas apontar um domínio. A documentação exige a configuração apropriada de IS_BEHIND_PROXY, proxies confiáveis e, quando aplicável, ALLOWED_HOSTS. Os endpoints de ingestão e assets do cliente precisam permanecer publicamente acessíveis para captura, replay e flags. A referência é a documentação sobre PostHog atrás de proxy.

Essa é a fronteira entre “subir containers” e operar um serviço. Domínio, HTTPS, regras de proxy e observabilidade fazem parte do produto que você está oferecendo aos próprios usuários.

Backup, retenção e teste de restore

Backup só ajuda se o restore tiver sido pensado e testado. Para essa pilha, isso inclui os dados persistentes que realmente sustentam a operação, não apenas uma cópia do arquivo Compose. Também exige definir por quanto tempo replays ficam armazenados.

O Runzos chama essa disciplina de privacidade operável: controle de dados só existe quando mascaramento, acesso, retenção, backup e restore entram na rotina. “Os dados estão na minha VPS” é localização. Não é, por si só, proteção nem recuperação.

Privacidade operável: onde session replay pode dar errado

Session replay pode ser útil para entender uma etapa quebrada, mas merece uma revisão do que a aplicação mostra. No PostHog, inputs são mascarados por padrão. Texto geral, porém, não é mascarado por padrão. O SDK oferece seletores, funções de mascaramento e a classe ph-no-capture para excluir elementos, como explica a documentação de privacidade do replay.

Isso pede uma pergunta simples antes de ativar o recurso: há tela com dados que não deveriam aparecer na gravação? Se houver, a configuração e a validação precisam vir antes da coleta. O artigo não substitui análise jurídica sobre LGPD; conformidade depende de contexto, base legal, configuração e processos do controlador.

Instâncias self-hosted também enviam relatórios periódicos de uso. Segundo a documentação, eles contêm dados anonimizados e agregados, não dados brutos de pessoas, eventos ou grupos. É possível operar air-gapped, embora a instalação inicial exija internet. A configuração está detalhada na documentação de egress do PostHog self-hosted.

Privacidade operável combina mascaramento, acesso, retenção, backup, restore e atualização.

Quando PostHog Cloud ganha da VPS

A documentação do PostHog diz que Cloud é a melhor experiência para a ampla maioria dos usuários. É uma posição do próprio fornecedor, não um estudo independente. Ainda assim, ela combina com fatos operacionais: a instância OSS não tem garantia ou plano de suporte pago, e o mantenedor descreve produção como intensiva em dados e de arquitetura complexa.

O software recebe correções continuamente em imagens recentes. O PostHog não publica CVEs nem mantém releases marcados para self-host, e recomenda manter a imagem atualizada. Isso reduz o tempo entre correção e disponibilidade, mas cria uma rotina: acompanhar atualização, testar, ter backup e saber como reagir se algo der errado.

A reconciliação prática do Runzos evita dois erros. O primeiro é tratar Cloud como derrota técnica. O segundo é tratar licença MIT como economia comprovada. Se a franquia atende e não existe motivo claro para operar dados e infraestrutura, Cloud preserva tempo para o produto. Se há motivo técnico real e capacidade operacional, a VPS pode ser uma escolha consciente.

Qual VPS considerar quando a decisão já está tomada

Não compre uma VPS para descobrir depois o que medir. Primeiro defina os eventos, valide se a ferramenta é necessária e passe pela matriz acima. Só então escolha infraestrutura compatível com uma stack que inclui banco, mensageria, proxy e backup.

Para stacks de produto com banco e eventos, a rota principal é a Turbo Cloud VPS. Para comparar uma opção de VPS com oferta validada, veja a Hostinger VPS. Se PIX, boleto e suporte em português forem critérios relevantes, a Servla VPS é a alternativa contextual.

As três rotas são caminhos comerciais do Runzos. Nenhuma delas substitui o checklist de operação, nem autoriza prometer preço, capacidade por evento, alta disponibilidade ou perda zero de dados sem teste e plano vigente.

A escolha entre operar e contratar também aparece em outros contextos. O comparativo Vercel, Railway ou Render ajuda a pensar no custo de uma plataforma gerenciada. Para automações, n8n vs Make mostra uma tensão parecida entre controle e operação. A análise Turbo Cloud detalha outra rota de infraestrutura já publicada no Runzos.

Checklist antes de rodar PostHog em VPS

1. Definir quais eventos mudariam uma decisão de produto.

2. Confirmar se web analytics simples não atende à necessidade.

3. Revisar a franquia e os limites atuais do PostHog Cloud.

4. Planejar uma VM conforme o requisito oficial mais conservador.

5. Mapear volumes persistentes de PostgreSQL, ClickHouse e outros serviços.

6. Configurar domínio, HTTPS, proxy confiável e hosts permitidos.

7. Manter endpoints de ingestão e assets acessíveis quando necessários.

8. Definir backup, retenção e um procedimento de restore testável.

9. Revisar mascaramento e exclusões antes de ativar session replay.

10. Criar rotina para acompanhar imagens, atualizações e incidentes.

11. Adicionar monitoramento para a pilha e seus serviços persistentes.

12. Documentar quem responde quando um dado ou container falhar.

Se esses itens parecem burocracia, Cloud provavelmente é a resposta para o momento. Se parecem uma rotina que sua operação já sabe executar, a VPS deixa de ser aposta e vira uma decisão técnica assumida.

FAQ

PostHog self-hosted é gratuito?

O código self-hosted do PostHog é open source sob licença MIT e pode ser implantado por Docker Compose. Isso não significa custo zero. A operação ainda envolve VPS, armazenamento, backup, atualizações, monitoramento e tempo de resposta a incidentes. Além disso, a documentação informa que alguns recursos de planos pagos são exclusivos do Cloud no self-host OSS.

Quais recursos uma VPS precisa para PostHog?

A documentação de self-host recomenda, para planejamento, uma VM Ubuntu equivalente a 4 vCPU, 16 GB de RAM e mais de 30 GB de armazenamento. Esse é um requisito oficial atual, não uma garantia de desempenho nem uma previsão de capacidade por volume de eventos. A pilha inclui vários serviços, então a necessidade real depende do uso e deve ser revisada antes da implantação.

PostHog Cloud gratuito já atende um micro-SaaS?

Pode atender. A página oficial informa franquia mensal de 1 milhão de eventos de Analytics, 5 mil recordings e 1 milhão de requisições de feature flags. A própria documentação orienta projetos abaixo desses patamares a considerar Cloud. Como limites e preços podem mudar, confirme a página oficial no momento da decisão.

PostHog substitui Plausible ou Umami?

Não necessariamente. PostHog atende analytics de produto baseada em eventos e oferece recursos como funis, flags e replay. Plausible e Umami são alternativas mais alinhadas a web analytics quando o objetivo é medir tráfego, sessões, origem e conversão. A escolha depende do tipo de pergunta que você precisa responder, não do número de recursos na lista.

Session replay pode capturar dados sensíveis?

Pode criar risco se a aplicação exibir conteúdo que não deveria entrar em uma gravação. Inputs são mascarados por padrão, mas texto geral não é mascarado por padrão. Antes de ativar replay, revise as telas, aplique seletores ou funções de mascaramento quando necessário e use ph-no-capture para excluir elementos. Isso é cuidado técnico, não parecer jurídico sobre LGPD.

Quando uma VPS deixa de compensar para analytics?

Quando você não precisa de eventos e decisões de produto, quando a franquia Cloud atende ou quando não há capacidade de manter backup, restore, atualização, proxy e monitoramento. A própria documentação do PostHog recomenda Cloud para a ampla maioria. A VPS só compensa quando a responsabilidade operacional já faz parte de uma necessidade clara.

Conclusão: compre VPS para uma operação, não para um contador de visitas

PostHog self-hosted pode ser a ferramenta certa, mas somente para quem precisa de analytics de produto e aceita a pilha que vem junto. Eventos, funis, flags e replay têm valor quando orientam decisões. Sem isso, o leitor ganha containers, volumes e alertas sem ganhar clareza.

A resposta honesta é menos glamourosa que “open source grátis”: use Cloud quando a franquia e o serviço gerenciado resolvem o problema. Escolha VPS quando domínio, HTTPS, banco, backup, restore, atualização e monitoramento já cabem na sua operação. A infraestrutura certa começa depois dessa decisão, não antes dela.