Essas três ferramentas não resolvem exatamente os mesmos problemas.

Se você só quer saber quantos visitantes recebe por dia e quais páginas são mais populares, comece com Auto-hospedar o Umami para análise de sites em uma VPS. Se precisar de conversões de metas, busca interna, rastreamento de downloads, fluxos de usuários ou políticas de retenção de dados mais detalhadas, implantar o Matomo é o melhor investimento.

Para uma instalação em servidor único com até 100.000 visualizações de página por mês, a recomendação mínima oficial do Matomo é 2 núcleos de CPU, 2 GB de RAM e 50 GB de SSD. Como o MariaDB também roda no Docker, vale a pena comprar memória adicional.

O crescimento do disco depende do volume de tráfego, do número de eventos, do período de retenção de logs e de se os dados brutos de visita são armazenados, então não dá para estimar apenas pelo tamanho dos arquivos do site. O sistema usado aqui é o Ubuntu 24.04 LTS; aponte os registros A / AAAA de analytics.example.com para a VPS com antecedência e abra apenas SSH, 80 e 443.

Instale o Docker Engine e o plugin Compose a partir do repositório oficial do Docker e depois confirme que está usando o Compose v2:

docker --version
docker compose version

Crie os diretórios de implantação e backup:

sudo mkdir -p /opt/matomo/backups
sudo chown -R "$USER":"$USER" /opt/matomo
cd /opt/matomo

Se esta VPS também executa outros contêineres, revise primeiro a lista de verificação de configuração de produção do Docker Compose em uma VPS para padronizar a rotação de logs, as verificações de integridade e a estratégia de atualização.

A conta do banco de dados da aplicação e a senha de root devem ser diferentes:

openssl rand -hex 32
openssl rand -hex 32
nano .env
chmod 600 .env

Grave os dois valores aleatórios em /opt/matomo/.env:

MARIADB_ROOT_PASSWORD=替换成第一组随机值
MATOMO_DATABASE_PASSWORD=替换成第二组随机值

Nunca faça commit de .env no Git nem escreva senhas em texto simples no arquivo Compose.

Crie /opt/matomo/compose.yaml:

services:
  db:
    image: mariadb:11.4
    container_name: matomo-db
    restart: unless-stopped
    environment:
      MARIADB_ROOT_PASSWORD: "${MARIADB_ROOT_PASSWORD:?set MARIADB_ROOT_PASSWORD in .env}"
      MARIADB_DATABASE: matomo
      MARIADB_USER: matomo
      MARIADB_PASSWORD: "${MATOMO_DATABASE_PASSWORD:?set MATOMO_DATABASE_PASSWORD in .env}"
    command:
      - --max-allowed-packet=64M
      - --innodb-buffer-pool-size=512M
    volumes:
      - matomo_db:/var/lib/mysql
    healthcheck:
      test:
        - CMD-SHELL
        - >-
          mariadb-admin ping -h 127.0.0.1 -uroot
          -p$$MARIADB_ROOT_PASSWORD --silent
      interval: 10s
      timeout: 5s
      retries: 20
      start_period: 30s
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

  app:
    image: matomo:5-apache
    container_name: matomo
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    ports:
      - "127.0.0.1:8080:80"
    environment:
      MATOMO_DATABASE_HOST: db
      MATOMO_DATABASE_ADAPTER: mysql
      MATOMO_DATABASE_TABLES_PREFIX: matomo_
      MATOMO_DATABASE_USERNAME: matomo
      MATOMO_DATABASE_PASSWORD: "${MATOMO_DATABASE_PASSWORD:?set MATOMO_DATABASE_PASSWORD in .env}"
      MATOMO_DATABASE_DBNAME: matomo
      PHP_MEMORY_LIMIT: 512M
    volumes:
      - matomo_data:/var/www/html
    healthcheck:
      test:
        - CMD-SHELL
        - >-
          php -r '$$c=@fsockopen("127.0.0.1",80,$$e,$$s,5);
          exit($$c ? 0 : 1);'
      interval: 30s
      timeout: 10s
      retries: 10
      start_period: 60s
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

volumes:
  matomo_db:
    name: matomo_db
  matomo_data:
    name: matomo_data

matomo:5-apache acompanha as versões de correção e menores do Matomo 5, então uma única reconstrução não vai pular direto para a próxima versão principal. mariadb:11.4 está fixado na série 11.4, evitando uma tag principal flutuante em produção. Em uma máquina de 2 GB, você pode primeiro alterar --innodb-buffer-pool-size para 256M; não deixe o cache do banco de dados consumir a memória necessária ao sistema e ao PHP.

Antes de iniciar, faça o Compose expandir as variáveis e verifique o YAML:

docker compose config >/dev/null
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 app

A primeira inicialização cria o banco de dados e os arquivos do Matomo. Quando os dois serviços mostrarem healthy, verifique o ponto de entrada local:

curl -I http://127.0.0.1:8080
sudo ss -lntp | grep ':8080'

O endereço de escuta deve ser 127.0.0.1:8080, não 0.0.0.0:8080. O MariaDB não tem configuração ports, e a porta 3306 nunca deve ser visível pela internet.

Edite /etc/caddy/Caddyfile:

analytics.example.com {
    encode zstd gzip
    reverse_proxy 127.0.0.1:8080

    request_body {
        max_size 64MB
    }
}

Verifique e carregue a configuração:

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
curl -I https://analytics.example.com

O Caddy repassa X-Forwarded-For, X-Forwarded-Host e X-Forwarded-Proto. Quando o Matomo está atrás de um proxy reverso HTTPS, verifique também a configuração de [General] em config/config.ini.php após a instalação:

[General]
assume_secure_protocol = 1
force_ssl = 1
proxy_ip_read_last_in_list = 0
trusted_hosts[] = "analytics.example.com"

trusted_hosts é a proteção de nome de host que o Matomo habilita por padrão; não a desative simplesmente para silenciar avisos. Depois de alterá-la, execute:

docker compose exec app php console config:get General
docker compose exec app php console cache:clear

Se você não tem familiaridade com certificados, DNS e configuração de múltiplos domínios do Caddy, consulte o guia completo de proxy reverso com Caddy em uma VPS.

Abra https://analytics.example.com no navegador. Na página do banco de dados, preencha:

Não preencha localhost nem 127.0.0.1; esses apontam para o próprio contêiner do Matomo, não para o MariaDB na rede do Compose.

O assistente então cria o administrador, adiciona o primeiro site e gera o código de rastreamento JavaScript. Coloque o código de rastreamento antes de </head> em todas as páginas do seu site; para WordPress, Shopify ou CMS comuns, prefira plugins oficiais ou da comunidade com manutenção ativa para que o código não se perca após uma atualização do tema.

Após a instalação, verifique:

docker compose exec app php console diagnostics:run
docker compose exec app php console core:archive --url=https://analytics.example.com
docker compose logs --tail=100 app

Depois visite seu site em uma janela anônima e confirme que uma visita de teste aparece em "Visitantes em tempo real" do Matomo. Ver a página carregar normalmente não prova que as solicitações de rastreamento e as tarefas de arquivamento estão funcionando.

O Matomo agrega os dados brutos de visita em relatórios. Sites pequenos podem acionar o arquivamento por solicitações do navegador, mas a recomendação oficial é mudar para o arquivamento CLI agendado quando o tráfego ultrapassar 500 visualizações de página por dia ou a resposta do servidor ficar lenta. Em produção, configure o Cron diretamente: é mais previsível.

Primeiro execute manualmente uma vez e confirme que não há erros:

cd /opt/matomo
docker compose exec -T app php /var/www/html/console core:archive \
  --url=https://analytics.example.com

Confirme o caminho absoluto do Docker:

command -v docker

Depois edite o Cron do root:

sudo crontab -e

Adicione uma linha; se o passo anterior não foi /usr/bin/docker, substitua pelo caminho real:

5 * * * * cd /opt/matomo && /usr/bin/docker compose exec -T app php /var/www/html/console core:archive --url=https://analytics.example.com >> /var/log/matomo-archive.log 2>&1

Quando o arquivamento CLI funcionar de forma estável, desative o arquivamento acionado pelo navegador:

docker compose exec app php console config:set General enable_browser_archiving = 0
docker compose exec app php console config:get General enable_browser_archiving

Verifique os logs regularmente para que o Cron não falhe repetidamente por problemas de caminho, certificado ou banco de dados:

sudo tail -n 100 /var/log/matomo-archive.log

A auto-hospedagem significa apenas que você controla a infraestrutura; não significa que seu site esteja automaticamente em conformidade com o GDPR, a CCPA ou as leis locais de privacidade. No mínimo, verifique estes itens em "Administração → Privacidade":

• Para a anonimização de IP, mascare 2 ou 3 bytes e ative-a antes de coletar tráfego real pela primeira vez;
• Defina períodos de retenção para os logs de visita brutos e os relatórios históricos; não armazene indefinidamente dados sem valor de negócio;
• Se você não precisa identificar usuários entre sessões, use rastreamento sem cookies e verifique como a precisão muda;
• Habilite um mecanismo para os usuários optarem por não ser rastreados e indique na política de privacidade a finalidade da coleta e o período de retenção;
• Não coloque informações pessoais como e-mails, nomes ou observações de pedido em URLs, títulos de página ou dimensões personalizadas;
• Decida se você precisa de uma plataforma de gestão de consentimento com base na sua região, método de rastreamento e finalidade; não trate "Matomo" como uma conclusão universal que dispensa o banner de cookies.

O Matomo oferece capacidade de anonimização de IP por padrão, mas a configuração final e a base legal continuam sendo responsabilidade do operador do site. Faça os responsáveis jurídicos ou de privacidade confirmarem as necessidades do negócio antes de fazer alterações.

Um backup completo inclui pelo menos o MariaDB e o volume matomo_data. O banco de dados contém dados de site, visitas e relatórios, enquanto o volume de dados contém config/config.ini.php, plugins e arquivos da aplicação.

Criar um backup do banco de dados:

cd /opt/matomo
mkdir -p backups
docker compose exec -T db sh -c \
  'mariadb-dump --single-transaction --quick --routines --triggers \
  --databases "$MARIADB_DATABASE" -uroot -p"$MARIADB_ROOT_PASSWORD"' \
  | gzip > "backups/matomo-db-$(date +%F-%H%M).sql.gz"

Fazer backup do volume de dados do Matomo:

docker run --rm \
  -v matomo_data:/source:ro \
  -v "$PWD/backups:/backup" \
  alpine sh -c 'tar -C /source -czf /backup/matomo-data.tar.gz .'

Os arquivos de backup não devem ficar apenas na mesma VPS. Sincronize-os criptografados com armazenamento de objetos ou outra máquina e realize simulações de restauração regularmente. Você pode seguir o processo de backup externo e verificação do tutorial de simulação de backup e restauração em uma VPS.

Para restaurar, primeiro interrompa as gravações do Matomo, restaure o volume de dados, depois importe o SQL em um MariaDB novo e, por fim, inicie os serviços e execute:

docker compose exec app php console core:update
docker compose exec app php console diagnostics:run
docker compose exec app php console core:archive --url=https://analytics.example.com

A aceitação da restauração deve verificar em conjunto o login do administrador, os relatórios históricos, as visitas em tempo real, o script de rastreamento e o arquivamento por Cron, não apenas se a página inicial abre.

O Matomo lida com dados de visitantes e contas de administrador, então não adie as atualizações de segurança por muito tempo. Antes de atualizar, leia as notas de versão do Matomo e as mudanças da imagem e depois execute:

cd /opt/matomo
docker compose config >/dev/null
# 先完成并验证数据库、matomo_data 两类备份
docker compose pull
docker compose up -d
docker compose exec app php console core:update
docker compose exec app php console diagnostics:run
docker compose ps

Após atualizar, verifique pelo menos:

• A página inicial HTTPS e o painel administrativo estão acessíveis;
• Novas visitas em tempo real chegam ao Matomo;
• Os relatórios históricos não desapareceram;
• core:archive é executado com sucesso manualmente;
• Os logs do Caddy, do Matomo e do MariaDB não mostram erros persistentes.

Não use a tag latest para atualizar automaticamente entre versões principais, nem faça backup apenas do arquivo Compose. O que é realmente insubstituível é o banco de dados, a configuração e os plugins que você instalou.

• O Matomo escuta apenas em 127.0.0.1:8080 e o MariaDB não mapeia nenhuma porta pública
• Domínio, HTTPS, hosts confiáveis e configuração do proxy reverso estão consistentes
• O administrador usa uma senha forte e tem autenticação de dois fatores habilitada quando disponível
• As visitas de teste aparecem nos visitantes em tempo real
• O arquivamento CLI a cada hora é bem-sucedido e os logs são observáveis
• Anonimização de IP, cookies, retenção de dados e políticas de exclusão estão confirmados
• Tanto o banco de dados quanto matomo_data têm backups externos
• Uma simulação de restauração foi concluída e o tempo de recuperação registrado
• Há backups antes das atualizações e o rastreamento e o arquivamento são verificados após elas

Depois de concluir essas etapas, esta instalação do Matomo não é apenas "a página abre", mas um ambiente de produção com HTTPS, persistência, controles de privacidade, arquivamento automático e capacidade de recuperação. Para equipes que realmente valorizam os dados próprios e as conversões do site, esse custo operacional é o preço do controle dos dados.