Ferramentas de Teste A/B Open-Source: GrowthBook e Mais
Panorama de ferramenta de teste a/b open source: GrowthBook, PostHog, Unleash e Flagsmith comparadas por self-host, licença e rigor estatístico.
📚 Este artigo faz parte do guia Ferramentas de Teste A/B Comparadas: Visão Neutra (2026).
Uma ferramenta de teste a/b open source entrega o mesmo tipo de resultado de qualquer plataforma de experimentação (atribuição de variação, coleta de conversão, veredito estatístico), mas com o código-fonte aberto para inspeção e, na maioria dos casos, a opção de rodar tudo dentro da sua própria infraestrutura em vez da de um fornecedor. GrowthBook e PostHog já têm uma comparação dedicada aqui no blog porque são as duas opções mais citadas da categoria; este guia amplia a lente para o panorama inteiro, incluindo Unleash e Flagsmith, os motivos reais para escolher open-source, o peso operacional de manter cada caminho no ar, e por que o rigor estatístico varia mais entre ferramentas abertas do que entre plataformas proprietárias maduras.
Panorama rápido
| Ferramenta | Foco principal | Self-hosted | Cloud gerenciado | Motor estatístico nativo | Licença do núcleo |
|---|---|---|---|---|---|
| GrowthBook | Feature flags + experimentação | Sim, stack leve (app + MongoDB) | Sim, GrowthBook Cloud | Sim: bayesiano por padrão, frequentista e sequencial disponíveis | MIT no núcleo, camada Enterprise à parte |
| PostHog | Product analytics com experimentação embutida | Sim, stack pesada (ClickHouse, Kafka, Postgres, Redis) | Sim, PostHog Cloud | Sim: bayesiano por padrão, frequentista disponível | Open-source em parte, camada paga à parte |
| Unleash | Feature flags primeiro | Sim, stack leve (app + PostgreSQL) | Sim, versão gerenciada | Limitado: suporte básico a A/B, sem motor estatístico dedicado | AGPL-3.0-or-later no núcleo |
| Flagsmith | Feature flags + remote config | Sim, stack leve (app + PostgreSQL, Docker Compose) | Sim, versão gerenciada | Limitado: variação via flag multivariada, estatística fica por conta de analytics externo | BSD-3-Clause no núcleo, Enterprise Edition à parte |
O resto deste guia detalha os motivos para escolher esse caminho, o que cada ferramenta realmente resolve, o peso de operar cada uma, e como validar o rigor estatístico de qualquer uma delas por conta própria antes de confiar num veredito de teste.
Por que uma equipe escolhe uma ferramenta open-source
Quatro motivos aparecem com mais frequência quando um time decide ir para o lado open-source em vez de uma plataforma proprietária fechada.
Controle de dados. Quando você autohospeda, o dado de comportamento do visitante (quem viu qual variação, quem converteu) nunca sai da sua própria infraestrutura para chegar ao servidor de um fornecedor terceiro. Isso é relevante no Brasil por causa da LGPD: manter o dado dentro do seu próprio ambiente simplifica o controle sobre onde ele fica fisicamente e reduz a superfície de compartilhamento com terceiros. Vale a ressalva: isso não é sinônimo automático de conformidade, é uma peça do quebra-cabeça, as outras obrigações da lei (base legal, minimização, retenção, segurança de acesso) continuam sendo sua responsabilidade independente de onde o servidor está.
Sem lock-in de vendor. Migrar de uma plataforma proprietária fechada para outra costuma significar reconstruir a integração do zero, porque o formato de dado e a API são proprietários. Com uma ferramenta open-source, o código está ali para ser lido, exportado ou até bifurcado (fork) se o fornecedor mudar de direção de um jeito que não serve mais o seu time.
Customização de código. Times de engenharia com uma necessidade específica (um algoritmo de bucketing diferente, uma integração interna, um requisito de compliance fora do padrão) podem alterar o comportamento direto no código, algo impossível numa plataforma fechada, onde você só pode pedir a funcionalidade e esperar o roadmap do fornecedor.
Custo zero de licença, mas não custo zero. O núcleo de código não custa nada para rodar, mas ele não roda sozinho: alguém precisa provisionar servidor, banco de dados, backup, monitoramento e tempo de engenharia para manter a versão atualizada. Trocar custo de licença por custo de operação é uma troca real, não uma economia automática, e o restante deste guia trata exatamente desse trade-off.
Panorama das ferramentas
GrowthBook nasceu como plataforma de feature flagging e experimentação, sem tentar ser nada além disso. O motor estatístico é bayesiano por padrão, com opção de trocar para frequentista e para teste sequencial, e o self-hosting é relativamente leve: a aplicação principal mais um banco MongoDB, geralmente subido via Docker Compose. É a opção mais citada por times dev-first que já têm (ou vão construir) o próprio warehouse de dados e querem um motor de experimentação dedicado por cima dele.
PostHog nasceu como suíte de product analytics open-source e foi crescendo até incorporar experimentação como mais um módulo dentro de um produto bem mais amplo, ao lado de funil, gravação de sessão, pesquisas e feature flags. O motor de experimentação também é bayesiano por padrão, com opção frequentista, e usa o mesmo pipeline de eventos que já alimenta o resto da suíte. O self-hosting é a operação mais pesada das quatro ferramentas deste guia: a stack completa inclui ClickHouse, Kafka, Postgres e Redis, e a própria documentação da empresa recomenda a versão cloud para produção na maioria dos casos.
Unleash é feature flags primeiro, ponto final: o produto foi desenhado para reduzir o risco de lançar funcionalidades novas (rollout gradual, canary release, kill switch), não para decidir vitórias de teste A/B. Ele tem algum suporte a A/B testing, mas isso significa rotear uma fração do tráfego para variações diferentes de uma flag, sem um motor estatístico dedicado calculando significância por trás. O self-hosting pede um servidor Node.js mais um banco PostgreSQL, uma stack relativamente enxuta. Um detalhe de licenciamento vale registrar: o núcleo do repositório principal está sob AGPL-3.0-or-later, uma licença copyleft mais restritiva do que a MIT usada pelo núcleo do GrowthBook ou a BSD-3-Clause usada pelo núcleo do Flagsmith, o que pode importar dependendo de como o seu time pretende modificar ou redistribuir o código.
Flagsmith também é feature flags primeiro, com remote config e flags multivariadas como o caminho para testar variações. Assim como o Unleash, ele não tem um motor de significância estatística nativo: o padrão documentado pela própria empresa é usar a flag multivariada para rotear o tráfego e mandar o evento de conversão para uma ferramenta de analytics externa (Amplitude, Mixpanel, ou equivalente) que calcula o resultado. O self-hosting é leve: Docker Compose sobe a aplicação e um banco PostgreSQL junto, sem exigir infraestrutura de streaming de evento como a do PostHog. O núcleo é licenciado sob BSD-3-Clause, uma licença permissiva, com os recursos de Enterprise Edition (RBAC, SSO/SAML) fechados à parte.
Se o seu comparativo é especificamente entre GrowthBook e PostHog, veja a comparação dedicada entre as duas, com framework de decisão por perfil de time. Se você quer o panorama completo incluindo ferramentas proprietárias como VWO e Optimizely, veja a comparação neutra de ferramentas de teste A/B.
Trade-offs de self-hosting: o que ninguém coloca no anúncio de “grátis”
O núcleo de código de qualquer uma das quatro ferramentas listadas acima é gratuito para rodar, mas autohospedar troca custo de licença por custo de operação, e esse segundo custo raramente aparece nas comparações rápidas. Um self-hosting saudável de verdade pede, no mínimo, tempo dedicado para provisionar e manter o servidor e o banco de dados, aplicar patch de segurança assim que sai (bancos de dados e proxies expostos à internet são alvo constante), atualizar a versão da ferramenta sem quebrar experimentos em andamento, e monitorar disponibilidade, porque uma queda no serviço de flag ou experimentação pode travar a atribuição de variação para visitantes reais no meio de um teste.
Esse peso não é igual entre as quatro ferramentas. GrowthBook, Unleash e Flagsmith pedem uma stack relativamente enxuta (aplicação mais um único banco relacional), o tipo de coisa que sobe via Docker Compose em poucos minutos e que um time pequeno de engenharia consegue manter sem virar um trabalho de tempo integral. PostHog pede uma operação de dados bem mais pesada, porque foi desenhado para processar grande volume de evento: ClickHouse, Kafka, Postgres e Redis, entre outros componentes, o que explica por que a própria empresa recomenda a versão cloud para a maioria dos times em produção.
O caminho cloud gerenciado da mesma ferramenta (GrowthBook Cloud, PostHog Cloud, ou as versões gerenciadas de Unleash e Flagsmith) tira essa carga operacional do seu time, mas troca isso por uma assinatura recorrente e, na maioria dos casos, por dado saindo da sua infraestrutura para a do fornecedor, o mesmo modelo de qualquer SaaS proprietário. Nenhum dos dois caminhos é “melhor” de forma absoluta: é uma escolha entre gastar tempo de engenharia ou gastar orçamento recorrente, e entre manter o dado dentro de casa ou aceitar que ele fique com um terceiro.
| Ferramenta | Stack mínima self-hosted | Peso operacional | Licença do núcleo |
|---|---|---|---|
| GrowthBook | Aplicação + MongoDB | Leve a médio | MIT (Enterprise à parte) |
| PostHog | Aplicação + ClickHouse + Kafka + Postgres + Redis | Pesado | Open-source em parte |
| Unleash | Aplicação Node.js + PostgreSQL 15+ | Leve | AGPL-3.0-or-later |
| Flagsmith | Aplicação + PostgreSQL (Docker Compose) | Leve | BSD-3-Clause (Enterprise à parte) |
Rigor estatístico em ferramentas open-source: verifique antes de confiar
Numa plataforma proprietária madura e cara, o motor estatístico costuma ser um produto testado por anos e por milhares de clientes pagantes, com pouco espaço para divergência entre o que a interface mostra e o que a matemática realmente calcula. No universo open-source, essa garantia é menos uniforme: cada projeto tem seu próprio time, seu próprio ritmo de revisão e sua própria escolha de método, e a profundidade do motor varia bem mais de ferramenta para ferramenta do que costuma variar entre concorrentes proprietários de mesmo porte.
Isso fica claro nas quatro ferramentas deste guia. GrowthBook e PostHog têm um motor de experimentação dedicado, pensado especificamente para calcular significância, com opção bayesiana e frequentista documentada. Unleash e Flagsmith não têm essa peça nativa: elas são excelentes em atribuir tráfego para variações de forma confiável, mas o cálculo estatístico de “essa diferença é real ou é ruído” tipicamente acontece numa ferramenta de analytics conectada por fora, não dentro do produto de flag em si. Usar Unleash ou Flagsmith para rodar um teste A/B sem também ter uma camada de análise estatística séria por trás é o erro mais comum: a flag funciona perfeitamente, mas ninguém garantiu que a amostra é suficiente ou que o resultado não é peeking disfarçado de vitória.
A recomendação prática, para qualquer uma das quatro: não confie cegamente no veredito que a interface mostra, especialmente numa ferramenta menos madura ou com equipe de manutenção menor. Pegue os mesmos números de visitantes e conversões que a ferramenta usou e reproduza o cálculo de forma independente. A calculadora abaixo, do nosso guia de significância estatística em teste A/B, faz exatamente isso: cole visitantes e conversões de cada variação e compare o valor-p, o lift e o veredito com o que a sua ferramenta open-source relatou para o mesmo experimento.
Teste z bilateral de duas proporções. "Sem significância" quase sempre quer dizer que falta amostra, não que as versões são iguais.
Se os dois números baterem, ótimo sinal de que o motor está calculando corretamente. Se divergirem por uma margem grande, vale investigar antes de tomar a decisão de negócio em cima do resultado, seja checando a documentação do método estatístico da ferramenta, seja abrindo uma issue no repositório, um luxo que só existe justamente porque o código é aberto.
Quando faz sentido NÃO ir de open-source
Open-source não é a escolha certa por padrão para todo time. Vale considerar o caminho proprietário gerenciado quando pelo menos uma destas condições é verdadeira:
- O time não tem capacidade de DevOps disponível. Se ninguém no time consegue responder com confiança “quem cuida do patch de segurança do banco de dados às 2h de uma sexta-feira”, self-hospedar qualquer uma dessas quatro ferramentas é assumir um risco operacional que ninguém está preparado para carregar.
- A urgência não permite uma sprint de engenharia. Um teste A/B que precisa começar amanhã não combina com provisionar servidor, configurar banco, testar backup e validar SDK antes do primeiro experimento rodar.
- O volume de tráfego não justifica manter infraestrutura própria. Para um site pequeno ou médio, o custo de engenharia de manter uma stack no ar frequentemente supera, em salário e atenção, o que uma assinatura gerenciada cobraria pelo mesmo volume.
- O time prefere não virar operador de banco de dados. Mesmo as opções mais leves (GrowthBook, Unleash, Flagsmith) pedem alguém disposto a aprender a operar Docker, PostgreSQL ou MongoDB em produção; isso é uma escolha de onde investir tempo de engenharia, não um detalhe menor.
Nesses casos, a camada cloud gerenciada da própria ferramenta open-source (GrowthBook Cloud, PostHog Cloud) já resolve boa parte do problema sem abandonar o produto. E uma ferramenta proprietária, gerenciada do início ao fim, continua sendo a opção mais direta para quem quer testar sem pensar em infraestrutura nenhuma.
Faça isso automático na Donnu
Se o motivo de olhar para open-source é fugir de uma ferramenta cara ou opaca, mas o motivo de hesitar é o peso de montar e manter um self-hosting (servidor, banco, patch, backup, monitoramento), vale considerar a Donnu como mais uma opção na mesa: um SaaS gerenciado, sem infraestrutura própria para operar, com estatística bayesiana honesta e isolamento de dados por conta desde o início. Não é substituto para feature flagging de produto no estilo Unleash ou Flagsmith, nem para a suíte completa de analytics do PostHog, e não é a escolha certa para quem realmente precisa customizar código-fonte ou manter tudo dentro da própria infraestrutura por exigência interna. Mas para quem quer parar de pesar Docker Compose contra assinatura mensal e só rodar o teste, é uma alternativa gerenciada e mais enxuta do que um contrato enterprise.
Comece um teste grátis e veja se dispensar o self-hosting compensa para o seu caso, especialmente se o tempo de engenharia do seu time está mais escasso do que o orçamento.
Leia também
Veja também a comparação dedicada entre GrowthBook e PostHog para um framework de decisão por perfil de time entre as duas ferramentas mais citadas desta categoria, a comparação neutra de ferramentas de teste A/B para o panorama completo incluindo opções proprietárias, o guia de significância estatística em teste A/B para a mecânica completa por trás de qualquer motor bayesiano ou frequentista, e o guia sobre ferramentas de teste A/B realmente grátis para separar open-source de trial disfarçado de grátis.
Referências
- GrowthBook. Documentação oficial e licenciamento. docs.growthbook.io e github.com/growthbook/growthbook
- PostHog. Documentação oficial e guia de self-hosting. posthog.com/docs
- Unleash. Documentação oficial e repositório open-source. docs.getunleash.io e github.com/unleash/unleash
- Flagsmith. Documentação oficial, licenciamento e guia de self-hosting. docs.flagsmith.com e github.com/Flagsmith/flagsmith
Perguntas frequentes
- O que diferencia uma ferramenta teste a/b open source de uma proprietária?
- A diferença central não é o preço, é o controle: uma ferramenta open-source publica o código-fonte, então você pode inspecionar exatamente como o motor estatístico calcula um resultado, modificar o comportamento e, na maioria dos casos, autohospedar a aplicação inteira dentro da sua própria infraestrutura. Uma ferramenta proprietária entrega só a interface e a API, o código fica fechado, e você sempre depende do servidor do fornecedor rodando. O custo de licença zero do open-source é real, mas ele se transforma em custo de operação, engenharia e manutenção quando você decide autohospedar.
- GrowthBook, PostHog, Unleash e Flagsmith são todas gratuitas de verdade?
- O núcleo de código de todas as quatro pode ser autohospedado sem pagar licença de software, mas "gratuito" ali significa gratuito de licença, não gratuito de operação: você ainda paga o servidor, o banco de dados e o tempo de engenharia para manter tudo funcionando. As quatro também vendem uma camada paga, seja em nuvem gerenciada (GrowthBook Cloud, PostHog Cloud), seja como recursos enterprise fechados por cima do núcleo aberto (RBAC avançado, SSO/SAML, suporte). Confirme sempre os limites atuais na página de preços de cada uma antes de planejar capacidade, porque esses números mudam com frequência.
- Self-hosting de ferramenta de experimentação open-source resolve a LGPD sozinho?
- Não sozinho. Self-hospedar mantém o dado dentro da sua própria infraestrutura em vez de sair para o servidor de um fornecedor terceiro, o que ajuda no controle de onde o dado fica fisicamente e reduz a superfície de compartilhamento com terceiros, dois pontos relevantes para a LGPD. Mas isso não substitui as outras obrigações da lei: base legal para o tratamento, minimização de dado coletado, política de retenção, segurança de acesso ao próprio servidor que você está operando. O self-hosting resolve "onde o dado mora", não "se você trata o dado de forma correta".
- Qual ferramenta open-source de teste A/B tem o motor estatístico mais robusto?
- Não existe uma resposta única, porque as quatro ferramentas citadas aqui não competem exatamente na mesma categoria. GrowthBook e PostHog têm um motor de experimentação dedicado, com suporte a teste bayesiano e frequentista, pensado especificamente para decidir vitórias de teste A/B. Unleash e Flagsmith nasceram como plataformas de feature flag: elas conseguem rotear tráfego para variações, mas o cálculo de significância estatística tipicamente fica por conta de uma ferramenta de analytics externa conectada por fora, não de um motor nativo delas. Antes de confiar cegamente no veredito de qualquer uma, vale reproduzir o cálculo por conta própria.
- Quando faz mais sentido não usar uma ferramenta de teste A/B open-source?
- Principalmente quando o time não tem capacidade real de DevOps disponível para instalar, atualizar e monitorar uma stack própria. O peso operacional varia muito entre as opções (uma stack de GrowthBook autohospedada é bem mais simples de manter do que uma stack completa de PostHog, por exemplo), mas nenhuma delas é "instale e esqueça". Um time pequeno sem ninguém dedicado a infraestrutura, ou que precisa de algo rodando amanhã sem sprint de engenharia dedicada, normalmente sai ganhando com uma ferramenta gerenciada, seja a camada cloud da própria ferramenta open-source, seja uma alternativa proprietária.