Presento Fleetd: gestión de servidores Linux y routers en un solo panel

Administrar unos pocos servidores y routers parece sencillo: conectarse por SSH, consultar registros cuando falla un servicio y ejecutar algunos comandos para actualizar el software.

La incomodidad está en que esas tareas ocurren en lugares distintos. El servidor tiene una entrada y el router otra. Cuando aparece una alerta, todavía hay que encontrar la máquina correcta, entender su entorno y empezar a investigar.

Quería reunir esas acciones cotidianas: abrir una página, ver qué equipos están conectados y dónde hay alertas, entrar en uno y, si hace falta, ejecutar un comando o abrir una terminal.

Así nació Fleetd, una herramienta autoalojada para administrar servidores Linux y routers. El código está publicado bajo licencia MIT, la primera versión pública es v0.3.0 y hay documentación en inglés y chino.

Esta primera entrega explica el problema, las funciones actuales y las decisiones principales. Más adelante entraré en la implementación.

Pasar de detectar un problema a tratarlo

La monitorización puede avisar de que un disco está lleno, pero después hay que identificar qué directorio crece. Un servicio fallido requiere registros, revisar su configuración y decidir si reiniciarlo.

Para quien mantiene pocas máquinas, estas acciones suelen formar una misma tarea. Quería conservar esa continuidad y reducir las veces que hay que buscar el mismo equipo en otra herramienta.

Área	Funciones actuales
Monitorización	CPU, memoria, carga, discos y tráfico, con siete días de historial
Estado de ejecución	Unidades systemd fallidas, contenedores Docker y pares WireGuard
Alertas	Equipos desconectados, consumo elevado sostenido, poco espacio y anomalías de servicios; correo opcional
Comandos remotos	Órdenes firmadas para una o varias máquinas, sujetas a permisos locales
Terminal web	Sesión interactiva en equipos con acceso completo
Agentes	Aprobación de equipos nuevos y distribución de versiones firmadas

Vista general de Fleetd con recursos y estado de conexión

Recorte de la interfaz incluida en la documentación. Los valores muestran el diseño, no resultados de rendimiento.

Los datos necesitan contexto. El estado de systemd corresponde a sistemas con systemd; OpenWrt no tiene por qué ofrecer la misma lista. La fecha de un handshake WireGuard es una pista, no una prueba de avería independiente del tráfico y la configuración.

Mi prioridad es ofrecer un punto desde el que investigar. Las reglas complejas, el análisis a largo plazo y la orquestación de configuraciones pueden seguir en herramientas especializadas.

Un servidor y un agente por máquina

El servidor aloja la interfaz, los registros de máquinas, las métricas y el historial de operaciones, con PostgreSQL como almacenamiento. Cada equipo Linux ejecuta un agente que recopila estado, recibe solicitudes y decide si ejecutarlas.

La interfaz Vue 3 se integra en el binario del servidor Go. El agente también está escrito en Go, con versiones Linux amd64 y arm64. Hay que comprobar la arquitectura: que un router utilice OpenWrt no garantiza que pueda ejecutar los binarios publicados.

Son límites fáciles de seguir: servidor, base de datos y agentes con configuraciones propias. También orientan el diagnóstico: ¿se conectó el agente?, ¿envió datos?, ¿llegó la solicitud?, ¿por qué se aceptó o rechazó?

Para los routers, importa quién inicia la conexión

Un servidor en la nube puede tener dirección pública y un router doméstico estar detrás de NAT. Abrir otro servicio de administración entrante añade trabajo de configuración y mantenimiento.

En Fleetd, el agente inicia la conexión al servidor. Si puede alcanzar su dirección, no necesita un puerto entrante dedicado a la administración del agente.

Esto facilita reunir equipos Linux, OpenWrt e iStoreOS de redes diferentes. El servidor sí necesita una dirección accesible, y el uso habitual requiere HTTPS y reenvío WebSocket según la documentación.

Una máquina nueva queda pendiente de aprobación. El administrador compara la huella mostrada por el instalador y por el panel antes de aprobarla o rechazarla. ¿Es realmente el equipo que pretendía añadir? Un nombre reconocible no sustituye esa comprobación. La próxima entrega detallará el alta, las huellas y la reconexión.

Ver una máquina no debe conceder control total

Algunas máquinas solo necesitan monitorización; otras, unas pocas tareas fijas. Solo ciertas máquinas requieren órdenes arbitrarias y terminal completa.

Fleetd deja esta decisión en la configuración local del agente:

Permiso	Operaciones permitidas
monitor	Solo monitorización, sin comandos remotos
allowlist	Acciones predefinidas localmente
full	Comandos arbitrarios y terminal web

Los comandos se firman en el navegador del administrador. El agente verifica la firma con una clave pública de confianza y comprueba destino, vigencia y permisos locales. El servidor reenvía; una petición ordinaria sin firma no basta para ejecutar algo.

Esto reduce la confianza ciega en el servidor, pero tiene un supuesto importante: el navegador y el código frontend que ejecuta deben seguir siendo fiables.

El servidor también entrega la interfaz. Si se compromete, podría sustituir la página que se carga después. Una clave no exportable no impide que código malicioso intente invocar la firma. Por tanto, firmar comandos no permite prometer seguridad absoluta tras comprometer el servidor.

Dedicaré otra entrega a esa cadena de confianza. Para empezar, mantener monitor donde solo se necesiten métricas, preferir allowlist para acciones fijas y habilitar full únicamente cuando haga falta una terminal completa.

Las actualizaciones necesitan su propia confianza

Copiar manualmente el agente a cada máquina se vuelve tedioso. Descargar y ejecutar cualquier archivo deja sin resolver su autenticidad.

Fleetd usa paquetes de versión firmados. El publicador los firma en su propio entorno y los agentes los verifican con la clave pública configurada. La firma de comandos y la de versiones tienen finalidades distintas.

Los binarios normales de GitHub Releases sirven para instalación manual en la arquitectura correspondiente. Un paquete .release firmado solo sirve para agentes que confían en su clave de publicación.

Quien se autoaloje debe establecer sus propias claves y proceso de actualización siguiendo la documentación. Subir el paquete del autor no lo hace válido en cualquier instalación. La validación de versiones, los errores y la recuperación tendrán su artículo específico.

Probar el servidor con Docker Compose

Con Docker y el complemento Compose instalados:

git clone https://github.com/weiyi0/fleetd
cd fleetd
git checkout v0.3.0
docker compose up -d
docker compose run --rm fleetd admin-add admin

Configura la contraseña cuando se solicite y abre http://localhost:8480. La interfaz está disponible en inglés y chino.

El checkout fija v0.3.0 para reproducir el alcance de esta entrada. Compose compila el servidor desde el código e inicia PostgreSQL. La primera ejecución descarga dependencias y compila; el tiempo depende del ordenador y la red.

Hasta aquí solo se ha iniciado el panel; no hay máquinas conectadas. La imagen Docker tampoco genera paquetes de agente firmados.

La guía rápida explica cómo compilar y ejecutar un agente manualmente. Para uso continuado, configura tu clave de publicación, sube paquetes firmados y utiliza el proceso de instalación del panel.

El Compose de ejemplo es para evaluación: contiene credenciales de ejemplo y el puerto 8480 no se limita a loopback. Restringe el acceso durante la prueba local. Antes de usarlo por red, sigue la guía de despliegue, cambia las credenciales, configura HTTPS y respalda base de datos y claves.

Empieza con una máquina de prueba fácil de recuperar. Comprueba la huella, observa su estado y prueba las operaciones autorizadas. Añade las demás después de completar ese recorrido.

Por qué la primera versión pública es v0.3.0

Los agentes del despliegue previo ya estaban en 0.2.0. La actualización exige una versión de destino superior, así que la publicación mantuvo esa secuencia.

El número describe una evolución; la madurez se gana mediante uso y verificación. Fleetd encaja hoy con quienes mantienen pocos servidores Linux y routers, quieren controlar sus datos y aceptan entender el despliegue y los permisos.

El repositorio, los binarios y la documentación permiten examinarlo antes de adoptarlo. Una tabla de funciones no basta para presentarlo como sustituto de todas las herramientas de operaciones. Su objetivo inicial es unir estados, alertas y mantenimiento necesario, conservando permisos claros en cada equipo.

Próximas entregas

Hablaré de conexiones salientes y aprobación, firmas en el navegador, permisos locales, OpenWrt, alertas y actualizaciones. También revisaré el desarrollo del proyecto con ayuda de IA.

Quiero documentar decisiones concretas: qué resolvieron y qué límites introdujeron. Los problemas reales y sus verificaciones se incorporarán conforme avance el proyecto.

Puedes empezar por el código y la documentación. Las dudas generales pueden ir a Issues; para vulnerabilidades utiliza el canal privado de GitHub. Espero que la herramienta reduzca cambios de contexto y que esta serie aporte experiencias reutilizables.