Umami, Plausible ou Matomo em VPS: qual analytics privado escolher em 2026?
Por Maicon Ramos · · 12 min de leitura

Navegue por tópicos
- O veredito antes do Docker: qual ferramenta cabe na sua operação?
- Umami, Plausible CE e Matomo: o que muda por baixo do dashboard?
- O banco escolhe a VPS: CPU, RAM e disco sem plano mágico
- Privacidade sem promessa jurídica: cookies, consentimento e acesso
- O custo invisível: atualização, backup e restore
- Quando VPS compensa e quando SaaS gerenciado ganha
- Checklist antes de contratar a VPS
- Qual VPS faz sentido depois da decisão?
- FAQ: dúvidas sobre analytics privado em VPS
- Conclusão: escolha a operação que você consegue recuperar
Resposta curta: Umami é a escolha mais direta para métricas web essenciais com PostgreSQL. Plausible Community Edition faz sentido se você quer a experiência do produto e aceita operar ClickHouse. Matomo atende quem precisa de uma suite mais ampla e aceita uma stack maior. Nos três casos, VPS só compensa quando domínio, HTTPS, banco, backup, atualização e restore têm dono.
Um dashboard próprio parece uma economia simples: trocar uma mensalidade por uma VPS. A conta muda quando o painel para de abrir, o banco cresce ou uma atualização pede retorno. Analytics auto-hospedado não é só um script no site. É uma cadeia de dados persistentes que alguém precisa manter.
A tese deste comparativo é a Privacidade Operável. Dados só ficam sob seu controle quando acesso, banco, atualização, cópia externa e recuperação também entram na rotina. Se essa rotina não cabe na operação, Cloud ou SaaS não é derrota. Pode ser a decisão mais barata no total.
O veredito antes do Docker: qual ferramenta cabe na sua operação?
A escolha não começa pela aparência do dashboard. Ela começa pelo trabalho que você aceita operar. O Umami reúne app Node e PostgreSQL. O Plausible CE traz Docker Compose e ClickHouse. O Matomo On-Premise usa webserver, PHP e MySQL ou MariaDB.
Critério | Umami | Plausible CE | Matomo |
|---|---|---|---|
Perfil ideal | Métricas essenciais e equipe confortável com PostgreSQL | Quem prioriza o produto Plausible e aceita a stack correspondente | Quem precisa de maior amplitude e configuração |
Stack de dados | Node e PostgreSQL | Docker Compose e ClickHouse | Webserver, PHP e MySQL ou MariaDB |
Requisito publicado | Node 18.18+ e PostgreSQL 12.14+ para instalação pelo código | CPU com SSE 4.2 ou NEON; 2 GB RAM recomendados para a stack | Para Matomo 6, PHP 8.1+, MySQL 8+ ou MariaDB 10.6+ |
Principal atrito | Operar banco, segredos e atualizações | ClickHouse eleva o piso operacional | Capacidade, banco e configuração por volume |
Quando evitar | Se não há rotina para PostgreSQL e restore | Se a VPS é muito limitada ou ninguém vai manter a stack | Se você só precisa de pageviews e eventos básicos |
Alternativa racional | Cloud do próprio produto ou SaaS | Cloud do próprio produto ou SaaS | Cloud do próprio produto ou SaaS |
A tabela mistura requisitos publicados e interpretação editorial. A documentação não declara um vencedor universal. A leitura do Runzos é objetiva: use a menor operação que responde às suas perguntas de negócio sem criar um painel que ninguém consegue recuperar.
Umami, Plausible CE e Matomo: o que muda por baixo do dashboard?
Umami: métricas essenciais com PostgreSQL
O repositório oficial do Umami apresenta o projeto como privacy-first, sem cookies e sem vigilância, disponível em auto-hospedagem ou Cloud. O projeto usa licença MIT. Para instalação pelo código, a documentação oficial do Umami pede Node.js 18.18+ e PostgreSQL 12.14+.
No desenho oficial em Compose, há aplicativo, URL de banco, segredo da aplicação, chave de criptografia para 2FA e volume persistente do Postgres. Isso faz do Umami a opção de menor atrito entre as três, não uma opção sem operação. Seu banco, seus segredos e sua atualização continuam sendo responsabilidade do operador.
Escolha Umami quando métricas web essenciais bastam e PostgreSQL já é uma dependência que você entende. Evite quando o plano é subir o container, esquecer o banco e descobrir o backup apenas depois de uma falha.
Plausible CE: experiência simples, infraestrutura menos simples
O projeto principal do Plausible se apresenta como analytics open-source, privacy-first e cookie-free, sob AGPL-3.0. A Community Edition tem distribuição própria e documenta o caminho de auto-hospedagem. O ponto decisório é o ClickHouse: os requisitos da Community Edition do Plausible pedem Docker e Docker Compose, CPU com SSE 4.2 ou NEON e recomendam ao menos 2 GB de RAM para ClickHouse e Plausible.
Dois gigabytes não são uma promessa de capacidade. São a recomendação publicada para essa stack. Tráfego, eventos, retenção, logs e tamanho do banco ainda definem o consumo real. A Community Edition também pede um domínio real em BASE_URL, segredo com no mínimo 64 bytes e documenta emissão de certificado ou uso atrás de reverse proxy.
Plausible CE é uma boa escolha quando a experiência do Plausible importa e a operação aceita ClickHouse como parte do desenho. Não o trate como solução para qualquer VPS barata. O dashboard pode ser simples. A persistência não é.
Matomo: suite ampla que pede dimensionamento consciente
O Matomo On-Premise é a opção para quem precisa de mais amplitude e configuração do que um painel enxuto oferece. Seus requisitos oficiais informam, para Matomo 6.0.0, PHP 8.1+, MySQL 8+ ou MariaDB 10.6+, além de webserver e banco.
A mesma documentação oferece sizing por pageviews. Até 100 mil pageviews mensais, a referência é servidor único com no mínimo 2 CPU, 2 GB de RAM e 50 GB SSD. Até um milhão de pageviews mensais, a referência sobe para 4 CPU, 8 GB de RAM e 250 GB SSD. São parâmetros do Matomo por volume, não uma régua para Umami ou Plausible.
Escolha Matomo quando sua necessidade justifica administrar uma suite mais configurável. Evite quando o objetivo é apenas ver visitas, origem e eventos básicos. Recursos que ficam desligados não pagam a complexidade da stack.

Aplicação e banco mudam o piso operacional de cada opção de analytics.
O banco escolhe a VPS: CPU, RAM e disco sem plano mágico
O erro comum é escolher a VPS pelo preço e só depois descobrir a exigência do banco. A arquitetura precisa vir antes. Umami pede PostgreSQL. Plausible CE inclui ClickHouse. Matomo combina PHP com MySQL ou MariaDB. Cada combinação cria necessidades distintas de memória, disco, atualização e recuperação.
Camada | Umami | Plausible CE | Matomo | Verificar antes do deploy |
|---|---|---|---|---|
Aplicação | Node ou imagem Docker | Serviços definidos em Compose | Webserver e PHP | Versões suportadas e recursos do host |
Banco | PostgreSQL | ClickHouse na stack CE | MySQL ou MariaDB | Espaço, retenção e procedimento de backup |
Dados persistentes | Volume do PostgreSQL | Volumes e dados da stack | Banco e arquivos da aplicação | O que sobrevive ao recriar serviços |
Domínio e TLS | Proxy e HTTPS definidos pelo operador | Domínio real; certificado ou proxy documentados | Configuração do ambiente | DNS, HTTPS e portas públicas mínimas |
Acesso | Contas e segredos | Contas, segredo e proxy | Contas e administração do servidor | Quem acessa o painel e como revogar acesso |
Recuperação | Dump e restore do PostgreSQL | Dados e configuração recuperáveis | Banco e configuração recuperáveis | Restore testado fora da VPS original |
Não existe plano mágico de VPS. Para Plausible CE, o requisito de CPU e a recomendação de memória são explícitos. Para Matomo, a documentação relaciona capacidade a pageviews. Para Umami, a coleta não encontrou um plano universal publicado. A decisão responsável é monitorar CPU, memória, disco e crescimento do banco depois de definir retenção e eventos.
Privacidade sem promessa jurídica: cookies, consentimento e acesso
Umami e Plausible se descrevem como sem cookies em suas documentações. Isso é relevante para o desenho técnico de coleta. Não significa que toda instalação dispensa análise sobre consentimento, dados pessoais, integrações ou obrigações aplicáveis.
O próprio guia de configuração consent-free do Matomo diferencia esse modo de situações que tipicamente exigem consentimento, como processamento de dados pessoais, marketing, publicidade ou compartilhamento com terceiros. Isso não é parecer jurídico. É um limite prático para não converter a expressão “privacy-first” em promessa de conformidade automática.
Privacidade Operável também inclui o painel administrativo. HTTPS não substitui contas bem controladas, atualização, firewall, banco protegido e revogação de acessos. Nunca publique o painel diretamente na porta do container como se isso bastasse para produção.

Controle de dados inclui proxy, aplicação, banco, cópia externa e restore em outra VPS.
O custo invisível: atualização, backup e restore
Licença aberta não elimina custo. O custo real inclui VPS, domínio, proxy, disco, cópia externa e tempo de manutenção. A parte que mais aparece tarde é a recuperação.
No Compose oficial, o Umami usa volume persistente do PostgreSQL e segredos de aplicação. O README também orienta atualizar imagem com docker compose pull e recriar os serviços. Atualizar não é apontar para latest e torcer. A rotina segura passa por conferir mudanças, fazer backup, testar a atualização e manter um caminho de retorno.
No Plausible CE, domínio, segredo, TLS e reverse proxy também aparecem na instalação. No Matomo, capacidade depende do volume de requests e do banco. Nenhuma dessas ferramentas transforma um snapshot no mesmo provedor em cópia externa suficiente. Uma cópia só vale como recuperação quando você consegue restaurá-la em outro ambiente e validar o serviço.
A reconciliação prática do Runzos evita dois erros: achar que SaaS é sempre caro e achar que self-hosted é sempre barato. Se você já administra banco, Compose, alertas e backup, a VPS pode concentrar uma operação que faz sentido. Se ninguém vai atualizar ou testar retorno, a economia aparente vira risco operacional.
Quando VPS compensa e quando SaaS gerenciado ganha
Situação | Escolha mais racional | Motivo | Risco se ignorar |
|---|---|---|---|
Você já opera Docker e banco | VPS pode compensar | A rotina técnica já existe | Subdimensionar disco e backup |
Você precisa de suporte e não quer plantão | Cloud ou SaaS | Parte da operação fica delegada | Comprar VPS e não manter a stack |
Você aceita atualizar com processo | VPS pode compensar | Há condição de manter versões e rollback | Atualizar sem backup ou teste |
Você precisa controlar acessos e dados | VPS, se houver operação | O desenho de acesso pode ficar sob sua gestão | Confundir controle com conformidade automática |
Você não tem cópia externa | Adie a VPS | Persistência local não é recuperação | Perder banco e configuração em uma falha |
Você nunca testou restore | Cloud ou corrija a rotina antes | Não há prova de recuperação | Descobrir falha no momento do incidente |
SaaS ganha quando a pergunta de negócio é simples e seu tempo não comporta administração de infraestrutura. VPS ganha quando você aceita a cadeia inteira: host, domínio, HTTPS, app, banco, cópia externa, atualização e restore. A escolha certa não é a que parece mais independente no papel. É a que continua funcionando quando algo sai do esperado.
Checklist antes de contratar a VPS
Definir qual pergunta de negócio o analytics precisa responder.
Escolher a ferramenta antes de escolher CPU, RAM e disco.
Confirmar o banco e os volumes persistentes da stack.
Criar domínio e HTTPS sem expor o painel de forma desnecessária.
Gerar e guardar segredos fora do repositório público.
Restringir contas administrativas e registrar quem tem acesso.
Planejar cópia externa de banco, configuração e dados persistentes.
Restaurar uma cópia em outro ambiente antes de confiar nela.
Monitorar memória, disco e crescimento do banco.
Atualizar versões com backup, leitura de mudanças e plano de retorno.
Qual VPS faz sentido depois da decisão?
Infraestrutura vem depois da matriz, não antes. Se você aceitou manter banco, atualização e restore, veja uma VPS da Hostinger para rodar analytics próprio. A rota é uma opção de infraestrutura para sua stack, não uma promessa de analytics gerenciado, preço, capacidade ou conformidade.
Quem prefere comparar alternativas pode consultar a oferta de VPS Servla e a oferta de VPS Turbo Cloud. Confirme recursos, condições e compatibilidade da oferta no momento de contratar. O requisito decisivo continua sendo o da ferramenta e da sua operação.
FAQ: dúvidas sobre analytics privado em VPS
Umami e Plausible usam cookies?
Os repositórios oficiais descrevem Umami e Plausible como ferramentas sem cookies. Isso caracteriza a abordagem declarada dos produtos, mas não substitui a revisão da sua implementação. Plugins, integrações, dados coletados e contexto de uso podem mudar a análise. Trate “sem cookies” como dado técnico, não como promessa jurídica universal.
Qual é mais leve: Umami, Plausible ou Matomo?
A pesquisa não executou benchmark comparativo, então não há base para declarar um vencedor de desempenho. Pelo desenho documentado, Umami reúne app e PostgreSQL, Plausible CE acrescenta ClickHouse e Matomo opera com PHP e MySQL ou MariaDB. Isso sugere menor ou maior atrito de stack, não uma medição de velocidade.
Plausible self-hosted precisa de ClickHouse?
A documentação da Community Edition inclui ClickHouse na stack e relaciona a ele a exigência de CPU com SSE 4.2 ou NEON. Ela também recomenda pelo menos 2 GB de RAM para ClickHouse e Plausible. Verifique o repositório e a versão da Community Edition no dia do deploy, pois componentes e requisitos podem mudar.
Umami precisa de PostgreSQL?
Para instalação pelo código, a documentação oficial pede PostgreSQL 12.14 ou superior. O Compose oficial usa Postgres 15 e um volume persistente para os dados. Isso torna backup, espaço em disco e restore do banco parte do plano desde o início, mesmo para uma instalação pequena.
Matomo precisa de qual servidor e banco?
O Matomo On-Premise exige webserver e banco. A página de requisitos atual informa, para Matomo 6.0.0, PHP 8.1 ou superior, MySQL 8 ou superior, ou MariaDB 10.6 ou superior. A mesma fonte oferece sizing por pageviews. Confirme a versão e os requisitos antes de instalar, porque documentação e releases evoluem.
Posso usar analytics sem banner de cookies?
Não há resposta universal. O Matomo documenta opções consent-free, mas também aponta casos que tipicamente exigem consentimento, incluindo certos processamentos de dados pessoais, marketing, publicidade e compartilhamento com terceiros. Avalie sua implementação e suas obrigações aplicáveis com orientação adequada quando necessário.
O que devo incluir no backup de analytics em VPS?
Inclua o banco, volumes ou arquivos persistentes, configuração de deploy, segredos guardados de forma segura e os elementos necessários para recriar domínio e acesso. Não basta copiar um container. O teste importante é restaurar em outro ambiente e verificar se aplicativo, banco e acesso voltam a funcionar sem dados reais expostos.
Quando SaaS é melhor que analytics auto-hospedado?
SaaS é melhor quando você quer dados e dashboard, mas não quer manter banco, TLS, atualizações, capacidade e recuperação. Também é racional quando ninguém consegue responder por um incidente. A VPS passa a compensar quando o controle operacional é uma necessidade real e a equipe consegue provar restore, não apenas subir containers.
Conclusão: escolha a operação que você consegue recuperar
Para Rafael, o veredito é claro. Use Umami para métricas essenciais com PostgreSQL. Use Plausible CE quando o produto justifica ClickHouse e o piso operacional maior. Use Matomo quando a amplitude da suite paga a administração extra. Escolha Cloud ou SaaS quando o seu negócio precisa de relatórios, não de um plantão de infraestrutura.
A Privacidade Operável é o critério que separa autonomia de improviso. Contrate VPS apenas depois de aceitar a rotina de banco, acesso, atualização, cópia externa e restore. A infraestrutura certa é a que sua operação consegue manter e recuperar.



