LogDeck, plano de control self-hosted para Docker y Podman en un solo binario Go
El proyecto guarda los logs de cada contenedor en SQLite local para que sobrevivan a un compose up --build, y añade gestión multi-host por SSH y un servidor MCP.
LogDeck es un plano de control self-hosted para Docker y Podman que cabe en un único binario escrito en Go, sin servicios externos ni base de datos que administrar aparte. Cubre el ciclo de vida de contenedores y de Compose, guarda los logs de forma persistente, lanza alertas y gestiona varios hosts por SSH. El autor lo ha presentado en r/selfhosted y el código está en el repositorio.
El almacén de logs es la razón de existir
Lo que diferencia a esta herramienta de un panel de Docker al uso es dónde van los logs. Cada contenedor se sigue con un tail hacia un SQLite local, así que el historial no se pierde cuando se recrea un contenedor. Eso incluye el caso molesto: un docker compose up --build levanta un contenedor nuevo con otro ID, y con los drivers por defecto los mensajes del anterior se van con él. Aquí siguen ahí, y los contenedores ya eliminados se pueden seguir leyendo.
El resto de la pieza es lo esperable en este terreno: arrancar, parar y reconstruir contenedores, operar sobre stacks de Compose y lanzar avisos cuando algo se comporta mal. La gestión multi-host va por SSH, de modo que no hace falta desplegar un agente en cada máquina.
MCP y consumo
El binario incluye además un servidor MCP, pensado para que un agente pueda leer los logs y actuar sobre los contenedores. Es la parte más reciente de la fiebre por conectar modelos con infraestructura real, y aquí es opcional: si no se quiere, no se activa.
Las cifras de memoria son del propio autor, no de una medición independiente. Habla de un heap en reposo de unos 8 MB y de unos 20 MB residentes con cinco contenedores y 400.000 líneas almacenadas. Si se sostiene con ese volumen de logs, es un consumo contenido para lo que hace.
En licencia y modelo no hay matices que buscar: open source completo, sin planes de pago ni componente en la nube. Tampoco hay versión etiquetada ni matriz de compatibilidad publicada en el anuncio, y el proyecto lo mantiene una sola persona, algo a tener en cuenta antes de meterlo en producción.
A quien ya tenga un Portainer, un Dozzle o un stack de Loki montado, esto no le resuelve nada que no tenga. El hueco está en instalaciones pequeñas o en el equipo de casa, donde montar un stack de observabilidad completo para ver qué pasó con un contenedor que ya no existe sale caro. Ahí un binario que arrastra su propio SQLite es una decisión de arquitectura razonable, siempre que los logs persistentes no crezcan sin control en disco.