SolidPing

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

---

Capturas de pantalla

Lista de verificaciones	Formulario de nueva verificación	Detalle de verificación

Pruébalo

Alojado	www.solidping.io — regístrate, sin necesidad de tarjeta
Página de estado en vivo	status.solidping.io — una instancia real de SolidPing que vigila la de producción, desde otro proveedor en otro país
Documentación	docs.solidping.io
Auto-alojamiento	docker run -p 4000:4000 --hostname solidping ghcr.io/fclairamb/solidping (también en Docker Hub como fclairamb/solidping) — SQLite por defecto, sin necesidad de otro servicio. El primer inicio de sesión es admin@solidping.io / solidpass, y debes cambiarlo (ver Credenciales por defecto). ¿Prefieres un binario simple? Cada versión también publica uno para Linux, macOS y Windows — consulta las guías de instalación. También: brew install fclairamb/tap/solidping (tap), scoop bucket add fclairamb https://github.com/fclairamb/scoop-bucket y luego scoop install solidping, y un gráfico de Helm.

Resumen

SolidPing es un sistema de monitoreo multi-tenant que permite a las organizaciones monitorear su infraestructura mediante trabajadores distribuidos que ejecutan verificaciones de salud. Está diseñado para un bajo consumo de recursos y un fácil auto-alojamiento.

Características principales

• 43 tipos de verificación: HTTP, TCP, UDP, ICMP, DNS, DNSBL, NTP, SSL/Dominio, SSH, RDP, VNC, FTP/SFTP, SMTP/POP3/IMAP, Email (buzón pasivo JMAP), WebSocket, SIP, gRPC, Prometheus, 7 bases de datos (Postgres, MySQL, MSSQL, Oracle, ClickHouse, MongoDB, Redis), 3 colas de mensajes (Kafka, RabbitMQ, MQTT), Docker, Kubernetes, SNMP, línea Freebox, servidor de juegos (Source/A2S, Minecraft), navegador sin cabeza, JS personalizado, rastreo de sitios web, endpoint de salud, heartbeat
• Trabajadores distribuidos: Ejecución de verificaciones multi-región con programación basada en arrendamiento, períodos de verificación por región con control de dispersión y cuotas de tasa de verificación por organización
• Ubicaciones privadas: Agentes delegados ejecutan verificaciones desde dentro de tu propia red a través de un WebSocket saliente, con cuotas de agentes por organización
• Multi-tenant: Aislamiento de datos a nivel de organización, RBAC, 2FA (TOTP), etiquetas con autocompletado
• Baja huella: Un solo binario; SQLite, Postgres integrado o Postgres externo
• Verificaciones rápidas: Frecuencias de menos de un minuto compatibles
• Notificaciones (10 nativas): Slack (OAuth + hilos + instalación en Marketplace), Discord (OAuth + webhook), Email, Webhooks, Google Chat, Mattermost, Ntfy, PagerDuty, Pushover, Web Push (VAPID)
• Incidentes: Resolución adaptativa con período de enfriamiento, correlación de incidentes grupales (una alerta por interrupción, no por verificación), reconocimiento, posposición, resolución manual y comentarios por incidente
• Grupos de verificación: Organiza verificaciones en grupos con paginación agrupada y correlación de incidentes a nivel de grupo
• Guardia y escalamiento: Horarios de rotación con anulaciones, políticas de escalamiento de múltiples pasos (objetivos: usuario / horario / conexión / todos los administradores, repeticiones)
• Cifrado de credenciales en reposo: Cifrado de sobre con clave maestra fuera de banda; los secretos nunca se devuelven al panel
• Túneles SSH: Alcanza objetivos que de otro modo serían inalcanzables a través de hosts de salto SSH
• Páginas de estado: Secciones, recursos, métricas de disponibilidad públicas, formato de fechas según la configuración regional
• Ventanas de mantenimiento: Supresión recurrente de alertas
• Scripting en JavaScript: Lógica de monitoreo personalizada en entorno aislado
• Monitoreo de navegador: Chrome sin cabeza vía Rod
• Servidor MCP: Acceso a herramientas de IA/LLM mediante el Protocolo de Contexto de Modelo (listado en Smithery)
• SSO / OAuth: Google, GitHub, GitLab, Microsoft, Slack, Discord, además de OIDC genérico, SAML y LDAP / Active Directory (interruptor de habilitación por proveedor, con revocación de tokens de autoservicio)
• Observabilidad: Prometheus /metrics, integración con Sentry, OpenTelemetry
• Cliente CLI: Gestiona verificaciones y resultados desde la terminal
• i18n: Panel multilingüe (inglés, francés, alemán, español)

Inicio rápido

Requisitos previos

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

Configuración de desarrollo

# 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

Credenciales por defecto

• Email: admin@solidping.io
• Contraseña: solidpass
• Organización: default

Ambas mitades de ese par se publican aquí, por lo que el primer inicio de sesión en una base de datos nueva debe establecer una nueva contraseña antes de que la cuenta pueda hacer cualquier otra cosa. El panel te lleva directamente al formulario; a través de la API el inicio de sesión tiene éxito y cada endpoint excepto POST /api/v1/auth/change-password, GET /api/v1/auth/me y POST /api/v1/auth/logout responde 403 con código PASSWORD_CHANGE_REQUIRED hasta que la rotes.

Ejemplo 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 verificación compatibles

Red

Protocolo	Descripción
HTTP/HTTPS	Códigos de estado, coincidencia de cuerpo, aserciones JSON, autenticación básica
TCP	Conectividad de puerto
UDP	Accesibilidad de puerto
ICMP	Ping
DNS	Resolución de registros
DNSBL	Pertenencia a listas de bloqueo DNS (RBL)
NTP	Accesibilidad del servidor de tiempo y desviación de reloj
WebSocket	Verificación de conexión
SIP	Servidor VoIP SIP (ping OPTIONS)

Seguridad y certificados

Protocolo	Descripción
SSL/TLS	Validez y expiración de certificados
Dominio	Expiración de nombre de dominio (WHOIS)

Email

Protocolo	Descripción
SMTP	Conectividad del servidor, STARTTLS, AUTH
POP3	Disponibilidad del servidor
IMAP	Disponibilidad del servidor
Email (JMAP)	Monitoreo pasivo de buzón — recibe un mensaje conocido vía JMAP y verifica la entrega

Bases de datos

Protocolo	Descripción
PostgreSQL	Conexión + ejecución de consultas
MySQL/MariaDB	Conexión + ejecución de consultas
MSSQL	Conexión + ejecución de consultas
Oracle	Conexión + ejecución de consultas
ClickHouse	Conexión + ejecución de consultas
MongoDB	Comando Ping
Redis	Comando PING

Acceso remoto

Protocolo	Descripción
SSH	Disponibilidad del servidor
RDP	Apretón de manos de negociación RDP previo a la autenticación (sin credenciales)
FTP	Disponibilidad del servidor
SFTP	Disponibilidad del servidor

Colas de mensajes

Protocolo	Descripción
Kafka	Conectividad del broker
RabbitMQ	Conectividad del broker
MQTT	Conectividad del broker

Infraestructura

Tipo	Descripción
Docker	Salud del contenedor
Kubernetes	Salud del clúster / servidor API
SNMP	Monitoreo de dispositivos
gRPC	Salud del servicio
A2S	Consulta de servidor de juegos Source / Steam (Valve A2S)
Minecraft	Consulta de servidor de Minecraft
Prometheus	Extrae un endpoint de Prometheus y verifica una métrica

Especializados

Tipo	Descripción
Heartbeat	Monitoreo pasivo mediante pings entrantes
JavaScript	Lógica de monitoreo personalizada en entorno aislado
Navegador	Chrome sin cabeza (Rod) — JS, CSS, renderizado completo
Línea Freebox	Calidad de línea xDSL/fibra Freebox (vía Freebox conectada)

Configuración

Todo se configura con variables de entorno con prefijo SP_. Precedencia: variables de entorno > config.local.yml > config.yml > valores por defecto.

Solo necesitas la configuración de la base de datos para comenzar — los valores por defecto cubren el resto.

SQLite (el valor por defecto — bueno para una sola instancia)

Nada que configurar. La imagen ya almacena la base de datos SQLite y cada blob subido (logotipos de organizaciones, recursos de páginas de estado, capturas de pantalla) en /data, por lo que un solo volumen con nombre montado es suficiente:

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

--hostname solidping no es opcional: el nombre del trabajador se deriva del nombre de host y debe coincidir con ^[a-z][a-z0-9-]{2,20}$. El nombre de host por defecto de Docker es el ID aleatorio del contenedor, que comienza con un dígito la mayoría de las veces, y el servidor entonces se niega a iniciar. Pasa --hostname, o establece SP_NODE_NAME en su lugar.

Si usas un montaje de enlace en lugar de un volumen con nombre (-v ./solidping-data:/data), el directorio del host conserva su propia propiedad, que generalmente no es escribible por el usuario no root de la imagen (uid/gid 65532). O bien chown 65532:65532 el directorio del host primero, o ejecuta con -u "$(id -u):$(id -g)". Un volumen con nombre, como se usa arriba, no tiene este problema — Docker lo siembra desde la imagen con la propiedad correcta.

PostgreSQL (recomendado para producción)

Las migraciones de esquema se ejecutan en el primer arranque, así que apúntalo a una base de datos vacía y deja que cree sus propias tablas:

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 es adecuado para una base de datos en la misma red privada, y es lo que acepta un contenedor estándar de postgres — no sirve TLS, por lo que sslmode=require falla contra uno con SSL is not enabled on the server. Para una base de datos gestionada o remota, usa sslmode=require (o verify-full) en su lugar.

Las variables que realmente necesitas

Variable	Valor por defecto	Descripción
SP_DB_TYPE	sqlite	sqlite o postgres
SP_DB_URL	—	Cadena de conexión de PostgreSQL (requerida cuando SP_DB_TYPE=postgres)
SP_DB_DIR	/data en la imagen, . para el binario simple	Dónde vive el archivo SQLite — configúralo en un volumen
SP_SERVER_LISTEN	:4000	Dirección de escucha
SP_BASE_URL	http://localhost:4000	URL pública, usada en enlaces y notificaciones
SP_NODE_NAME	el nombre de host	Nombre del trabajador, ^[a-z][a-z0-9-]{2,20}$. Configúralo, o pasa --hostname — el servidor no se iniciará si el nombre de host no coincide
SP_LOG_LEVEL	info	debug, info, warn, error

Esa es toda la superficie para comenzar. Todo lo demás — autenticación y SSO, email y los otros canales de notificación, dominios personalizados y TLS, trabajadores multi-región, retención de datos, almacenamiento — es opcional y está documentado en docs.solidping.io:

Resumen de configuración	cada variable, agrupada por área
Base de datos	cadenas de conexión, modos SSL, agrupación, copias de seguridad
Autenticación	proveedores OAuth, OIDC, SAML, LDAP, 2FA
Notificaciones	Slack, Discord, email, webhooks y el resto

Arquitectura

Componentes principales

• Servidor API: API REST para gestionar verificaciones, incidentes y resultados
• Panel (web/dash0): Interfaz de administración (React + TanStack Router + shadcn/ui)
• Página de estado (web/status0): Panel de estado público
• Trabajadores: Agentes distribuidos que ejecutan verificaciones de monitoreo
• Notificaciones: Slack, Discord, Email, Webhooks, Google Chat, Mattermost, Ntfy, PagerDuty, Pushover, Web Push
• Base de datos: PostgreSQL (resultados particionados) o SQLite

Stack Tecnológico

• Backend: Go 1.24+, go-chi/chi v5, Bun ORM, koanf
• Frontend: React 19, TypeScript, Vite, TanStack Router/Query, Tailwind CSS, shadcn/ui
• Base de datos: PostgreSQL (producción), SQLite (desarrollo/nodo único)

Estructura del Proyecto

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

Desarrollo

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

Principales

• Muchos protocolos y tipos de prueba
• Bajo consumo de memoria
• Ejecución rápida (comprobaciones en menos de un minuto)
• Autoalojamiento sencillo (binario único + PostgreSQL)
• Multiplataforma (Linux, macOS, Windows)
• Páginas de estado públicas

No Objetivos

• Pruebas transaccionales de múltiples pasos / flujos de usuario con scripts (usa Playwright directamente para eso)
• Monitoreo de rendimiento de aplicaciones / RUM (usa Datadog, New Relic o Site24x7)

Inspiración

• uptime-kuma - Gran herramienta de monitoreo autoalojada

Contribuciones

Los informes de errores y las solicitudes de extracción son bienvenidos — consulta CONTRIBUTING.md para la configuración local y las convenciones de PR. ¿Encontraste un problema de seguridad? Consulta SECURITY.md en lugar de abrir un problema público.

Licencia

AGPL-3.0 - Consulta LICENSE.