Hospedar Uptime Kuma em um VPS gerenciado: monitore seus serviços sem pausa

O que o Uptime Kuma monitora

O Uptime Kuma consulta seus serviços em intervalos regulares, até a cada 20 segundos, guarda o histórico das respostas e avisa assim que um deles deixa de responder. Ele é usado por uma interface web, disponível em vários idiomas.

• Os monitores: HTTP e HTTPS, busca de uma palavra-chave na página, requisição JSON, TCP, WebSocket, ping, registro DNS, contêineres Docker e monitor “push” para uma tarefa agendada que sinaliza sozinha a própria execução.
• Os alertas: mais de 90 serviços de notificação, entre eles Telegram, Discord, Slack e e-mail.
• As páginas de status: várias páginas públicas, cada uma em um domínio próprio, se você quiser.
• Os certificados: as informações do certificado HTTPS de cada serviço monitorado.
• A conta: autenticação em duas etapas e passagem por um proxy para os monitores que precisam dele.

Coloque o Uptime Kuma em um servidor diferente dos serviços que ele monitora. Em uma máquina separada, ele enxerga a queda de fora e envia o alerta enquanto seus serviços estão parados.

O que a licença MIT permite

O Uptime Kuma é publicado sob a licença MIT. Ela autoriza usar, copiar, modificar, mesclar, publicar, distribuir, sublicenciar e vender o software, com uma condição: manter o aviso de copyright e o texto da licença em toda cópia.

Você pode, portanto, rodar o Uptime Kuma em uma empresa, monitorar nele os serviços de seus clientes e abrir páginas de status para eles, sem licença a comprar.

A instalação com Docker Compose

A documentação do Uptime Kuma começa pelo Docker Compose. Em um servidor com o Docker instalado, crie uma pasta e baixe o arquivo oficial:

mkdir uptime-kuma
cd uptime-kuma
curl -o compose.yaml https://raw.githubusercontent.com/louislam/uptime-kuma/master/compose.yaml

O arquivo do projeto publica a porta 3001 em todos os endereços do servidor. Atrás de um proxy reverso, limite-a ao endereço local, como sugere o README:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"

docker compose up -d

• Uma porta publicada em 127.0.0.1: por padrão, o Docker publica em todos os endereços do servidor, antes das regras do firewall ufw. Localmente, o Uptime Kuma só é acessado pelo proxy reverso.
• Uma pasta data em um disco local: ela guarda o banco kuma.db, os arquivos enviados e as capturas de tela. O projeto descarta o NFS e os demais sistemas de arquivos em rede, porque o SQLite precisa de bloqueios de arquivo confiáveis.
• A tag 2 acompanha a versão 2 do Uptime Kuma, e a passagem para uma versão principal seguinte continua sendo uma escolha sua.
• A imagem 2-slim é mais leve, cerca de 185 MB para baixar contra 620 MB: ela deixa de lado o Chromium e o MariaDB integrado que a imagem 2 traz. A imagem 2 é a que o projeto recomenda, e um monitor “Browser Engine” pede então um Chromium externo com a 2-slim.

Na primeira execução, abra a interface: um assistente faz você escolher o banco de dados e depois criar a conta de administrador. Ative a autenticação em duas etapas já no primeiro login.

O projeto não informa números de memória nem de processador: o tamanho depende da quantidade de serviços a monitorar e da frequência desejada. Em um VPS gerenciado, descreva-nos o uso e recomendamos o tamanho adequado.

HTTPS e WebSocket: o proxy reverso

Em uma rede pública, o projeto pede HTTPS. O Uptime Kuma se apoia no WebSocket: o proxy reverso precisa repassar os cabeçalhos Upgrade e Connection. Ele é servido na raiz de um domínio ou subdomínio, e o wiki dele descarta subpastas como example.com/uptimekuma.

Com o Caddy

O Caddy obtém e renova sozinho o certificado e repassa o WebSocket sem nenhum ajuste a mais:

uptime.example.com {
    reverse_proxy 127.0.0.1:3001
}

Com o Nginx e o Certbot

server {
    listen 80;
    server_name uptime.example.com;

    location / {
        proxy_pass         http://localhost:3001;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection "upgrade";
        proxy_set_header   Host $host;
    }
}

Em seguida, o Certbot instala o certificado Let's Encrypt e o redirecionamento para HTTPS, e depois renova o certificado por conta própria:

sudo certbot --nginx -d uptime.example.com

Quando o Uptime Kuma só é acessível pelo proxy, abra as configurações dele, “Settings”, “Reverse Proxy”, “HTTP Headers”, e mude “Trust Proxy” para “Yes”: os logs passam a mostrar o endereço real dos visitantes.

SQLite ou MariaDB

Desde a versão 2, o Uptime Kuma oferece três bancos, à escolha no assistente da primeira execução:

Para fixar a escolha de antemão, sem passar pelo assistente, as variáveis UPTIME_KUMA_DB_TYPE, UPTIME_KUMA_DB_HOSTNAME, UPTIME_KUMA_DB_PORT, UPTIME_KUMA_DB_NAME, UPTIME_KUMA_DB_USERNAME e UPTIME_KUMA_DB_PASSWORD são acrescentadas ao serviço no compose.yaml.

As notificações, e-mail incluído

Um monitor só serve se o alerta chega até você. Declare seus canais em “Settings”, “Notifications”, envie uma mensagem de teste por cada um e prepare dois, por exemplo um aplicativo de mensagens e o e-mail: se um cair, o outro assume.

Para o e-mail, o Uptime Kuma se conecta a um servidor SMTP. Em um VPS Simafri, o envio passa por um relay autenticado, na porta 587: o endereço de uma conta de e-mail que você já tem, ou o Simafri Suite.

Backups e atualizações

Desde a versão 2, o backup da pasta data é o único método que o projeto suporta. Com o SQLite ou o MariaDB integrado, tudo está nela. Um banco SQLite copiado durante uma gravação pode ficar corrompido: pare o contêiner durante a cópia, sabendo que os monitores param com ele.

docker compose stop
tar -czf uptime-kuma-$(date +%F).tar.gz data
docker compose start

Atualizar

O wiki do projeto dá dois comandos, a partir da pasta do compose.yaml. A pasta data continua no lugar:

docker compose pull
docker compose up -d --force-recreate

Leia as notas de versão antes de cada atualização: algumas trazem correções de segurança, como a 2.5.9, de 31 de outubro de 2026. Um backup feito logo antes dá a você um retorno simples.

A passagem da versão 1 para a versão 2 pede mais cuidado: faça backup da pasta data, com o contêiner parado, e deixe a migração ir até o fim, porque uma migração interrompida obriga a restaurar o backup. O projeto mediu cerca de 7 minutos para 20 monitores e 90 dias de histórico, e bem mais em uma máquina modesta ou com mais monitores.

Quem faz o quê em um VPS gerenciado

A auto-hospedagem exige cuidar do servidor além da aplicação. Em um VPS gerenciado, nossas equipes assumem o servidor e acompanham sua instância de forma proativa; o Uptime Kuma continua sendo seu software, com as configurações e os dados dele.

Se você preferir que nossas equipes intervenham na própria aplicação, esse serviço é cobrado por hora ou por valor fechado, com o orçamento informado antes da intervenção.