Requisitos do Uptime Kuma: tamanho do servidor e onde rodá-lo

Os requisitos do Uptime Kuma são pequenos, e o lugar onde ele roda importa mais que o tamanho do servidor. Um monitor que cai junto com seus sites não consegue avisar que eles caíram. Por isso, comece pela localização, depois dimensione o servidor e faça a configuração na ordem.

Onde ele deve rodar

A Sandstorm Media, uma agência de software, passou por isso quando migrou do UptimeRobot para o Uptime Kuma. A agência não queria o monitor perto dos próprios servidores, então contratou um servidor na nuvem em outro país.

Coloque o Uptime Kuma em um servidor que não rode nenhum dos sites, apps ou bancos de dados que ele verifica. Se o servidor de um site ficar sem memória, um deploy quebrar ou um banco de dados parar de responder, o monitor não cai junto, e você ainda recebe o alerta.

Um dos mantenedores do Uptime Kuma eleva o nível: você should not co-locate your uptime status page on the same infrastructure, datacenter or credit card. Se seus sites já rodam em servidores VPS da DreamHost, um segundo servidor para o Uptime Kuma fica no mesmo data center, porque a Central de Ajuda da DreamHost informa que todo VPS fica hospedado no data center US East, em Ashburn, na Virgínia. E ele também entra na mesma fatura. Se seus sites estão hospedados em outra empresa, o monitor fica totalmente fora da infraestrutura deles. De qualquer forma, você vai adicionar uma verificação externa nos passos de configuração abaixo, e é ela que avisa se o data center ou o próprio Uptime Kuma sair do ar.

De que tamanho de servidor ele precisa

O Uptime Kuma não publica requisitos mínimos. O README pede Node.js 20.4 ou mais recente em instalações sem Docker e para por aí, e um usuário não encontrou nenhum número de RAM ou CPU em toda a documentação. Então, nós medimos. Em 21 e 22 de outubro de 2026, rodamos o Uptime Kuma 2.5.6 no Docker a partir do compose.yaml do próprio projeto, com o banco de dados SQLite padrão, na nossa máquina de teste com 2 vCPUs e 4 GB (arm64), que não é um servidor da DreamHost. É a mesma configuração do Stack 4.

Sem nenhum monitor, ele usou cerca de 200 MiB de memória. Depois, adicionamos 200 monitores de sites com as configurações padrão, uma verificação a cada 60 segundos e sem novas tentativas, e todos os 200 entraram sem erros. Após 15 minutos de verificações, o contêiner usava 237 MiB e 0,45% da CPU, e 3.408 MB dos 3.904 MB da máquina continuavam livres. Nossas verificações acessavam uma pequena página de teste dentro da mesma máquina, então sites reais com HTTPS e redirecionamentos custam um pouco mais. O teste rodou uma única vez, por 15 minutos, então não diz nada sobre meses de histórico.

Um usuário do GitHub mediu cerca de 126 MiB para 200 verificações na versão 1, em um servidor do mesmo tamanho, e outro usuário na mesma discussão rodou cerca de 250 monitores em uma versão beta 2 com menos de 400 MiB em média.

O disco é o que merece atenção: cada verificação grava um resultado, então o banco de dados cresce conforme o número de monitores, a frequência das verificações e o tempo em que você mantém o histórico. No servidor da DreamHost, você pode guardar um ano de histórico ou mantê-lo para sempre. O usuário que projetou 9 GB chamou o número de an order of magnitude,, já que ele veio de uma amostra de 11 minutos. Nossa pasta de dados passou de 1,4 MB vazia para 5 MB depois de adicionarmos 200 monitores e 15 minutos de verificações, uma amostra curta demais para projetar meses. O Stack 4 tem 75 GB de disco, então confira df -h a cada um ou dois meses no começo. Se o espaço ficar pequeno, você pode migrar para um plano Stack maior, e seu ambiente vai junto.

Como você acessa o painel

O próprio guia de proxy reverso do Uptime Kuma recomenda um servidor web comum na frente, com HTTPS, e cita o Caddy como um que obtém e renova certificados sozinho. O servidor Uptime Kuma da DreamHost já vem montado assim: você acessa o painel pelo Caddy, com HTTPS de verdade no IP do servidor.

Páginas de status e badges foram feitos para ser públicos, então continuam acessíveis sem login.

Configure passo a passo

Você vai rodar os comandos abaixo como root, ou coloque sudo na frente se entrar com outro usuário.

Entre e atualize

1. Dê a ele um servidor que não hospede mais nada

   Contrate o Stack 4 com Uptime Kuma, a escolha da DreamHost para essa tarefa, e use esse servidor só para o monitor.

2. Leia o login criado na primeira inicialização

   A senha de administrador é gerada na primeira inicialização, antes que o painel possa ser acessado. Acesse o servidor por SSH e exiba a senha:

   bashCopiar

   cat /root/.uptime_kuma_credentials

   Faça login no IP do seu servidor via HTTPS. Guarde a senha em um gerenciador de senhas. Mais tarde, cada página de status pode ganhar um domínio próprio.

3. Atualize antes de adicionar qualquer coisa

   Um servidor novo começa na versão que a DreamHost fixou e testou, que pode estar atrás da versão mais recente do Uptime Kuma. O script de atualização não faz backup sozinho, então rode o backup primeiro:

   bashCopiar

   uptime-kuma-backup
   uptime-kuma-update

   O atualizador permanece na versão 2 e não pula para uma nova versão principal sem você. Em 15 de outubro de 2026, a versão mais recente do Uptime Kuma era a 2.5.6.

Configure o login e os alertas

1. Ative o login em duas etapas

   Vá em Settings, depois em Security, e clique em 2FA Settings. O Uptime Kuma mostra um QR code para você escanear com um app autenticador e depois pede um código do app para confirmar.

2. Diga ao Uptime Kuma para confiar no Caddy

   Vá em Settings, depois em Reverse Proxy e em HTTP Headers, e defina Trust Proxy como Yes, se ainda não estiver assim. O guia de proxy reverso do Uptime Kuma indica essa configuração para servidores acessados apenas por meio de um servidor web na frente. Assim, seus logs mostram o endereço real de cada visitante.

3. Adicione uma notificação e depois seus monitores

   Um monitor fora do ar só aparece no painel até você adicionar um serviço de notificação em Settings, depois Notifications. Conecte e-mail, Slack ou Telegram primeiro e, em seguida, crie seus monitores.

Acompanhe o monitor e guarde uma cópia

1. Aponte uma verificação externa para o Uptime Kuma

   O plano gratuito do UptimeRobot cobre 50 monitores com verificações a cada 5 minutos, e um deles pode vigiar o endereço do seu Uptime Kuma. Um comentarista do Hacker News usa o UptimeRobot exatamente para isso: I only use it to monitor the Uptime Kuma that monitors the rest of my homelab.

   Um heartbeat também funciona. O plano gratuito do Healthchecks.io monitora 20 tarefas, e a documentação de shell dele traz uma linha de curl para enviar o ping. Coloque uma verificação local rápida antes dela, para que o ping só seja enviado enquanto o Uptime Kuma responder, e adicione a linha ao crontab do servidor com crontab -e:

   bashCopiar

   */5 * * * * curl -fsS -m 5 -o /dev/null http://127.0.0.1:3001 && curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/your-uuid-here

   Esse heartbeat comprova que o servidor, as tarefas agendadas e o app estão rodando. A verificação do UptimeRobot também confirma que o painel responde via HTTPS de fora. Os planos pagos do UptimeRobot estão no nosso guia sobre preços do UptimeRobot comparados aos do Pingdom e do Better Stack.

2. Copie cada backup para fora do servidor

   O guia de migração para a v2 do Uptime Kuma diz que uma cópia do diretório de dados é o único backup com suporte, e o uptime-kuma-backup cria essa cópia como um arquivo local e mostra onde a salvou. No seu próprio computador, baixe esse arquivo:

   bashCopiar

   scp YOUR-USER@YOUR-SERVER-IP:/path/printed/by/the/script.tar.gz .

   Se você entrar com um usuário diferente de root, copie o arquivo para sua pasta pessoal com sudo cp e assuma a propriedade dele com sudo chown antes de baixá-lo.

   O script grava o arquivo no mesmo disco do Uptime Kuma. Essa cópia salva você de uma atualização malsucedida, mas não ajuda se você perder o servidor, então não a deixe lá.

3. Acompanhe as novas versões

   O Debian se atualiza em segundo plano. O contêiner do Uptime Kuma não se atualiza sozinho, então cada nova versão espera até você rodar os dois comandos de atualização de novo. Acompanhe as versões do Uptime Kuma pelo menu Watch do repositório no GitHub e atualize para a mais recente sempre que uma for lançada.

Perguntas frequentes sobre hospedagem do Uptime Kuma