Problema

Los equipos de operaciones suelen trabajar con una colección heterogénea de herramientas: redis-cli para Redis, psql o mysql para bases de datos, ssh para acceso remoto, docker para contenedores, git para control de versiones y clientes HTTP para APIs. Cada una tiene su propio flujo de autenticación, su propio formato de salida y, sobre todo, su propia ventana de terminal. El “cambio de contexto” constante genera:

  • pérdida de tiempo al abrir y cerrar sesiones,
  • dificultad para correlacionar logs de diferentes fuentes,
  • riesgo de que credenciales se propaguen en archivos temporales,
  • complejidad al automatizar tareas con scripts que deben invocar múltiples binarios.

En entornos donde se combinan bases de datos, servicios de almacenamiento S3, despliegues vía SSH y pipelines de CI, el problema se vuelve crítico: cualquier interrupción en una herramienta rompe la cadena de trabajo y obliga a volver a autenticarse o a replicar configuraciones.

Causa

  1. Fragmentación de clientes – Cada servicio expone su propio protocolo (RESP, PostgreSQL wire, MySQL, SSH, Docker API, etc.). Los clientes oficiales están diseñados para un único objetivo y no comparten estado ni caché de credenciales.
  2. Gestión de secretos dispersa – Las credenciales se guardan en archivos .pgpass, variables de entorno, o en el propio ssh-agent. Cuando se usan varios clientes, la superficie de exposición crece.
  3. Falta de orquestación de UI – Las terminales tradicionales no permiten mantener varias sesiones activas simultáneamente; cambiar de una a otra implica cerrar la anterior o abrir una nueva pestaña.
  4. Automatización limitada – Herramientas de AI o pipelines de CI necesitan una API estructurada. La mayoría de los CLIs solo ofrecen salida de texto, lo que obliga a parsear strings frágiles.

Estos factores se combinan en la práctica y hacen que la operativa diaria sea más lenta y propensa a errores.

Solución

Una arquitectura basada en un único binario con UI TUI que:

  • Integre múltiples tipos de conexión (Redis, PostgreSQL, MySQL, MongoDB, S3, HTTP, SSH, Git, Docker) bajo un mismo proceso.
  • Mantenga un almacén de credenciales en memoria protegido con AES‑256‑GCM y derivado mediante scrypt; la clave maestra nunca se escribe en disco.
  • Exporte todas las operaciones a través de un servidor JSON‑RPC 2.0 (MCP) escuchando en un socket Unix o puerto local. Cada comando se identifica por el nombre de la conexión, no por parámetros de host/usuario.
  • Permita el uso de clientes externos (Claude, Cursor, scripts de CI) que invoquen la API sin conocer detalles de autenticación.
  • Ofrezca funcionalidades de salud y métricas (latencia, sparklines) para detectar problemas antes de que impacten el flujo de trabajo.
  • Se distribuya como un solo archivo binario (~45 MB) que se instala mediante un script curl y se actualiza automáticamente.

Arquitectura resumida

  1. Módulo de conexión – Cada tipo de servicio tiene un driver nativo (por ejemplo, un parser RESP para Redis, un cliente libpq para PostgreSQL). Los drivers comparten una capa de abstracción que recibe un “connection name” y devuelve un objeto de sesión.
  2. Vault en proceso – Al iniciar, el binario solicita la contraseña maestra, deriva la clave con scrypt y abre un contenedor cifrado en RAM. Todas las credenciales se cargan allí y se destruyen al cerrar la aplicación.
  3. TUI – Usa una biblioteca como tview o ncurses para renderizar pestañas, tablas y formularios. Cada pestaña mantiene su propia sesión montada, accesible con Ctrl+Tab.
  4. MCP Server – Un listener JSON‑RPC que expone métodos genéricos: exec_ssh, query_sql, list_containers, upload_s3, etc. Cada método recibe { "connection": "my‑redis", "command": "GET key" } y devuelve JSON estructurado.
  5. Integración con AI – Un agente AI puede llamar al método exec_ssh para ejecutar scripts de despliegue, o query_sql para obtener métricas, sin nunca ver la contraseña.

Pasos de implementación práctica

  1. Compilar o descargar el binario – El proyecto publica versiones precompiladas para Linux, macOS y Windows.
  2. Instalar con el script oficial:
curl -fsSL https://github.com/Kodjaoglanian/qore/releases/latest/download/install.sh | bash
  1. Crear conexiones desde la UI: asignar un nombre, seleccionar el tipo (Redis, PostgreSQL, etc.) y proporcionar la cadena de conexión o credenciales. El vault cifra la información automáticamente.
  2. Activar el servidor MCP – En la configuración, habilitar el listener en 127.0.0.1:5000 o en un socket Unix (/tmp/qore-mcp.sock).
  3. Consumir la API desde cualquier cliente JSON‑RPC. Un ejemplo sencillo para ejecutar un comando Docker:
curl -X POST http://127.0.0.1:5000 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"docker_exec","params":{"connection":"local-docker","command":"ps -a"},"id":1}'
  1. Integrar con AI – Configurar el agente (Claude, Cursor, etc.) para que apunte al endpoint MCP y utilice los nombres de conexión en sus prompts. El agente nunca maneja la contraseña, solo envía la solicitud JSON.

Cuándo aplicar esta solución

Escenarios típicos donde la unificación aporta valor:

  • Entornos de homelab o pequeñas empresas que manejan varios servicios sin un orquestador completo (Kubernetes, Terraform).
  • Equipos de DevOps que necesitan cambiar rápidamente entre bases de datos y contenedores durante incidentes.
  • Proyectos de IA operativa donde se desea que un modelo genere comandos de infraestructura sin exponer secretos.
  • Flujos de CI/CD que requieren ejecutar comandos SSH, consultas SQL y despliegues Docker en una única fase de script.

Señales de que la solución es adecuada:

  • Más de tres herramientas de línea de comandos diferentes en uso diario.
  • Necesidad de auditoría centralizada de credenciales.
  • Peticiones de automatización que fallan por parsing de salida de texto.

Casos donde no aplica:

  • Infraestructuras que ya usan un orquestador completo (Kubernetes, OpenShift) con APIs nativas.
  • Entornos que requieren alta disponibilidad del gestor mismo; un proceso único puede ser un punto único de falla.
  • Políticas de seguridad que prohíben la ejecución de binarios no firmados o que exigen separación física de credenciales.

Código

# Ejemplo de definición de una conexión PostgreSQL en JSON (usado por el MCP)
cat > connection.json <<'EOF'
{
  "name": "prod-pg",
  "type": "postgresql",
  "host": "db.example.com",
  "port": 5432,
  "user": "admin",
  "password": "********",   // se almacena cifrado en el vault
  "database": "app"
}
EOF

# Registrar la conexión vía RPC (asumiendo que el MCP está activo)
curl -X POST http://127.0.0.1:5000 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"register_connection","params":'"$(cat connection.json)"',"id":2}'

Verificación

  1. Arrancar la UI (qore) y confirmar que las pestañas aparecen con los nombres de conexión configurados.
  2. Ejecutar una consulta desde la UI (p.ej., SELECT 1;) y observar la respuesta en línea.
  3. Probar el endpoint MCP con curl como en el bloque anterior y validar que el JSON de respuesta contiene result y id.
  4. Revisar el vault: al cerrar la UI, intentar leer el archivo de credenciales en disco; debería estar vacío o contener solo datos cifrados.
  5. Simular un ataque: detener el proceso, borrar la RAM y volver a iniciar; la UI pedirá la contraseña maestra, lo que confirma que las credenciales no persisten.

Notas adicionales

  • Persistencia de la vault – Si se necesita que las credenciales sobrevivan a reinicios, exportar el vault cifrado a un archivo y cargarlo al iniciar con la misma contraseña maestra.
  • Seguridad del socket – Cuando se usa un socket Unix, restringir los permisos (chmod 600) para que solo el usuario de operación pueda acceder.
  • Escalado – Para entornos con alta concurrencia, ejecutar varias instancias del binario en diferentes puertos y balancear con un proxy ligero (nginx) que reenvíe peticiones JSON‑RPC.
  • Mantenimiento – El comando qore update descarga la última versión y reemplaza el binario sin perder configuraciones, pero siempre probar en un entorno de staging antes de actualizar producción.

Con una única interfaz TUI y un servidor JSON‑RPC, se elimina la fricción de cambiar entre clientes, se centraliza la gestión de credenciales y se abre la puerta a automatizaciones impulsadas por IA sin comprometer la seguridad. La clave está en mantener la arquitectura modular, cifrar todo en memoria y exponer solo una capa JSON bien definida.