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

**Autor:** Maicon Ramos
**Categoria:** Hospedagem & VPS
**Publicado:** 2026-09-11
**Atualizado:** 2026-09-11
**Canonical:** https://runzos.com/umami-plausible-matomo-vps-2026

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.

## Leia também

- [Google ADK e A2A Protocol: o que muda para agentes de IA conectados?](https://runzos.com/google-adk-a2a-protocol-agentes-ia-2026/)
- [LangGraph vs CrewAI em 2026: qual framework usar para agentes de IA?](https://runzos.com/langgraph-vs-crewai-agentes-ia-2026/)
- [OpenAI Agents SDK em VPS: vale a pena rodar agentes fora do notebook?](https://runzos.com/openai-agents-sdk-vps-2026/)
- [Referência MCP privada com Docker em VPS: guia prático](https://runzos.com/como-configurar-servidor-mcp-docker-vps/)