Imagine padronizar a sua CI numa das três ferramentas open source de testes de regressão visual que toda a gente coloca na lista (BackstopJS, Argos, Lost Pixel) e descobrir, uma semana após começar a experiência, que duas das três não são o que pareciam de fora. O Argos tem código excelente no GitHub, mas o seu responsável diz claramente que o self-hosting não é suportado nem documentado. O Lost Pixel foi arquivado a 22 de abril de 2026, quando a equipa se juntou à Figma, e não ofereceu qualquer caminho de migração às equipas que já o usavam.
Isso deixa exatamente uma das três que é genuinamente self-hostável e mantida hoje. O que é estranho de dizer sobre uma categoria com tanta escolha aparente, mas é onde o panorama está de facto. As ferramentas que as pessoas tratam como três iguais são, na prática, uma opção self-hosted que funciona, uma ferramenta forte que vive nos servidores de outra pessoa, e uma da qual devias estar a migrar.
Esta é uma leitura com foco no self-hosting sobre as ferramentas de testes de regressão visual self-hosted que sobrevivem ao contacto com a realidade: qual encaixa em que restrição, e o que fazer se usas o Lost Pixel agora mesmo.
A versão curta
- BackstopJS é a opção self-hostável, mantida, com licença MIT e de custo zero. Puppeteer por omissão com suporte para Playwright, comparação ao nível do pixel via Resemble.js e uma interface de revisão em HTML (com as ressalvas de renderização em Docker que precisas de planear).
- Argos é a ferramenta mais forte no fluxo de trabalho (revisão de PR e comparação de snapshots ARIA desde o final de 2025), mas na prática é um SaaS gerido. O responsável não oferece suporte nem documentação para o executares por conta própria.
- Lost Pixel foi arquivado em abril de 2026. Não o adotes para trabalho novo e, se o usas, planeia já a tua migração.
O veredito numa linha: para uma pipeline de CI totalmente self-hosted, o BackstopJS é a escolha prática. Se queres o melhor fluxo de revisão e podes aceitar uma dependência SaaS, o Argos é a melhor ferramenta.
(O que isto não cobre: testes visuais baseados em Cypress, fluxos de trabalho específicos de componentes em Storybook e números de desempenho medidos à mão. Esta comparação é construída a partir de factos de fontes primárias, não de um banco de testes que eu próprio tenha executado.)
O panorama dos testes de regressão visual self-hosted mudou
Dois factos concretos do último ano remodelaram esta lista, e ambos são fáceis de deixar escapar se trabalhas a partir de um artigo escrito antes de acontecerem.
O primeiro: numa discussão no GitHub de setembro de 2025, um responsável do Argos afirmou que o Argos não oferece suporte nem documentação para o executar fora do serviço gerido. O código tem licença MIT e está à vista, por isso "podes fazer self-hosting" é tecnicamente verdade, mas não há um caminho suportado, uma distinção que importa enormemente assim que és a pessoa de piquete para tratar disso.
O segundo: o repositório do Lost Pixel foi arquivado a 22 de abril de 2026, apenas para leitura, quando a equipa anunciou que se ia juntar à Figma. Nenhuma orientação de migração acompanhou o encerramento. Uma ferramenta que era, até há pouco, uma alternativa gratuita e self-hosted legítima ao Percy e ao Chromatic é agora uma dependência sem responsável.
Ambas as mudanças apontam na mesma direção. A razão pela qual as equipas acabam aqui em primeiro lugar, preços de SaaS que crescem com navegadores vezes viewports vezes páginas, ou uma regra de conformidade que proíbe carregar capturas de uma interface por publicar para terceiros, não desapareceu. O que mudou é que o menu self-hosted é mais curto do que parece.
Conclusão-chave da secção: apenas uma das três ferramentas que as pessoas colocam na lista é genuinamente self-hostável e ativamente mantida hoje.
BackstopJS: a opção genuinamente self-hostável
A instalação é npm install -g backstopjs (ou uma instalação local no projeto), e esse único facto explica grande parte do porquê de o BackstopJS ganhar no eixo do self-hosting: não há qualquer serviço para fazer engenharia inversa, nenhum backend gerido do qual dependa em segredo. Corre como pacote npm ou contentor Docker numa infraestrutura que controlas, sob licença MIT, com custo de licença zero. O README indica que a linha atual (6.3.x) suporta o Node 20.
Por dentro, conduz o Puppeteer por omissão (Chrome headless) e também suporta o Playwright em chromium, firefox e webkit. A comparação é baseada em pixels via Resemble.js, com um valor configurável misMatchThreshold que controla quanto desvio de pixels conta como falha. As aprovações acontecem através de um relatório HTML com uma interface no navegador para aceitar as alterações.
As limitações são onde se toma uma decisão estratégica. O BackstopJS não tem um fluxo integrado de bloqueio de PR: dir-te-á que existe uma diferença, mas ligar isso a um portão de "esta PR não pode ser integrada" fica ao teu cargo. A sua configuração vive em JSON, um cenário de cada vez, e com algumas centenas de casos de teste esse JSON torna-se uma superfície de manutenção por si só. O desenvolvimento é de ritmo lento mais do que rápido: o projeto não está arquivado, o pacote está atualmente na versão 6.3.25, e o repositório mostra cerca de 7.200 estrelas no GitHub e 516 issues abertas. Por isso trata o BackstopJS como algo maduro e utilizável, não como uma plataforma de testes visuais de evolução rápida.
O risco operacional mais agudo é a renderização em Docker. Duas issues, capturas em branco ou cortadas em Docker (#1156) e resultados inconsistentes após a atualização do Docker para a v5.3.0 (#1303), estão abertas há anos sem resolução. O Docker é além disso exatamente o que queres para a CI, porque normaliza a renderização entre máquinas. Assim, a ferramenta que te dá mais controlo também te entrega uma classe conhecida e por corrigir de instabilidade precisamente na configuração em que a vais executar. É um risco planeável, não um impedimento, mas tem de estar em cima da mesa antes de te comprometeres.
Dica: a armadilha das baselines entre sistemas operativos. Se os teus programadores capturam as baselines em macOS e os teus runners de CI são Linux, os teus testes vão falhar só por diferenças no anti-aliasing dos tipos de letra, antes de existir qualquer regressão real. Como um profissional documentou, a renderização dos tipos de letra difere entre a imagem Linux usada nos serviços de CI e uma máquina local com macOS, o suficiente para fazer falhar um teste visual por si só. A solução é gerar e comparar as baselines num único ambiente (executa o BackstopJS dentro da mesma imagem Docker em local que usas na CI), para que as imagens de referência e de comparação venham de uma renderização idêntica.
Argos: o melhor fluxo de trabalho, mas SaaS na prática
O Argos acerta na experiência de revisão de uma forma que o BackstopJS não consegue, e é essa toda a razão de estar nesta lista apesar da ressalva do self-hosting. Integra-se com Playwright, Cypress, Storybook, WebdriverIO e Puppeteer, e liga-se ao GitHub Actions, GitLab CI, Bitbucket e Azure DevOps. O fluxo de revisão de PR é uma funcionalidade de produto de primeira classe, e não parou de avançar. Entradas recentes do changelog acrescentam revisões colaborativas com comentários fixados (junho de 2026) e a ignoração automática de alterações instáveis.
O seu diferenciador técnico mais interessante é a comparação. Além da comparação determinística de pixels, o Argos acrescentou a comparação de snapshots ARIA para o seu SDK Playwright a 4 de novembro de 2025. A comparação de snapshots ARIA compara a árvore de acessibilidade (papéis, etiquetas e estrutura) juntamente com a captura de pixels, o que apanha uma classe de regressões semânticas e de acessibilidade que uma comparação de pixels pura pode deixar passar (um botão que continua a parecer idêntico mas perdeu a sua etiqueta acessível, por exemplo). Para equipas com compromissos de acessibilidade, é uma capacidade real que as ferramentas só de pixels não oferecem.
Depois vem a restrição. O código é MIT, mas o produto é o serviço gerido, e o responsável foi explícito ao dizer que o self-hosting não é documentado nem suportado. Podes pô-lo de pé a partir do código-fonte. Simplesmente fá-lo sabendo que qualquer alteração a montante pode partir o teu deployment e ninguém é obrigado a ajudar. Há uma incerteza relacionada que convém sinalizar em vez de afirmar: relatos da comunidade sugerem que a integração com o GitLab Self-Managed exige um plano Enterprise (trato isso como um sinal da comunidade, não como uma especificação confirmada, por isso verifica-o com a tua própria configuração antes de conduzir uma decisão).
Isto produz uma lacuna incómoda. Uma equipa com requisitos de privacidade rigorosos (precisamente a equipa mais motivada para fazer self-hosting) que também quer a experiência de revisão do Argos não tem um bom caminho. Podem usar o serviço gerido e aceitar a dependência de terceiros, ou fazer self-hosting sem suporte, ou escolher outra ferramenta. Não há uma quarta porta limpa, e é mais honesto dizê-lo do que fingir que a licença open source a fecha.
Conclusão-chave da secção: o Argos é a ferramenta mais forte. Fazer o seu self-hosting não é suportado e é operacionalmente frágil.
Lost Pixel: arquivado, e o que fazer se o usas
O próprio aviso do repositório do Lost Pixel resume toda a história numa linha: o repositório foi arquivado pelo proprietário a 22 de abril de 2026 e está agora apenas para leitura. A equipa juntou-se à Figma, a última versão foi a v3.22.0 em novembro de 2024, e não foi publicada qualquer orientação de migração.
Até ao arquivamento, o Lost Pixel era uma escolha razoável (renderização baseada em Docker, suporte para Playwright e Storybook mais Ladle e Histoire, e testes visuais tanto de página inteira como ao nível de componente). Nada disso mudou tecnicamente a 22 de abril. O que mudou é que agora não tem responsável, nem correções de segurança, nem roadmap, o que para uma dependência de CI é desqualificante para trabalho novo por melhor que a versão atual funcione.
Se o usas hoje, a migração divide-se conforme a forma como o estavas a usar. Se dependias dos seus testes ao nível de componente, em especial fluxos com Storybook ou Ladle, o teu substituto mais próximo é o serviço gerido do Argos ou os testes de captura de ecrã nativos do Playwright. O BackstopJS pode capturar seletores ou URLs de Storybook, mas não te dá o mesmo fluxo de componentes integrado que o Lost Pixel dava, por isso terias de modelar tu próprio esses estados de componente. Se o usavas para regressão visual de página inteira, o BackstopJS é o sucessor self-hosted direto. Seja como for, a mudança não é urgente no sentido de "as tuas builds vão partir amanhã", mas o relógio corre: uma ferramenta de testes sem manutenção apodrece em silêncio à medida que as versões do teu navegador, sistema operativo e framework se afastam daquelas com que foi compilada pela última vez.
Comparação num relance
Aqui está a mesma informação lado a lado, para que possas percorrer os eixos que importam numa decisão de CI antes de os mapeares nas tuas próprias restrições.
| Eixo | BackstopJS | Argos | Lost Pixel |
|---|---|---|---|
| Licença | MIT | Código MIT, produto SaaS gerido | MIT |
| Realidade do self-hosting | Totalmente self-hostável por conceção | Possível mas sem suporte e sem documentação | Era self-hostável, agora arquivado |
| Estado de manutenção | Mantido, de ritmo lento e maduro | Ativo (serviço gerido) | Arquivado a 22 de abril de 2026 |
| Abordagem de comparação | Comparação de pixels (Resemble.js) | Comparação de pixels mais comparação de snapshots ARIA | Comparação de pixels (sem manutenção) |
| Suporte de frameworks e motores | Puppeteer (por omissão), Playwright | Playwright, Cypress, Storybook, WebdriverIO, Puppeteer | Playwright, Storybook, Ladle, Histoire (no momento do arquivamento) |
| Fluxo de revisão | Relatório HTML, aprovação manual, sem portão de PR | Revisão de PR, comentários colaborativos, bloqueio de PR | Não aplicável (arquivado) |
| Custo | Grátis | Preços SaaS (por snapshot) | Grátis mas sem manutenção |
Como escolher (quadro de decisão)
Parte da tua restrição mais dura, não de uma lista de funcionalidades. A restrição elimina por ti a maior parte do menu.
- Totalmente self-hosted, orçamento zero, e podes aceitar testes só de página inteira com revisão manual: BackstopJS. É a única opção que satisfaz self-hosted, mantido e grátis ao mesmo tempo, e os compromissos (sem portão de PR, configuração em JSON, instabilidade em Docker) são quantidades conhecidas em torno das quais podes projetar.
- Queres a melhor experiência de revisão, bloqueio de PR e comparação ARIA, e podes aceitar uma dependência SaaS: o serviço gerido do Argos. Este é o caminho para os pontos fortes do Argos sem o risco do self-hosting sem suporte. Se uma regra de conformidade proíbe o carregamento de capturas para terceiros, esta porta está fechada e voltas ao BackstopJS.
- Suite de testes pequena ou com Playwright em primeiro lugar: considera não acrescentar qualquer ferramenta dedicada. O Playwright inclui
toHaveScreenshot()de forma nativa, e para suites abaixo de cerca de 100 testes pode ser tudo o que precisas. Um guia de um profissional coloca o ponto de inflexão em que uma ferramenta dedicada começa a valer a pena por volta dessa escala (trata isso como uma observação do setor, não como um número oficial do Playwright). A sobrecarga de gerir os ficheiros de baseline em git cresce para além desse ponto, que é onde uma ferramenta dedicada se paga a si mesma. - Atualmente no Lost Pixel: migra já, conforme a divisão da secção anterior. Não tomes "ainda funciona" como razão para ficar.
Uma ressalva que precede todas estas ferramentas e lhes sobrevive: a equipa da Sparkbox, a escrever há anos, escolheu uma opção alojada precisamente porque conseguir que os engenheiros usassem de facto os testes era mais difícil do que a configuração. Uma ferramenta self-hosted com uma interface de revisão mais fraca pode ganhar no custo e perder na adoção (se a tua equipa ignora um relatório barulhento do BackstopJS, o seu custo de licença zero não te trouxe nada). Tem em conta a experiência de revisão na decisão, não só o preço.
Conclusão-chave da secção: a restrição escolhe a ferramenta. Self-hosted e grátis aponta para o BackstopJS, melhor fluxo de trabalho com SaaS aceitável aponta para o Argos, e pequeno e com Playwright em primeiro lugar pode não apontar para nenhuma ferramenta.
Dimensionar o runner de CI para o Chromium headless
As três ferramentas conduzem o Chromium headless, e é a pegada de memória do Chromium (não a CPU) que define o tamanho do teu runner, porque cada worker de navegador concorrente quer os seus próprios poucos gigabytes de RAM. Se dimensionas a máquina abaixo do necessário, os teus testes visuais não falham de forma limpa. São mortos por OOM a meio da execução e reportados como ruído de infraestrutura instável, que é o pior tipo de falha para depurar.
Como guia aproximado, dimensionado por paralelismo e não como números rígidos (o uso real depende da complexidade da página e de quantos workers executas em paralelo):
- Equipa pequena ou testes em série: cerca de 2 vCPU / 4 GB RAM dão conta de um único worker Chromium headless com a sobrecarga do daemon de CI.
- Uso de CI em equipa: cerca de 4 vCPU / 8 GB RAM suportam aproximadamente 2 a 4 workers de navegador em paralelo, que é onde a maioria das equipas se situa.
- Alto débito ou suites grandes: cerca de 8 vCPU / 16 GB RAM para um alto paralelismo, ou quando a execução de regressão visual partilha um runner com outro trabalho de CI.
O armazenamento é a rubrica silenciosa. Os artefactos de capturas e as baselines históricas acumulam-se execução após execução, por isso planeia esse crescimento: reserva uma margem generosa de armazenamento se guardas as baselines em local, ou envia as baselines e os artefactos para armazenamento de objetos para que o disco do runner não seja a restrição.
Um VPS é o anfitrião natural para um runner de CI self-hosted que faça isto, porque queres RAM previsível e dedicada para os workers do Chromium, e uma máquina caseira só faz sentido se o hardware já lá estiver. Se também estás a montar o resto do stack de CI, as peças em torno da ferramenta de testes visuais são implementações num clique no marketplace da Cloudzy: Gitea, GitLab, Jenkins e Forgejo para a forja de CI, e Docker para a consistência de renderização de que as ferramentas precisam. A própria ferramenta de regressão visual instala-se por cima via npm ou Docker, por isso cria um Linux VPS dimensionado a partir dos intervalos acima e executa-o aí. Se estás a montar CI baseado em Docker, os guias da Cloudzy sobre alternativas self-hosted ao GitLab e listar contentores Docker cobrem a configuração adjacente.
Perguntas frequentes
O Argos é self-hostável?
Tecnicamente sim (o código tem licença MIT), mas o responsável afirmou em setembro de 2025 que o Argos não oferece suporte nem documentação para o executar fora do serviço gerido. Trata o self-hosting como algo sem suporte e operacionalmente frágil: pode partir a qualquer alteração a montante sem que qualquer responsável seja obrigado a ajudar. Para a maioria das equipas, o serviço gerido é a forma prática de obter os benefícios do Argos.
O que aconteceu ao Lost Pixel?
O Lost Pixel foi arquivado a 22 de abril de 2026, quando a equipa se juntou à Figma e encerrou o produto. O repositório está apenas para leitura, a última versão foi a v3.22.0 em novembro de 2024, e não foi fornecida qualquer orientação de migração. Não o adotes para trabalho novo. Se o usas, planeia uma migração para o BackstopJS (testes de página inteira) ou para o Argos e os nativos do Playwright (testes de componentes).
O que é a comparação de snapshots ARIA?
A comparação de snapshots ARIA compara a árvore de acessibilidade (papéis, etiquetas e estrutura) juntamente com a captura de pixels, e apanha regressões semânticas e de acessibilidade que uma comparação de pixels sozinha pode deixar passar, como um botão visualmente idêntico que perdeu a sua etiqueta acessível. O Argos acrescentou a funcionalidade a 4 de novembro de 2025.
Quanta RAM precisa o Chromium headless na CI?
Um único worker em série corre normalmente com cerca de 2 a 4 GB, e os workers concorrentes escalam a RAM de forma mais ou menos linear a partir daí. O uso real depende da complexidade da página e de quantas instâncias de navegador executas em paralelo, por isso trata estes números como guias e não como valores rígidos, e deixa margem para evitar execuções mortas por OOM.
O BackstopJS suporta o Playwright?
Sim. O Puppeteer é o motor por omissão (Chrome headless), e o BackstopJS também suporta o Playwright em chromium, firefox e webkit. O motor seleciona-se na tua configuração.
