Alternativas leves ao Uptime Kuma para uma VPS pequena

O Uptime Kuma é agradável de usar e muito completo, mas sua combinação de Node.js, interface web, histórico, banco local e diversos tipos de monitor pode ser maior do que o necessário em uma VPS pequena. Esta pesquisa procura substitutos realmente mais enxutos, priorizando software livre, gratuito e autohospedável, sem confundir tamanho do binário ou da imagem Docker com consumo real de memória.

O objetivo não é declarar que o Uptime Kuma é “ruim”. A versão atual consultada, 2.5.0, continua ativa, oferece uma experiência muito conveniente e reúne mais de 90 integrações de notificação, vários tipos de monitor e páginas de status em uma única aplicação. A pergunta prática é outra: quanto dessa conveniência é necessário no seu servidor e onde o monitor deve rodar para continuar funcionando quando a VPS cair?

Resumo executivo

O Gatus é a melhor substituição geral. É um programa em Go distribuído como binário ou container único, usa memória, SQLite ou PostgreSQL, testa HTTP, TCP, ICMP, DNS, TLS e outros protocolos, possui condições expressivas, alertas e página de status. Mantém quase tudo que importa para uma instalação pessoal ou pequena empresa, mas troca o painel de administração do Kuma por configuração em YAML. Está ativo, é licenciado sob Apache-2.0 e teve a versão 5.36.0 publicada em 19 de maio de 2026.

Em uma fotografia local controlada feita para esta pesquisa, o Gatus com SQLite, três checks HTTPS e retenção limitada usou 12,21 MiB, enquanto uma instalação nova e ainda sem monitores do Uptime Kuma 2.5.0 usou 130,3 MiB. Naquele instante, o Gatus ocupou aproximadamente 10,7 vezes menos memória. Suas imagens ocupavam, respectivamente, cerca de 23,9 MiB e 572,7 MiB. Esse ensaio não é um benchmark universal, mas confirma que há uma diferença material no cenário testado.

As melhores escolhas por perfil são:

• Substituto completo e leve: Gatus com SQLite.
• Status público e checks em binário nativo: Vigil.
• Interface próxima do Kuma: Statping-ng, aceitando manutenção mais lenta; ou Updu em laboratório, aceitando juventude e uma licença ainda mal documentada.
• Mínimo absoluto e página estática: TinyStatus.
• Vigilância local de processos e autorrecuperação: Monit, combinado com um monitor externo.
• Nenhum consumo na VPS: UptimeFlare em Cloudflare Workers/D1, Upptime no GitHub ou um SaaS gratuito como UptimeRobot.
• Quem já usa Prometheus: Blackbox Exporter; começar toda a pilha apenas para substituir o Kuma geralmente adiciona complexidade em vez de removê-la.
• Cron, backup e tarefas agendadas: Healthchecks, como complemento e não como substituto de checks HTTP externos.

Há uma ressalva arquitetural importante: um monitor instalado na mesma VPS monitorada não detecta de forma confiável a queda total dessa VPS, do provedor, da rota ou da energia. A arquitetura mais robusta e ainda simples é executar Gatus em uma segunda máquina ou usar UptimeFlare/Upptime/UptimeRobot fora da VPS, mantendo Monit dentro dela para reiniciar processos e avisar sobre problemas locais.

Metodologia e critérios

A pesquisa foi concluída em 8 de agosto de 2026. Foram consultadas apenas fontes primárias: documentação oficial, repositórios, arquivos de licença, páginas de releases, avisos de segurança e páginas comerciais oficiais. Projetos foram avaliados pelos seguintes critérios:

1. Arquitetura: linguagem/runtime, quantidade de processos e serviços externos.
2. Persistência: memória, arquivos, SQLite ou banco separado.
3. Cobertura: HTTP, TCP, ICMP, DNS, TLS, push/heartbeat e monitoramento local.
4. Operação: interface, configuração, alertas, página pública, backup e atualização.
5. Manutenção: releases e atividade verificável, sem interpretar apenas número de estrelas como qualidade.
6. Licença e modelo: open source, open core ou serviço proprietário.
7. Leveza demonstrável: medições reproduzíveis quando disponíveis e, no restante, arquitetura como indício — nunca como benchmark inventado.

Como interpretar “leve” nesta pesquisa

As classificações são relativas e deliberadamente conservadoras:

• Ultraleve: binário nativo, script periódico ou site estático, sem banco servidor e sem painel administrativo pesado.
• Leve: um binário/container com interface e SQLite ou armazenamento em memória.
• Intermediário: runtime maior, mais de um processo ou banco externo, ainda que o projeto se anuncie como leve.
• Fora do objetivo: plataforma de observabilidade com múltiplos serviços, agentes e bancos.

Tamanho de download não equivale a RAM. Um binário de 17 MB não necessariamente consome 17 MB, e uma imagem de 20 MB pode usar mais memória do que uma imagem maior. Na ausência de uma medição comparável, o campo de consumo é marcado como não informado e a conclusão se apoia apenas na arquitetura e nas dependências.

Ponto de partida: o que o Uptime Kuma entrega

O repositório oficial do Uptime Kuma descreve um servidor Node.js com painel web, banco integrado, intervalos a partir de 20 segundos, monitores HTTP(S), TCP, palavra-chave, JSON, WebSocket, ping, DNS, push, Steam e Docker, além de páginas de status e mais de 90 serviços de notificação. Fora do Docker, a documentação requer Node.js 20.4 ou superior e recomenda PM2; em Docker, tudo chega empacotado na imagem oficial.

Isso explica parte do consumo: não se trata apenas de um processo que faz curl. O Kuma mantém interface interativa, autenticação, histórico, gráficos, diversos protocolos e integrações. A linha 2.x também recebeu otimizações de histórico. Portanto, relatos antigos de vazamento ou uso de memória de 2023 não são evidência suficiente contra a versão atual e não foram usados nesta conclusão.

O recurso Browser Engine, quando utilizado, adiciona Chromium e pertence a uma categoria naturalmente mais pesada do que checks HTTP comuns. Essa diferença deve ser considerada na migração: trocar um teste real de navegador por uma requisição HTTP simples reduz consumo, mas também reduz o que está sendo validado.

Medição local: Gatus versus Uptime Kuma

Foi executado um ensaio curto e reproduzível para obter uma ordem de grandeza, não para simular produção.

Ambos rodaram em Docker Desktop com containers Linux. A leitura foi feita com docker stats --no-stream; o tamanho veio de docker image inspect. Uma execução adicional do Gatus com armazenamento apenas em memória marcou 10,33 MiB.

Na fotografia principal, o Kuma usou aproximadamente 10,7 vezes a RAM do Gatus com SQLite, e sua imagem era aproximadamente 23,9 vezes maior. A comparação é conservadora em um sentido — o Kuma estava vazio e o Gatus já fazia três checks —, mas continua limitada: é um único computador, uma única execução, poucos segundos de aquecimento e uma leitura instantânea de CPU. Não demonstra picos, crescimento do banco, vazamentos, comportamento após 24 horas ou consumo na sua VPS. O teste correto antes de migrar deve usar seus próprios endpoints, intervalos e notificadores.

Comparação geral

As melhores alternativas com interface ou página de status

1. Gatus: a recomendação principal

O Gatus oferece o melhor equilíbrio desta lista. A configuração é um arquivo, mas o resultado inclui uma interface de status limpa, agrupamento de serviços, condições avançadas, histórico controlável, incidentes/anúncios, badges, endpoint de métricas e autenticação OIDC. O armazenamento padrão pode ficar em memória; para uma VPS real, SQLite entrega persistência sem introduzir outro servidor.

Entre os checks documentados estão HTTP/HTTPS, TCP, ICMP, DNS, gRPC e STARTTLS. As condições conseguem validar código HTTP, corpo, latência, certificado e domínio. A documentação no próprio repositório lista notificadores como e-mail, Discord, Slack, Telegram, Pushover, Gotify, ntfy, Teams e webhooks, entre outros.

Vantagens:

• consumo baixo confirmado no pequeno ensaio desta pesquisa;
• binário e container únicos;
• SQLite suficiente para uso pessoal e pequena empresa;
• configuração versionável e fácil de restaurar;
• checks e condições mais poderosos do que uma simples verificação de status 200;
• licença permissiva Apache-2.0 e manutenção recente.

Limitações:

• não há painel CRUD equivalente ao Kuma para cadastrar cada monitor clicando;
• editar YAML exige atenção a indentação e reinício/reload conforme o método usado;
• monitoramento de navegador real e alguns tipos muito específicos do Kuma podem exigir outra ferramenta;
• página e administração vivem no mesmo aplicativo; autenticação e publicação devem ser planejadas.

Para o seu perfil, a perda do formulário gráfico provavelmente é um preço pequeno pela redução de dependências e consumo.

2. Vigil: status público com binário Rust

O Vigil monitora HTTP, TCP, SSH e ICMP, aceita scripts e “reporters” que enviam estado, e possui o componente Vigil Local para serviços privados. O servidor produz uma página pública de status, admite anúncios e envia alertas por e-mail, Twilio, Slack, Zulip, Telegram, Pushover, Gotify, XMPP, Matrix, Webex e webhook, conforme o README oficial.

A licença é MPL-2.0, e a versão 1.29.0 foi publicada em março de 2026. A ausência de uma pilha Node e de um banco servidor sugere implantação enxuta, mas não encontrei benchmark oficial comparável de RAM. É a segunda melhor escolha quando a página pública e os alertas importam mais que análise histórica detalhada.

3. Statping-ng: interface tradicional, atividade mais lenta

O Statping-ng preserva a proposta visual do antigo Statping em um fork comunitário: binário Go, UI, gráficos, página pública, notificações e SQLite/MySQL/PostgreSQL. A licença é GPL-3.0.

O projeto é atraente para quem não quer editar YAML, mas a última release verificada foi a 0.93.0, de 4 de junho de 2025, e a atividade recente é bem menor que a do Gatus. O README cita uma imagem próxima de 20 MB e binários ao redor de 17 MB; isso informa armazenamento, não RAM. Se escolhido, use SQLite e o container único em vez da composição com nginx e PostgreSQL, a menos que esses serviços já existam.

4. Updu: quase um “Kuma leve”, mas ainda jovem

O Updu combina um binário Go, uma SPA SvelteKit embutida e SQLite, sem dependências externas em runtime. Oferece 21 tipos de monitor, painel, páginas de status, incidentes, manutenção, OIDC, métricas Prometheus e notificadores como webhook, Discord, Slack, SMTP, Gotify e ntfy.

É uma proposta muito alinhada ao pedido, mas ainda estava na versão 0.7.2. O site afirma licença MIT, porém não foi possível confirmar um arquivo LICENSE na raiz do repositório na data da pesquisa. Para uso empresarial, isso precisa ser resolvido antes da adoção. O guia oficial de escala descreve decisões cuidadosas sobre cache e temporários, mas não publica RSS de memória. Recomendação: testar, acompanhar e não substituir ainda o monitor crítico da empresa.

5. Peekaping: muitos recursos, explicitamente beta

O Peekaping usa backend Go e frontend React e suporta SQLite, PostgreSQL ou MongoDB. Sua lista de monitores é ampla: HTTP, TCP, ping, DNS, push, Docker, gRPC, SNMP, bancos, MQTT, RabbitMQ e Kafka, com status pages, badges, MFA e vários alertas.

O próprio README o declara beta, e a ferramenta de migração do Uptime Kuma ainda aparece no roadmap. A licença é MIT. É um projeto interessante para laboratório e talvez se torne a alternativa visual mais completa, mas hoje não supera a combinação de maturidade e simplicidade do Gatus.

6. ciao: somente HTTP, com UI simples

O ciao é uma aplicação Ruby on Rails voltada a HTTP/HTTPS. Usa SQLite interno, dispensa banco e cache externos, oferece UI/API, validade de TLS, SMTP, webhooks e métricas Prometheus opcionais. É MIT e teve atividade em 2026.

A simplicidade funcional é boa, mas Rails continua sendo um runtime maior que um binário Go/Rust e não há medição oficial que prove vantagem sobre Gatus. Faz sentido quando todos os alvos são HTTP e a preferência por uma interface supera o desejo de minimizar dependências.

Opções ultraleves e sem painel completo

TinyStatus: checks periódicos e HTML estático

O TinyStatus usa Python 3.11, um arquivo YAML e checks HTTP, ping ou porta para gerar index.html, history.html e history.json. Não precisa manter um servidor web de aplicação: nginx, Caddy ou até hospedagem estática pode servir os arquivos gerados. A licença é MIT.

É provavelmente a solução mais simples para uma página pública de poucos endpoints. Em troca, não há administração por navegador e o README não documenta um sistema interno de notificações. A atividade do projeto também é baixa, com última movimentação relevante em 2024. O pequeno código e a saída estática reduzem o risco operacional, mas não eliminam o risco de manutenção lenta.

Monit: o melhor complemento dentro da VPS

O Monit é um daemon nativo que observa processos, programas, arquivos, diretórios, sistemas de arquivos, recursos e serviços de rede. Ele pode alertar e, principalmente, agir: reiniciar um processo, executar um programa ou parar um serviço que entrou em condição ruim. O software livre Monit usa AGPL-3.0; o produto centralizado M/Monit é comercial e não deve ser confundido com ele.

Sua interface HTTP(S) é administrativa e simples, não uma página pública de status equivalente à do Kuma. Para segurança, mantenha-a em 127.0.0.1, socket Unix, VPN ou proxy autenticado. A combinação ideal é Monit local + Gatus/UptimeFlare externo: o primeiro reage a falhas internas; o segundo continua observando quando a máquina inteira some.

Updo: CLI/TUI Go para checks diretos

O Updo é um binário Go com CLI/TUI, pacotes Debian/RPM/APK e container. Faz requisições HTTP customizáveis, POST/PUT, assertions, mede resposta e validade SSL e pode enviar webhook, Slack ou Discord. A versão 0.4.8 foi publicada em maio de 2026 e a licença é MIT.

Não oferece painel web, página pública ou banco histórico local. É adequado para scripts, terminais, pipelines e uma instalação que já tenha outra forma de visualizar métricas.

Monika: sintéticos em YAML, mas ainda Node.js

A Monika é uma CLI em TypeScript/Node.js 20 capaz de testar HTTP/API, TLS e bancos como MySQL, MariaDB, PostgreSQL, MongoDB e Redis, com vários canais de alerta. É MIT, configurável em YAML e o repositório permanecia ativo em 2026.

Ela dispensa uma interface persistente e pode ser menor que uma instalação completa do Kuma, porém continua dependendo de Node.js. Sem um benchmark comum, não deve ser chamada de ultraleve apenas porque é CLI. É interessante quando os checks de API e banco são mais importantes que status page e histórico visual.

MinMon: alarmes locais em Rust

O MinMon é um binário Rust sem banco e sem GUI. Monitora processos, systemd, containers, memória, disco e temperatura e reage por e-mail, webhook ou processo. Sua licença é dupla MIT/Apache-2.0.

Não testa endpoints externos como função principal. Ocupa o mesmo nicho local do Monit, com escopo menor e configuração moderna, e funciona melhor como complemento do que como substituto direto.

Prometheus e Blackbox Exporter

O Prometheus Blackbox Exporter executa probes HTTP/HTTPS, DNS, TCP, ICMP e gRPC e exporta métricas. É um binário Go licenciado sob Apache-2.0, sem banco próprio, página pública ou mecanismo de alerta completo.

Para formar um sistema equivalente, são necessários:

• Prometheus para agendamento, coleta e histórico;
• Alertmanager para agrupar, silenciar e enviar alertas;
• Grafana, se uma interface e dashboards forem desejados;
• uma página de status separada, se o público precisar acompanhar incidentes.

Se Prometheus e Alertmanager já existem na sua infraestrutura, adicionar Blackbox Exporter é uma escolha eficiente e evita duplicar séries de tempo. Se nada disso existe e a única necessidade é verificar 10 ou 20 sites, instalar quatro componentes para substituir um Kuma contradiz o objetivo de simplificar. O armazenamento local do Prometheus também exige política própria de retenção e backup.

Soluções que retiram o consumo da VPS

UptimeFlare: open source sobre Cloudflare Workers e D1

O UptimeFlare usa Cloudflare Workers e D1 para executar checks e manter a página de status. Seu README documenta até 50 checks em frequência de um minuto, 90 dias de histórico, HTTP/HTTPS/TCP, requisições customizadas, incidentes, manutenção, páginas privadas, domínio próprio, API JSON e notificações por Apprise. O código é Apache-2.0.

Na prática, ele zera o consumo da sua VPS e coloca o monitor fora do mesmo domínio de falha. Não é, porém, infraestrutura totalmente autohospedada: funcionamento, limites, cobrança futura e disponibilidade dependem da Cloudflare.

Há um alerta de segurança obrigatório. A vulnerabilidade GHSA-36q9-v7p3-vj6v / CVE-2026-29779 permitia exposição de configuração e credenciais em versões afetadas entre 21 de setembro de 2025 e 4 de março de 2026. A correção foi publicada em 4 de março de 2026. Quem instalou nesse intervalo deve atualizar imediatamente, revisar o procedimento de migração indicado pelo projeto e rotacionar segredos potencialmente expostos.

Upptime: GitHub como monitor e histórico

O Upptime usa GitHub Actions para verificar endpoints, Issues para incidentes, commits para histórico e GitHub Pages para uma página Svelte. O código é MIT e os dados de histórico usam ODbL. Não requer container ou processo na VPS e pode verificar em intervalo nominal de cinco minutos.

O custo dessa arquitetura é previsibilidade. A documentação oficial dos eventos do GitHub Actions informa que tarefas agendadas podem sofrer atrasos e até ser descartadas em períodos de alta carga. Em repositórios públicos, workflows agendados também podem ser desativados após 60 dias sem atividade. É excelente para sites públicos e monitoramento sem urgência de segundos, mas não para uma SLA rigorosa.

UptimeRobot e Better Stack: gratuitos, mas proprietários

O plano gratuito do UptimeRobot oferece 50 monitores com frequência de cinco minutos, status page e checks HTTP, palavra-chave, ping, porta e heartbeat; a página oficial afirma que uso comercial é permitido. O Better Stack oferece no plano gratuito 10 monitores, 10 heartbeats, uma página de status e alertas básicos.

Ambos eliminam completamente o consumo local e observam a VPS de fora. Não são open source nem autohospedados, e dados sobre alvos, incidentes e contatos ficam com um fornecedor. Para uma VPS única e sem espaço para outro servidor, ainda podem ser a solução operacionalmente mais sensata.

Heartbeats e tarefas agendadas

O Healthchecks não consulta sites periodicamente. Ele espera receber um ping de um cron, backup, job ou script e alerta quando o ping atrasa, chega cedo demais ou informa falha. Possui painel, API e mais de 25 integrações. É BSD-3-Clause, usa Python 3.12 e Django 6 e aceita SQLite no modo simples ou PostgreSQL/MySQL/MariaDB.

Isso o torna excelente para responder a perguntas que um check HTTP não responde: “o backup terminou?”, “o certbot rodou?”, “o relatório noturno foi gerado?”. Use-o junto de Gatus ou outro monitor de endpoints, não no lugar deles.

Projetos que parecem adequados, mas não resolvem bem este objetivo

Kener

O Kener é MIT, usa SvelteKit/Node.js e cria belas páginas de status, incidentes e manutenções. A instalação atual inclui Redis. É uma boa ferramenta editorial de status, mas não há evidência de que Node + Redis seja “bem mais leve” que o Kuma em uma VPS pequena.

Kuvasz

O Kuvasz é ativo, AGPL-3.0 e oferece UI, status pages, HTTP, SSL, heartbeat, ping, API, Prometheus/OpenTelemetry e muitos alertas. A versão 3.10.0 saiu em maio de 2026. A stack Kotlin/JVM e o conjunto amplo de recursos não sustentam a promessa de economia radical sem medição própria.

Maintenant

O Maintenant combina Go, SQLite e UI e monitora HTTP/TCP, heartbeat e containers. A Community Edition é AGPL, mas o projeto é open core: recursos e limites adicionais ficam no plano Pro. A integração Docker pede acesso ao socket do Docker, que equivale a poder administrativo sobre o host; não monte /var/run/docker.sock apenas por conveniência. A aplicação também depende de proxy externo para autenticação em alguns cenários e sua telemetria anônima deve ser revisada. É mais superfície do que o necessário para apenas verificar uptime.

Checkmate, Tianji, OpenStatus e OneUptime

• Checkmate oferece uptime, métricas de servidores e página de status, mas a composição inclui aplicação e MongoDB. É AGPL-3.0 e ativo, porém não minimalista.
• Tianji agrega uptime, analytics, agentes e telemetria em Node/TypeScript com PostgreSQL. É Apache-2.0 e ativo, mas seu escopo aumenta dependências.
• OpenStatus é uma plataforma moderna AGPL-3.0; a implantação completa envolve dashboard, checker, bancos/analytics e vários componentes. O pequeno tamanho anunciado para um checker isolado não representa o sistema todo.
• OneUptime é uma suíte completa de observabilidade e incidentes com PostgreSQL, Redis, ClickHouse e outros serviços. A própria documentação de dimensionamento recomenda recursos muito acima de uma VPS pequena. É o oposto do objetivo desta pesquisa.

Páginas de status que não são monitores completos

Não confunda status page com motor de monitoramento:

• cState é um gerador estático Hugo, MIT e quase sem runtime depois do build. O próprio projeto informa que não monitora automaticamente “out of the box”. É um bom frontend separado.
• Cachet 3.x é uma página de status em PHP 8.3 com SQLite ou bancos servidores. A licença atual é source-available customizada, não uma licença open source OSI; além disso, não substitui sozinho os checks do Kuma.
• Staytus usa Rails, MySQL e worker de e-mail. A documentação continua ligada a versões antigas e o mantenedor reconheceu pouca manutenção. É legado, não uma escolha nova.

Projetos abandonados ou que não devem ser adotados

Uptime original de fzaninotto

O repositório fzaninotto/uptime foi arquivado em dezembro de 2024 e o README declara que não é mais mantido. As dependências documentadas incluem Node.js 0.10 e MongoDB 2.1, hoje inadequados. Não confundir esse projeto com Uptime Kuma ou Upptime.

Cabot

O Cabot também declara no próprio README que não é mantido ativamente e procura mantenedores. Sua aplicação Django e integrações antigas não compensam o risco de operar um monitor crítico sem manutenção regular.

Statping original

O projeto Statping original parou de ser mantido. Se a interface for desejada, o candidato atual é o fork comunitário Statping-ng, ainda com a ressalva de ritmo lento mencionada antes.

Licenças e modelos: o que pode ser usado na empresa

Esta tabela não é aconselhamento jurídico. Para uso interno comum, as opções recomendadas são simples; modificações distribuídas, oferta como serviço ou incorporação em produto exigem leitura da licença aplicável.

Recomendações práticas

Cenário A: você tem uma segunda máquina ou outro local sempre ligado

Use Gatus + SQLite fora da VPS monitorada. Pode ser outra VPS mínima, um servidor doméstico estável ou uma máquina de administração. Mantenha Monit dentro da VPS para processos críticos. Essa é a melhor combinação de independência, consumo baixo e controle.

Cenário B: existe apenas uma VPS e o objetivo é liberar RAM

Use UptimeFlare atualizado, Upptime ou UptimeRobot gratuito para os endpoints públicos. UptimeFlare preserva código aberto, mas depende da Cloudflare; Upptime é simples e auditável, mas os horários do GitHub não são rígidos; UptimeRobot é proprietário, porém fácil e externo ao domínio de falha.

Instalar Gatus na mesma VPS ainda economiza memória em relação ao ensaio do Kuma, mas não resolve a observabilidade da queda total do host.

Cenário C: você quer continuar administrando pelo navegador

Teste Statping-ng com SQLite durante uma semana. Se a atividade mais lenta do projeto incomodar, prefira Gatus e aceite editar YAML. Acompanhe Updu e Peekaping, mas trate ambos como pilotos: o primeiro é pré-1.0 e precisa esclarecer a licença; o segundo se declara beta.

Cenário D: você já usa Prometheus

Adicione Blackbox Exporter e regras no Alertmanager. Não instale Grafana, Prometheus, Alertmanager e exporter do zero apenas para dez URLs se Gatus resolve tudo em um processo.

Cenário E: a prioridade é vigiar serviços da própria VPS

Instale Monit ou MinMon localmente, com painel não exposto à internet, e mantenha um monitor externo para alcance público. Para cron e backups, adicione Healthchecks ou seu serviço hospedado compatível.

Instalação recomendada do Gatus

Uma composição mínima, fixada na versão usada no ensaio, pode ser:

services:
  gatus:
    image: ghcr.io/twin/gatus:v5.36.0
    container_name: gatus
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - ./config.yaml:/config/config.yaml:ro
      - ./data:/data

O bind em 127.0.0.1 evita publicar o painel diretamente. Coloque Caddy, nginx, seu proxy reverso ou Tailscale à frente, com TLS e autenticação quando a página não for pública.

Exemplo de config.yaml sem credenciais:

storage:
  type: sqlite
  path: /data/gatus.db
  maximum-number-of-results: 100
  maximum-number-of-events: 50

ui:
  title: "Estado dos serviços"

endpoints:
  - name: "Site principal"
    group: "Produção"
    url: "https://example.com/health"
    interval: 30s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 2000"

Depois, configure o canal de alerta seguindo os exemplos oficiais do Gatus, preferindo variáveis de ambiente ou secrets a tokens gravados no repositório. Ajuste failure-threshold e success-threshold para evitar alertas por uma única falha transitória. Limites de resultados e eventos mantêm o SQLite previsível; aumente-os somente se o histórico for necessário.

Antes de usar a composição em produção:

1. substitua o domínio de exemplo;
2. valide permissões e persistência do diretório data;
3. fixe a imagem pelo digest se sua política exigir builds imutáveis;
4. faça backup de config.yaml e data/gatus.db;
5. monitore o próprio Gatus a partir de outro local, quando possível;
6. não publique headers, tokens ou credenciais na página de status.

Plano de migração do Uptime Kuma

1. Inventariar antes de desligar

Registre todos os monitores e, para cada um, anote:

• URL/host, tipo e intervalo;
• método, headers, corpo, autenticação e validade TLS;
• timeout, tentativas e limiares de falha/recuperação;
• dependências entre serviços e janelas de manutenção;
• canais de notificação e responsáveis;
• páginas de status, domínios e audiência;
• histórico que precisa ser preservado por política empresarial.

Faça backup da instalação atual. Não dependa de uma importação automática: o Gatus não documenta um migrador nativo do Kuma, e o migrador do Peekaping ainda estava no roadmap.

2. Mapear equivalências e lacunas

Checks HTTP, TCP, ping, DNS, certificado e push geralmente possuem equivalente. Monitores de Browser Engine, Steam, Docker socket, MQTT, bancos e fluxos muito específicos precisam ser comparados individualmente. Manter temporariamente o Kuma para dois monitores especiais pode ser melhor do que forçar um equivalente mais fraco.

3. Executar os dois em paralelo

Rode o candidato por pelo menos sete dias com os mesmos endpoints e intervalos. Compare:

• alertas perdidos e falsos positivos;
• tempo até detectar e até reconhecer recuperação;
• comportamento em falha de DNS, TLS, timeout e status incorreto;
• RAM em repouso e após 24 horas;
• pico e média de CPU durante as rodadas;
• crescimento diário do SQLite ou volume;
• clareza das mensagens recebidas por quem está de plantão.

Um teste mais forte usa 20 endpoints, intervalo de 60 segundos, mesma retenção e dois notificadores em cada candidato, após 24 horas de aquecimento.

4. Mover o ponto de observação

Sempre que possível, coloque o monitor fora da VPS observada. Para serviços privados, use rede privada como Tailscale, um reporter/push ou checks locais complementares; não abra portas administrativas na internet apenas para facilitar o monitoramento.

5. Fazer o corte reversível

Troque primeiro os alertas e a página pública. Mantenha o Kuma parado, mas com volume e backup preservados, por uma ou duas semanas. Depois de confirmar que todos os tipos, incidentes e contatos funcionam, remova o container antigo. Essa sequência permite retorno rápido sem apagar histórico prematuramente.

Segurança e manutenção

• Um painel de uptime revela nomes, tecnologias, padrões de falha e horários de manutenção. Publique somente o que clientes realmente precisam ver.
• Não exponha UI administrativa sem TLS e autenticação. Prefira localhost + proxy, VPN ou OIDC.
• Não grave tokens de Telegram, SMTP, webhooks ou headers de API no Git público.
• Evite montar o socket Docker. Quem controla esse socket normalmente controla o host.
• Fixe versões, leia release notes e atualize regularmente. Em UptimeFlare, confirme explicitamente que a correção da CVE-2026-29779 está aplicada.
• Teste o canal de alerta e o caminho de recuperação; “monitor verde” sem notificação funcional é falsa segurança.
• Faça backup da configuração. O histórico pode ser descartável no uso pessoal, mas incidentes empresariais podem ter retenção exigida.
• Mantenha um contato de emergência que não dependa do domínio, SMTP ou servidor que está sendo monitorado.

Decisão final

Para substituir o Uptime Kuma em uma VPS pequena, eu adotaria esta ordem:

1. Gatus com SQLite, executado fora da VPS monitorada sempre que houver uma segunda máquina.
2. UptimeFlare atualizado quando liberar toda a RAM da VPS for prioridade e a dependência da Cloudflare for aceitável.
3. Vigil quando página pública, alertas e checks nativos importarem mais que histórico detalhado.
4. Monit local + monitor externo para serviços que precisam de reinício automático e detecção real de queda do host.
5. Statping-ng somente se o painel CRUD for indispensável e o ritmo de manutenção for aceitável.
6. Blackbox Exporter apenas em uma infraestrutura Prometheus já existente.

O resultado local de 12,21 MiB contra 130,3 MiB torna o Gatus a primeira experiência lógica: há uma diferença grande e medida, a arquitetura é simples, o projeto está ativo e a migração é reversível. Ainda assim, a melhor melhoria não é somente trocar o container. É mudar o monitor para fora do componente que ele precisa vigiar.

Conclusão

Sim, existem alternativas bem mais leves ao Uptime Kuma. A mais equilibrada é o Gatus, principalmente com SQLite e retenção limitada. Ele preserva checks variados, alertas e página de status num binário/container pequeno e, no ensaio desta pesquisa, consumiu cerca de um décimo da memória observada em um Kuma 2.5.0 vazio.

Para a instalação mais confiável, rode o Gatus em outra máquina e use Monit dentro da VPS. Se não houver outro servidor, UptimeFlare, Upptime ou UptimeRobot eliminam o consumo local e enxergam a queda de fora. TinyStatus resolve o caso mínimo; Vigil é um excelente segundo colocado; Statping-ng serve a quem não abre mão do painel; Peekaping e Updu merecem acompanhamento, mas ainda não são a primeira escolha empresarial.

Não há razão técnica para manter uma stack de observabilidade grande apenas para verificar alguns endpoints. Também não vale economizar 100 MiB e perder detecção, alertas ou independência do domínio de falha. Gatus externo + Monit local é o ponto de equilíbrio mais forte desta pesquisa.

Fontes consultadas

Referência e recomendados

• Uptime Kuma — repositório oficial
• Uptime Kuma — releases oficiais
• Gatus — repositório, documentação e licença
• Gatus 5.36.0 — release oficial
• Vigil — repositório e documentação
• Vigil 1.29.0 — release oficial
• Statping-ng — repositório e documentação
• Statping-ng 0.93.0 — release oficial
• TinyStatus — repositório e documentação
• Updu — repositório e documentação
• Updu — guia oficial de escala
• Peekaping — repositório, roadmap e licença
• ciao — repositório e documentação

Monitores mínimos, componentes e complementos

• Monit — documentação oficial
• Monit — histórico oficial de versões
• Updo — repositório e releases
• Monika — repositório e documentação
• MinMon — repositório e documentação
• Prometheus Blackbox Exporter — repositório oficial
• Prometheus Alertmanager — documentação oficial
• Prometheus — armazenamento local
• Healthchecks — repositório e documentação
• Healthchecks 4.3 — release oficial

Serverless e serviços externos

• UptimeFlare — repositório, documentação e licença
• UptimeFlare — aviso GHSA-36q9-v7p3-vj6v / CVE-2026-29779
• Upptime — repositório oficial
• Upptime — documentação oficial
• GitHub Actions — limitações de workflows agendados
• GitHub Actions — desativação e reativação de workflows
• UptimeRobot — regras oficiais do plano gratuito
• Better Stack — preços e limites oficiais

Alternativas mais amplas, páginas de status e projetos descartados

• Kener — repositório e documentação
• Kuvasz — repositório e documentação
• Maintenant — repositório, edições e documentação
• Checkmate — repositório e arquitetura
• Tianji — repositório e arquitetura
• OpenStatus — repositório e arquitetura
• OneUptime — repositório oficial
• OneUptime — dimensionamento oficial
• cState — repositório e documentação
• Cachet 3.x — repositório e licença
• Staytus — repositório e documentação
• Uptime de fzaninotto — repositório arquivado
• Cabot — repositório e aviso de manutenção

Nota sobre atualidade

Pesquisa concluída em 8 de agosto de 2026. Versões, atividade dos projetos, limites de planos gratuitos, licenças e termos de plataformas podem mudar. Confirme as páginas oficiais antes de uma implantação importante e repita as medições na VPS real com seus próprios monitores.