Qual é a configuração mínima de VPS para Matomo Analytics self-hosted?

Para produção pequena, a configuração mínima prática é 2 vCPUs, 4 GB de RAM e 60 GB de SSD, com PHP, MySQL ou MariaDB e cron de arquivamento ativo. O Matomo pode instalar em recursos menores, mas isso deixa pouca margem para picos, backups e relatórios pesados. Se o site tiver muitos eventos customizados, e-commerce ou vários domínios monitorados, comece com 4 vCPUs e 8 GB de RAM. A decisão deve considerar hits mensais, retenção de dados e frequência de acesso ao painel.

Matomo self-hosted em VPS ajuda na adequação à LGPD?

Ajuda no controle técnico, mas não resolve LGPD sozinho. Ao rodar Matomo self-hosted, a empresa define onde os dados ficam, por quanto tempo são retidos, quem acessa relatórios e quais configurações de anonimização serão usadas. Isso facilita aplicar políticas internas e reduzir dependência de terceiros. Mesmo assim, consentimento, base legal, política de privacidade, contratos e governança precisam ser avaliados com apoio jurídico. A VPS entrega controle operacional, não substitui análise legal nem documentação de processos.

É melhor usar MySQL ou MariaDB para Matomo?

Matomo funciona com MySQL e MariaDB, desde que a versão seja compatível com a versão instalada do aplicativo. A melhor escolha costuma ser aquela que o time já sabe operar, monitorar e restaurar. Em VPS, o ponto decisivo não é apenas o nome do banco, mas configuração de InnoDB, memória disponível, índices, retenção e rotina de backup. Para bases maiores, acompanhe tempo de arquivamento, crescimento das tabelas e uso de I/O. Um banco bem ajustado faz mais diferença do que trocar tecnologia sem medir.

Preciso de datacenter no Brasil para rodar Matomo?

Datacenter no Brasil é recomendável quando o público, o site e a equipe estão majoritariamente no país. Isso tende a reduzir latência no endpoint de tracking e melhora a experiência de quem acessa o painel. A diferença pode ser pequena em sites simples, mas fica mais perceptível em operações com muitos eventos e uso frequente dos relatórios. Ainda assim, localização não corrige servidor subdimensionado, banco lento ou cron ausente. Avalie também estabilidade da rede, backups, suporte, painel e possibilidade de upgrade.

Como fazer backup correto de uma instalação Matomo?

O backup deve incluir banco de dados, arquivos da aplicação, configuração, plugins e informação sobre versões usadas. Para bases pequenas, dumps diários com compressão e cópia externa podem funcionar bem. Para bases maiores, avalie snapshots consistentes, janela de backup e restauração em servidor separado. O erro comum é confiar apenas em snapshot automático sem testar recuperação. Faça um restore periódico e registre quanto tempo leva para voltar. Antes de atualizar Matomo, PHP ou banco, gere snapshot ou backup verificável.

Quando devo separar o banco de dados do servidor Matomo?

Separe o banco quando a VPS começa a mostrar uso constante de CPU pelo MySQL ou MariaDB, I/O alto, cron de arquivamento demorado ou lentidão no painel durante consultas comuns. Outro sinal é quando backups do banco atrapalham a coleta de eventos. Em geral, instalações acima de 1 milhão de hits mensais, multi-site ou e-commerce com muitos eventos merecem análise de banco dedicado. Antes de separar, revise retenção, cron, plugins e configuração de memória. Separar componentes ajuda, mas também aumenta operação e custo.

Matomo Analytics self-hosted em VPS no Brasil

Resposta direta

Para rodar Matomo Analytics self-hosted no Brasil, a escolha mais segura costuma ser uma VPS ou Cloud Server com pelo menos 2 vCPUs, 4 GB de RAM, 60 GB de SSD ou NVMe, PHP atualizado, MySQL ou MariaDB bem configurado e backup externo testado. Essa base atende sites pequenos e médios com coleta própria de métricas, desde que o arquivamento do Matomo rode por cron e o banco não fique no limite de I/O. Para empresas com tráfego maior, múltiplos sites ou retenção longa de dados, o ponto de partida sobe para 4 vCPUs, 8 GB de RAM e disco rápido. A localização no Brasil ajuda quando o público e a equipe estão no país, pois reduz latência no painel e na coleta de eventos, mas não substitui boa configuração de banco, cache, segurança e restauração.

Resumo rápido

Matomo self-hosted dá controle sobre dados analíticos, retenção, plugins e integrações, mas exige manutenção do servidor.
Para produção básica, use 2 vCPUs, 4 GB de RAM e 60 GB de SSD ou NVMe como ponto de partida conservador.
Em tráfego maior, o gargalo costuma aparecer no MySQL ou MariaDB, não apenas no PHP.
O arquivamento por cron reduz carga no painel e evita que relatórios pesados sejam calculados durante a navegação.
Datacenter no Brasil tende a melhorar latência para equipes e visitantes brasileiros, desde que rede e DNS estejam bem configurados.
Backup precisa incluir arquivos, banco de dados e rotina de restauração testada, não só snapshot ocasional.
Uma VPS para Matomo deve ser escolhida pensando em crescimento de dados, retenção e volume de hits por mês.

Por que rodar Matomo Analytics self-hosted em VPS no Brasil

Matomo Analytics self-hosted entra no radar de empresas que querem medir tráfego, conversões e comportamento sem entregar todo o histórico analítico a uma plataforma SaaS. O atrativo não é apenas técnico. Há um componente de governança: decidir onde os dados ficam, por quanto tempo são mantidos, quem acessa os relatórios e quais integrações podem ler eventos, metas e funis. Para negócios que lidam com leads, portais logados, e-commerce ou dados sensíveis de navegação, esse controle pesa bastante.

Rodar no Brasil faz sentido quando a maior parte do público, do time de marketing e dos sistemas internos está no país. A coleta de eventos do Matomo usa requisições HTTP para o endpoint de tracking, normalmente matomo.php ou API equivalente. Em um site brasileiro, manter esse endpoint em uma região próxima pode reduzir alguns milissegundos por chamada e deixar o painel administrativo mais responsivo para a equipe. A diferença não transforma um servidor mal configurado em rápido, mas ajuda quando todo o restante está correto.

Privacidade, LGPD e controle operacional

Na prática, uma instalação self-hosted permite aplicar políticas mais claras de retenção. Um time pode manter dados detalhados por 180 dias, relatórios agregados por 24 meses e logs de servidor por menos tempo, conforme necessidade jurídica e operacional. Também é possível anonimizar IPs, ajustar consentimento de cookies, limitar acesso por perfil e integrar autenticação corporativa. Nada disso elimina a necessidade de análise jurídica, mas dá mais controle técnico do que depender apenas das opções de um serviço fechado.

Quando self-hosted faz sentido

Self-hosted vale mais para empresas que têm alguém capaz de operar Linux, PHP, banco de dados e backup. Se o time não consegue atualizar pacotes, monitorar disco ou restaurar um dump, a economia pode virar risco. Para quem já mantém aplicações PHP, o caminho é mais natural. Inclusive, muitos cuidados se parecem com os de uma VPS para aplicações PHP no Brasil: versão de PHP compatível, extensões corretas, OPcache ativado, servidor web ajustado e logs sob controle. A diferença é que o Matomo cresce pelo acúmulo de dados. Um blog pode ter poucos arquivos, mas milhões de registros analíticos depois de alguns meses.

Arquitetura recomendada para Matomo em produção

Uma instalação típica de Matomo em VPS usa Linux, Nginx ou Apache, PHP-FPM, MySQL ou MariaDB e um processo de cron para arquivamento. Essa arquitetura é simples, mas cada peça precisa estar dimensionada para o volume real de coleta. O Matomo não é só um painel bonito em PHP. Ele recebe eventos, grava visitas, processa relatórios, agrega métricas e consulta tabelas que podem crescer rápido. Se o servidor web responde bem, mas o banco fica saturado, o painel vai parecer lento e os relatórios podem demorar minutos.

Para uma instalação inicial, uma pilha comum seria Ubuntu LTS ou Debian estável, Nginx, PHP 8.2 ou 8.3 quando suportado pela versão instalada do Matomo, MariaDB 10.11 ou MySQL 8, HTTPS com Let’s Encrypt e firewall liberando apenas 80, 443 e SSH restrito. O diretório do Matomo deve ficar fora de caminhos improvisados, com permissões claras para o usuário do PHP-FPM. Em produção, evite instalar painel de hospedagem pesado se a VPS tiver pouca RAM. Um painel pode facilitar operação, mas também consome memória e adiciona superfície de ataque.

PHP, MySQL ou MariaDB e servidor web

O PHP precisa de extensões como pdo_mysql, mysqli, curl, gd, mbstring, xml, zip e suporte a timezone correto. OPcache deve estar ativo, pois reduz recompilação de scripts PHP. Em uma VPS de 4 GB, uma configuração inicial razoável pode usar pm = dynamic, pm.max_children = 12 a 20, dependendo do consumo médio por processo. Não copie valores de outro servidor sem medir. Se cada processo PHP usa 80 MB e você abre 30 filhos, só o PHP pode consumir 2,4 GB.

Cron, arquivamento e ingestão de eventos

O cron de arquivamento é uma das diferenças entre instalação amadora e produção estável. Sem cron, relatórios podem ser calculados durante o acesso ao painel, deixando a experiência lenta. Uma rotina comum roda core:archive a cada hora ou a cada 30 minutos, dependendo do tráfego. Em sites maiores, separar ingestão e relatórios pode ser necessário. Por exemplo, o tracking continua recebendo eventos ao longo do dia, enquanto relatórios agregados são processados em horários planejados. Isso reduz picos e deixa o painel mais previsível.

Como dimensionar CPU, RAM, disco e rede

Dimensionar uma VPS para Matomo exige olhar para hits, sites monitorados, retenção e frequência de relatórios. Um site institucional com 50 mil pageviews por mês é muito diferente de um e-commerce com 3 milhões de eventos mensais, campanhas com UTM, metas, busca interna e eventos customizados. A conta também muda quando a empresa monitora 20 sites em uma única instalação. O Matomo centralizado facilita governança, mas concentra carga em um único banco.

Para produção pequena, 2 vCPUs e 4 GB de RAM costumam ser um ponto de partida mais confortável do que 1 vCPU e 1 GB. O Matomo até pode instalar em planos menores, mas produção real envolve sistema operacional, PHP-FPM, banco de dados, servidor web, agente de monitoramento, logs e processos de backup. Com 1 GB, qualquer pico de relatório ou dump de banco pode empurrar o sistema para swap. Swap salva o servidor de cair em alguns casos, mas deixa a aplicação lenta. Em analytics, lentidão no banco aparece rápido.

Configurações por volume de tráfego

Um cenário conservador fica assim: até 100 mil hits por mês, 2 vCPUs, 4 GB de RAM e 60 GB de disco. Entre 100 mil e 1 milhão de hits por mês, pense em 4 vCPUs, 8 GB de RAM e 100 GB ou mais de SSD rápido. Acima disso, comece a avaliar banco separado, maior IOPS, tuning de queries, retenção mais curta e arquivamento mais frequente. Não existe número universal, porque eventos customizados, metas, dimensões personalizadas e plugins alteram muito a carga.

Disco e banco de dados são parte do mesmo problema

O disco não serve apenas para armazenar arquivos do Matomo. Ele sustenta tabelas, índices, temporários, logs binários, dumps e snapshots. Em instalações com retenção longa, 60 GB podem desaparecer rápido. Uma política de retenção de 25 meses com dados brutos detalhados pesa mais do que relatórios agregados. Se você está comparando planos, leia também o contexto de VPS para MySQL e MariaDB no Brasil, porque o gargalo de analytics frequentemente mora no banco. SSD ou NVMe ajuda em I/O aleatório, mas não compensa índices mal cuidados, cron ausente ou tabelas sem manutenção.

Na rede, o consumo costuma ser moderado para sites pequenos, mas não ignore transferência mensal. Cada pageview pode gerar uma ou mais requisições de tracking. Se você usa eventos de scroll, cliques, formulários e mídia, o volume sobe. A recomendação prática é monitorar tráfego de saída e entrada por 30 dias antes de migrar campanhas grandes para a instalação.

Banco de dados, retenção e performance do Matomo

O banco de dados é o coração do Matomo. Quase todo problema de escala passa por ele em algum momento. Tabelas de log recebem visitas, ações, conversões, conteúdo pesquisado e eventos. Depois, o arquivamento transforma parte desse volume em relatórios agregados. Quando a retenção de dados brutos é longa e o site tem muitos eventos, o banco cresce em tamanho e complexidade. O resultado aparece como painel lento, cron demorando demais, uso alto de CPU pelo MySQL ou MariaDB e consultas que disputam I/O com backups.

Uma instalação saudável começa com parâmetros simples. Em uma VPS de 8 GB dedicada ao Matomo, o innodb_buffer_pool_size pode ficar em torno de 3 GB a 5 GB, dependendo do que mais roda no servidor. Em uma VPS de 4 GB, algo entre 1 GB e 2 GB pode ser mais prudente. O objetivo é manter índices e dados frequentes em memória sem sufocar PHP, sistema operacional e processos de backup. Também faz sentido ajustar max_connections com calma. Abrir conexões demais não aumenta capacidade se a CPU e o disco não acompanham.

Tabelas grandes e arquivamento

A retenção precisa ser uma decisão de produto, não um esquecimento técnico. Manter dados brutos para sempre parece confortável, até o banco passar de dezenas para centenas de gigabytes. Para muitos negócios, dados detalhados por 6 ou 12 meses e relatórios agregados por mais tempo já resolvem análises de marketing. O Matomo oferece configurações para excluir logs antigos e manter relatórios processados. Essa limpeza deve ser alinhada com LGPD, auditoria e necessidades de BI.

Ajustes práticos de MySQL e MariaDB

Três rotinas ajudam bastante: arquivamento por cron, análise periódica de tamanho das tabelas e backup com janela definida. Um exemplo prático é rodar o arquivamento a cada hora, verificar semanalmente tabelas maiores que 5 GB e revisar mensalmente a retenção. Se o servidor também hospeda o site principal, cuidado dobrado. Analytics e aplicação competem pelos mesmos recursos. Em produção séria, separar Matomo do site transacional evita que uma campanha de mídia deixe o checkout mais lento.

Também evite executar dumps pesados no horário de pico. mysqldump pode funcionar bem em bases pequenas, mas bases maiores pedem ferramentas e estratégia mais cuidadosas, como compressão, baixa prioridade, replica temporária ou backup em nível de volume com consistência. Antes de confiar em qualquer método, restaure em outro servidor e meça o tempo. Backup que nunca foi restaurado é só uma hipótese otimista.

Segurança, backup e rotina de operação

Matomo concentra dados de navegação, campanhas e conversões. Isso não deve ficar em uma VPS configurada no improviso. A primeira camada é reduzir superfície de ataque: SSH com chave, login root desativado, firewall ativo, pacotes atualizados e HTTPS obrigatório. Em Nginx ou Apache, bloqueie acesso direto a diretórios sensíveis, arquivos de configuração e caminhos que não precisam ser públicos. O Matomo publica recomendações de segurança no painel de diagnóstico, e elas devem ser tratadas como tarefas operacionais, não como aviso decorativo.

Outro ponto simples é isolar usuários. O processo PHP não precisa rodar como root. O usuário do deploy não precisa ter acesso irrestrito ao banco. A senha do banco usada pelo Matomo deve ter permissões adequadas para a aplicação, sem privilégios administrativos globais. Para equipes maiores, acesso ao painel deve seguir perfis. Marketing não precisa necessariamente administrar plugins, usuários e configurações globais. Menos privilégio reduz dano quando uma credencial vaza.

Hardening básico do servidor

Uma base razoável inclui ufw ou firewall equivalente, Fail2ban para reduzir tentativas repetidas de login, atualizações automáticas de segurança quando compatíveis com sua política, logs enviados para destino externo e monitoramento de CPU, RAM, disco e HTTP 5xx. Em uma VPS pequena, agentes pesados podem atrapalhar. Escolha ferramentas enxutas. O essencial é receber alerta antes de o disco chegar a 95%, antes de o certificado expirar e antes de o cron de arquivamento ficar parado por dias.

Backups que realmente ajudam na restauração

Backup de Matomo precisa cobrir banco, arquivos de configuração, plugins e, idealmente, informação sobre versão instalada. Snapshot de volume é útil, mas não substitui dump consistente do banco quando você precisa restaurar apenas dados analíticos. Um bom desenho combina snapshot antes de atualizações, backup diário do banco, cópia externa e teste mensal de restauração. Se esse tema ainda não está maduro na sua operação, o guia de VPS com backup automático ajuda a separar recurso de conveniência, snapshot e estratégia real de recuperação.

Na atualização do Matomo, faça o básico: snapshot ou backup antes, leitura das notas da versão, execução em janela de menor tráfego e verificação do painel depois. Plugins também precisam de cuidado. Um plugin abandonado pode quebrar compatibilidade ou abrir risco. Em empresas, mantenha inventário simples: versão do Matomo, versão do PHP, versão do banco, plugins ativos, data do último restore testado e responsável técnico.

Tabela comparativa de perfis de VPS para Matomo

A tabela abaixo não é um comparativo de preços. Ela organiza perfis técnicos para facilitar a escolha antes de olhar provedores. Recursos como preço, região exata, tipo de disco, snapshots e franquia de transferência mudam por plano e precisam ser confirmados no site oficial de cada fornecedor antes da contratação. Para o contexto brasileiro, provedores com região no Brasil ou boa conectividade para o país podem reduzir latência, mas a escolha final também depende de suporte, forma de pagamento, painel, backups e política de rede.

Perfil de uso	Tráfego estimado	Configuração inicial	Banco de dados	Disco e backup	Observação operacional
Site institucional e blog	Até 100 mil hits/mês	2 vCPUs, 4 GB RAM	MySQL ou MariaDB no mesmo servidor	60 GB SSD, backup diário externo	Cron horário e retenção definida já resolvem boa parte dos riscos
Portal, SaaS pequeno ou e-commerce leve	100 mil a 1 milhão de hits/mês	4 vCPUs, 8 GB RAM	Banco no mesmo servidor bem ajustado ou instância separada	100 GB SSD ou NVMe, snapshot antes de updates	Monitorar IOPS, tamanho das tabelas e tempo do `core:archive`
Multi-site, mídia ou e-commerce em campanha	Acima de 1 milhão de hits/mês	4 a 8 vCPUs, 16 GB RAM	Preferir banco dedicado ou servidor separado	200 GB ou mais, backup com teste de restore	Planejar retenção, arquivamento frequente e alertas de capacidade
Ambiente corporativo com compliance	Varia por política interna	4 vCPUs, 8 GB RAM como base	Banco com permissões restritas e logs auditáveis	Backup criptografado e cópia fora da região principal	Exigir documentação de acesso, restauração e atualização

Em termos de provedores, nomes como DigitalOcean, Vultr, Akamai Cloud, AWS Lightsail, Google Cloud, Azure, Hostinger, Locaweb e LetsCloud aparecem com frequência em discussões sobre VPS, Cloud Server e cloud instances. Para este artigo, nenhum preço específico deve ser tratado como definitivo sem revisão humana. A informação volátil envolve mensalidade, região disponível, armazenamento, banda e recursos inclusos. A LetsCloud pode entrar no radar quando o projeto busca presença no Brasil e contratação local, mas disponibilidade de localidade, NVMe, snapshots e backup deve ser confirmada por plano no momento da compra.

A melhor leitura da tabela é por risco. Se o Matomo é apenas apoio para um blog, a configuração intermediária talvez seja excesso. Se ele orienta investimento de mídia, funil de vendas e decisões de produto, economizar em RAM, disco e backup pode sair caro. Analytics parado durante uma campanha significa perda de visibilidade justamente quando os dados são mais valiosos.

Recomendações por perfil

Dev solo ou consultor

Para um dev solo que atende pequenos clientes ou mantém sites próprios, a recomendação prática é começar com 2 vCPUs, 4 GB de RAM e 60 GB de SSD. Essa configuração dá margem para PHP-FPM, banco, Nginx, cron e backup sem viver no limite. O segredo está em não transformar a VPS em depósito de tudo. Evite rodar Matomo, WordPress pesado, banco de produção, painel administrativo e ferramentas de automação no mesmo plano pequeno. Se forem poucos sites e até 100 mil hits por mês, uma única instalação bem cuidada pode funcionar por bastante tempo. Configure cron, retenção e alerta de disco desde o primeiro dia.

Time de marketing e produto

Times de marketing e produto costumam precisar de mais previsibilidade. Eles acessam relatórios em horário comercial, cruzam campanhas, criam metas e comparam períodos. Para esse perfil, 4 vCPUs, 8 GB de RAM e 100 GB de disco são uma base mais confortável. O Matomo passa a ser ferramenta de trabalho, não experimento técnico. Defina perfis de acesso, documente nomenclatura de campanhas, configure metas com padrão e revise eventos customizados para não registrar ruído demais. Um erro comum é medir cada microinteração do site e depois descobrir que ninguém usa esses eventos. Métrica demais também consome banco.

Produção com alto tráfego

Em produção com alto tráfego, pense no Matomo como uma aplicação de dados. A arquitetura pode exigir VPS separada para aplicação, banco dedicado, disco rápido, backup com janela própria e monitoramento de cron. A partir de 1 milhão de hits por mês, teste carga antes de campanhas grandes. Meça tempo de resposta do endpoint de tracking, duração do arquivamento, crescimento diário do banco e consumo de I/O durante backups. Uma base com 8 vCPUs, 16 GB de RAM e 200 GB de armazenamento pode ser adequada para alguns cenários, mas não substitui medição. Se a empresa depende dos relatórios para receita, tenha plano de restauração e migração documentado.

Checklist antes de contratar a VPS

Antes de contratar, transforme a escolha em perguntas objetivas. Quantos sites serão medidos nos próximos 12 meses? Qual volume mensal de pageviews e eventos? A empresa precisa manter dados brutos por quanto tempo? Quem vai aplicar atualizações? Quem recebe alerta quando o disco cresce rápido? Essas respostas evitam escolher uma VPS olhando só para vCPU e preço. Matomo é uma ferramenta que acumula valor com o tempo, mas também acumula dados, índices, logs e responsabilidades.

Um bom teste inicial é estimar eventos por visita. Um site simples pode registrar 1 pageview por página. Um e-commerce pode registrar pageview, busca, clique em produto, add to cart, checkout, compra, eventos de mídia e dimensões personalizadas. Se 100 mil visitas geram 800 mil eventos, o banco terá comportamento diferente de um blog com 100 mil pageviews simples. Também vale estimar crescimento. Campanhas pagas podem multiplicar tráfego em poucos dias, e o Matomo precisa absorver isso sem derrubar o painel.

Perguntas técnicas para evitar migração precoce

Confirme se o provedor permite upgrade de CPU, RAM e disco sem reinstalação complexa. Verifique se há snapshots sob demanda, backup automático opcional, console de emergência, métricas de uso e opção de região próxima ao público. Não publique decisão baseada em preço promocional sem revisar renovação, impostos, banda e condições. Se o projeto exige compliance, peça informações sobre datacenter, contrato, logs e suporte. Esses dados mudam, então a última atualização de informações de concorrentes neste artigo deve ser registrada como 2026-08-04.

Sinais de que o plano ficou pequeno

Alguns sintomas indicam hora de otimizar ou subir plano: cron core:archive demorando mais que o intervalo entre execuções, uso constante de swap, disco acima de 80%, MySQL com CPU alta por longos períodos, painel levando mais de 5 segundos para abrir relatórios comuns e backups invadindo horário de pico. Primeiro revise retenção, plugins, índices e cron. Depois considere upgrade. Jogar mais CPU sem corrigir arquivamento ausente ou banco mal configurado pode apenas adiar o problema.

A escolha final deve equilibrar privacidade, operação e custo. VPS para Matomo Analytics self-hosted no Brasil é uma boa alternativa quando a empresa quer controle real dos dados e tem maturidade mínima para cuidar da infraestrutura. Com 2 vCPUs e 4 GB de RAM você começa de forma segura em projetos pequenos. Com 4 vCPUs, 8 GB de RAM e banco bem ajustado, atende operações mais sérias. Acima disso, trate como plataforma de dados, com arquitetura, monitoramento e restauração testada.