Runzos

Umami, Plausible ou Matomo em VPS: qual analytics privado escolher em 2026?

Por Maicon Ramos · · 12 min de leitura

Ilustração de três opções de analytics conectadas a VPS, banco e backup externo.
Navegue por tópicos
  1. O veredito antes do Docker: qual ferramenta cabe na sua operação?
  2. Umami, Plausible CE e Matomo: o que muda por baixo do dashboard?
  3. O banco escolhe a VPS: CPU, RAM e disco sem plano mágico
  4. Privacidade sem promessa jurídica: cookies, consentimento e acesso
  5. O custo invisível: atualização, backup e restore
  6. Quando VPS compensa e quando SaaS gerenciado ganha
  7. Checklist antes de contratar a VPS
  8. Qual VPS faz sentido depois da decisão?
  9. FAQ: dúvidas sobre analytics privado em VPS
  10. 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.

Comparação visual entre três stacks de analytics e seus bancos de dados em VPS.

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.

Fluxo de dados do site ao analytics, banco, backup externo e restauração em nova VPS.

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

  1. Definir qual pergunta de negócio o analytics precisa responder.

  2. Escolher a ferramenta antes de escolher CPU, RAM e disco.

  3. Confirmar o banco e os volumes persistentes da stack.

  4. Criar domínio e HTTPS sem expor o painel de forma desnecessária.

  5. Gerar e guardar segredos fora do repositório público.

  6. Restringir contas administrativas e registrar quem tem acesso.

  7. Planejar cópia externa de banco, configuração e dados persistentes.

  8. Restaurar uma cópia em outro ambiente antes de confiar nela.

  9. Monitorar memória, disco e crescimento do banco.

  10. 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.

analytics privadoVPSUmamiPlausible AnalyticsMatomoself-hosted

Compartilhe:

Leia também