SolidPing

npx add-mcp 'https://solidping.io/api/v1/mcp'

---

Capturas de tela

Lista de verificações	Formulário de nova verificação	Detalhe da verificação

Experimente

Hospedado	www.solidping.io — cadastre-se, sem necessidade de cartão
Página de status ao vivo	status.solidping.io — uma instância real do SolidPing monitorando a de produção, de outro provedor em outro país
Documentação	docs.solidping.io
Auto-hospedagem	docker run -p 4000:4000 --hostname solidping ghcr.io/fclairamb/solidping (também no Docker Hub como fclairamb/solidping) — SQLite por padrão, sem necessidade de outros serviços. O primeiro login é admin@solidping.io / solidpass, e você deve alterá-lo (veja Credenciais padrão). Prefere um binário puro? Toda versão também publica um para Linux, macOS e Windows — veja os guias de instalação. Também: brew install fclairamb/tap/solidping (tap), scoop bucket add fclairamb https://github.com/fclairamb/scoop-bucket e depois scoop install solidping, e um Helm chart.

Visão geral

O SolidPing é um sistema de monitoramento multi-tenant que permite que organizações monitorem sua infraestrutura por meio de workers distribuídos que executam verificações de saúde. Foi projetado para baixo consumo de recursos e fácil auto-hospedagem.

Principais recursos

• 43 tipos de verificação: HTTP, TCP, UDP, ICMP, DNS, DNSBL, NTP, SSL/Domínio, SSH, RDP, VNC, FTP/SFTP, SMTP/POP3/IMAP, Email (caixa de entrada passiva JMAP), WebSocket, SIP, gRPC, Prometheus, 7 bancos de dados (Postgres, MySQL, MSSQL, Oracle, ClickHouse, MongoDB, Redis), 3 filas de mensagens (Kafka, RabbitMQ, MQTT), Docker, Kubernetes, SNMP, linha Freebox, servidor de jogos (Source/A2S, Minecraft), navegador headless, JS personalizado, rastreamento de site, endpoint de saúde, heartbeat
• Workers distribuídos: Execução de verificações multi-região com agendamento baseado em lease, períodos de verificação por região com controle de propagação e cotas de taxa de verificação por organização
• Locais privados: Agentes externos executam verificações de dentro da sua própria rede por meio de um WebSocket de saída, com cotas de agentes por organização
• Multi-tenant: Isolamento de dados por organização, RBAC, 2FA (TOTP), rótulos com autocompletar
• Baixo consumo: Binário único; SQLite, Postgres embutido ou Postgres externo
• Verificações rápidas: Frequências abaixo de um minuto suportadas
• Notificações (10 nativas): Slack (OAuth + threads + instalação no Marketplace), Discord (OAuth + webhook), Email, Webhooks, Google Chat, Mattermost, Ntfy, PagerDuty, Pushover, Web Push (VAPID)
• Incidentes: Resolução adaptativa com tempo de espera, correlação de incidentes em grupo (um alerta por interrupção, não por verificação), reconhecimento, adiamento, resolução manual e comentários por incidente
• Grupos de verificação: Organize verificações em grupos com paginação agrupada e correlação de incidentes em nível de grupo
• Plantão e escalonamento: Escalas de rodízio com substituições, políticas de escalonamento em várias etapas (destinos: usuário / escala / conexão / todos os administradores, repetições)
• Criptografia de credenciais em repouso: Criptografia de envelope com chave mestra fora de banda; segredos nunca são exibidos de volta no painel
• Túneis SSH: Alcance destinos inacessíveis por meio de hosts de salto SSH
• Páginas de status: Seções, recursos, métricas públicas de disponibilidade, formatação de data sensível ao local
• Janelas de manutenção: Supressão recorrente de alertas
• Scripts JavaScript: Lógica de monitoramento personalizada em sandbox
• Monitoramento de navegador: Chrome headless via Rod
• Servidor MCP: Acesso a ferramentas por IA/LLM via Model Context Protocol (listado no Smithery)
• SSO / OAuth: Google, GitHub, GitLab, Microsoft, Slack, Discord, além de OIDC genérico, SAML e LDAP / Active Directory (alternância de ativação por provedor, com revogação de token por autoatendimento)
• Observabilidade: Prometheus /metrics, integração com Sentry, OpenTelemetry
• Cliente CLI: Gerencie verificações e resultados pelo terminal
• i18n: Painel multilíngue (inglês, francês, alemão, espanhol)

Início rápido

Pré-requisitos

• Go 1.24+
• PostgreSQL 15+
• Docker (para desenvolvimento)
• Bun (para desenvolvimento do frontend)

Configuração de desenvolvimento

# Start PostgreSQL
docker-compose up -d

# Build and run
make build && ./solidping serve

# Or use hot reload for development
make dev-test   # Backend + frontend with hot reload

Credenciais padrão

• Email: admin@solidping.io
• Senha: solidpass
• Organização: default

Ambas as partes desse par são publicadas aqui, então o primeiro login em um banco de dados novo deve definir uma nova senha antes que a conta possa fazer qualquer outra coisa. O painel leva você direto ao formulário; pela API, o login é bem-sucedido e todos os endpoints, exceto POST /api/v1/auth/change-password, GET /api/v1/auth/me e POST /api/v1/auth/logout, respondem 403 com o código PASSWORD_CHANGE_REQUIRED até que você a altere.

Exemplo de API

# Get a JWT token
TOKEN=$(curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"org":"default","email":"admin@solidping.io","password":"solidpass"}' \
  'http://localhost:4000/api/v1/auth/login' | jq -r '.accessToken')

# List checks
curl -s -H "Authorization: Bearer $TOKEN" \
  'http://localhost:4000/api/v1/orgs/default/checks'

Tipos de verificação suportados

Rede

Protocolo	Descrição
HTTP/HTTPS	Códigos de status, correspondência de corpo, asserções JSON, autenticação básica
TCP	Conectividade de porta
UDP	Alcance de porta
ICMP	Ping
DNS	Resolução de registros
DNSBL	Participação em lista de bloqueio DNS (RBL)
NTP	Alcance do servidor de horário e desvio de relógio
WebSocket	Verificação de conexão
SIP	Servidor VoIP SIP (ping OPTIONS)

Segurança e certificados

Protocolo	Descrição
SSL/TLS	Validade e expiração de certificado
Domínio	Expiração de nome de domínio (WHOIS)

Email

Protocolo	Descrição
SMTP	Conectividade do servidor, STARTTLS, AUTH
POP3	Disponibilidade do servidor
IMAP	Disponibilidade do servidor
Email (JMAP)	Monitoramento passivo de caixa de entrada — receba uma mensagem conhecida via JMAP e verifique a entrega

Bancos de dados

Protocolo	Descrição
PostgreSQL	Conexão + execução de consulta
MySQL/MariaDB	Conexão + execução de consulta
MSSQL	Conexão + execução de consulta
Oracle	Conexão + execução de consulta
ClickHouse	Conexão + execução de consulta
MongoDB	Comando ping
Redis	Comando PING

Acesso remoto

Protocolo	Descrição
SSH	Disponibilidade do servidor
RDP	Handshake de negociação RDP pré-autenticação (sem credenciais)
FTP	Disponibilidade do servidor
SFTP	Disponibilidade do servidor

Filas de mensagens

Protocolo	Descrição
Kafka	Conectividade do broker
RabbitMQ	Conectividade do broker
MQTT	Conectividade do broker

Infraestrutura

Tipo	Descrição
Docker	Saúde do contêiner
Kubernetes	Saúde do cluster / servidor de API
SNMP	Monitoramento de dispositivos
gRPC	Saúde do serviço
A2S	Consulta a servidor de jogos Source / Steam (Valve A2S)
Minecraft	Consulta a servidor Minecraft
Prometheus	Coleta de um endpoint Prometheus e verificação de uma métrica

Especializados

Tipo	Descrição
Heartbeat	Monitoramento passivo via pings recebidos
JavaScript	Lógica de monitoramento personalizada em sandbox
Navegador	Chrome headless (Rod) — JS, CSS, renderização completa
Linha Freebox	Qualidade da linha xDSL/fibra Freebox (via Freebox conectada)

Configuração

Tudo é configurado com variáveis de ambiente com prefixo SP_. Precedência: variáveis de ambiente > config.local.yml > config.yml > padrões.

Você só precisa das configurações do banco de dados para começar — os padrões cobrem o restante.

SQLite (o padrão — bom para uma única instância)

Nada para configurar. A imagem já armazena o banco de dados SQLite e todos os blobs enviados (logotipos de organizações, ativos de páginas de status, capturas de tela) em /data, então um único volume nomeado montado é suficiente:

docker run -p 4000:4000 \
  --hostname solidping \
  -v solidping-data:/data \
  ghcr.io/fclairamb/solidping

--hostname solidping não é opcional: o nome do worker é derivado do hostname e deve corresponder a ^[a-z][a-z0-9-]{2,20}$. O hostname padrão do Docker é o ID aleatório do contêiner, que na maioria das vezes começa com um dígito, e o servidor então se recusa a iniciar. Passe --hostname, ou defina SP_NODE_NAME.

Se você usar um bind mount em vez de um volume nomeado (-v ./solidping-data:/data), o diretório do host mantém sua própria propriedade, que geralmente não é gravável pelo usuário não-root da imagem (uid/gid 65532). Ou chown 65532:65532 o diretório do host primeiro, ou execute com -u "$(id -u):$(id -g)". Um volume nomeado, como usado acima, não tem esse problema — o Docker o inicializa a partir da imagem com a propriedade correta.

PostgreSQL (recomendado para produção)

As migrações de esquema são executadas no primeiro boot, então aponte para um banco de dados vazio e deixe-o criar suas próprias tabelas:

docker run -p 4000:4000 \
  --hostname solidping \
  -e SP_DB_TYPE=postgres \
  -e SP_DB_URL='postgresql://solidping:password@postgres:5432/solidping?sslmode=disable' \
  ghcr.io/fclairamb/solidping

sslmode=disable é adequado para um banco de dados na mesma rede privada, e é o que um contêiner postgres padrão aceita — ele não serve TLS, então sslmode=require falha contra um com SSL is not enabled on the server. Para um banco de dados gerenciado ou remoto, use sslmode=require (ou verify-full).

As variáveis que você realmente precisa

Variável	Padrão	Descrição
SP_DB_TYPE	sqlite	sqlite ou postgres
SP_DB_URL	—	String de conexão PostgreSQL (obrigatória quando SP_DB_TYPE=postgres)
SP_DB_DIR	/data na imagem, . para o binário puro	Onde o arquivo SQLite fica — defina-o para um volume
SP_SERVER_LISTEN	:4000	Endereço de escuta
SP_BASE_URL	http://localhost:4000	URL pública, usada em links e notificações
SP_NODE_NAME	o hostname	Nome do worker, ^[a-z][a-z0-9-]{2,20}$. Defina-o, ou passe --hostname — o servidor não iniciará se o hostname não corresponder
SP_LOG_LEVEL	info	debug, info, warn, error

Essa é toda a superfície de início. Todo o resto — autenticação e SSO, email e os outros canais de notificação, domínios personalizados e TLS, workers multi-região, retenção de dados, armazenamento — é opcional e documentado em docs.solidping.io:

Visão geral da configuração	todas as variáveis, agrupadas por área
Banco de dados	strings de conexão, modos SSL, pooling, backups
Autenticação	provedores OAuth, OIDC, SAML, LDAP, 2FA
Notificações	Slack, Discord, email, webhooks e o restante

Arquitetura

Componentes principais

• Servidor de API: API REST para gerenciar verificações, incidentes e resultados
• Painel (web/dash0): UI de administração (React + TanStack Router + shadcn/ui)
• Página de status (web/status0): Painel de status público
• Workers: Agentes distribuídos que executam verificações de monitoramento
• Notificações: Slack, Discord, Email, Webhooks, Google Chat, Mattermost, Ntfy, PagerDuty, Pushover, Web Push
• Banco de dados: PostgreSQL (resultados particionados) ou SQLite

Pilha de Tecnologia

• Backend: Go 1.24+, go-chi/chi v5, Bun ORM, koanf
• Frontend: React 19, TypeScript, Vite, TanStack Router/Query, Tailwind CSS, shadcn/ui
• Banco de dados: PostgreSQL (produção), SQLite (desenvolvimento/nó único)

Estrutura do Projeto

solidping/
├── server/
│   ├── main.go                  # CLI entry point (serve, migrate, client)
│   └── internal/
│       ├── app/                 # Server setup, services, embedded assets
│       ├── handlers/            # HTTP handlers + business logic
│       ├── checkers/            # Protocol checker implementations
│       ├── notifications/       # Notification channels
│       ├── db/                  # Bun models + Postgres/SQLite migrations
│       └── middleware/          # Auth, CORS, org context
├── web/
│   ├── dash0/                   # Admin dashboard (React)
│   └── status0/                 # Public status page
├── docker-compose.yml           # Development PostgreSQL
├── Dockerfile                   # Production container
└── Makefile                     # Build targets

Desenvolvimento

Comandos

make build            # Build complete application
make dev-test         # Hot-reload backend + frontend
make dev-backend      # Backend only with hot reload (air)
make dev-dash0        # Dashboard dev server
make test             # Run backend tests
make lint             # Lint all code
make fmt              # Format all code
make docker-build     # Build Docker image

Cliente CLI

# Build the CLI
make build-cli

# Usage
./bin/sp auth login
./bin/sp checks list
./bin/sp results list

Objetivos

Principais

• Muitos protocolos e tipos de teste
• Baixo consumo de memória
• Execução rápida (verificações em menos de um minuto)
• Fácil auto-hospedagem (binário único + PostgreSQL)
• Multiplataforma (Linux, macOS, Windows)
• Páginas públicas de status

Não Objetivos

• Testes transacionais de múltiplas etapas / fluxos de usuário com script (use Playwright diretamente para isso)
• Monitoramento de Performance de Aplicações / RUM (use Datadog, New Relic ou Site24x7)

Inspiração

• uptime-kuma - Ótima ferramenta de monitoramento auto-hospedada

Contribuindo

Relatórios de bugs e pull requests são bem-vindos — veja CONTRIBUTING.md para configuração local e convenções de PR. Encontrou um problema de segurança? Veja SECURITY.md em vez de abrir uma issue pública.

Licença

AGPL-3.0 - Veja LICENSE.