--- title: "22 herramientas open source y TUI que todo sysadmin Linux debería conocer en 2026" description: "Las interfaces de terminal viven una nueva etapa que tiene poco que ver con recuperar software del pasado. Las TUI (Text User Interfaces) actuales permiten monitorizar servidores Linux, analizar redes..." url: https://revistacloud.com/herramientas-open-source-y-tui-que-todo-sysadmin-linux/ date: 2026-09-14 modified: 2026-09-03 author: "Silvia A. Feliz" image: https://revistacloud.com/wp-content/uploads/2026/09/modern-open-source-tools.jpg categories: ["Guías y recursos"] tags: ["herramientas", "open source"] type: post lang: es --- # 22 herramientas open source y TUI que todo sysadmin Linux debería conocer en 2026 Las interfaces de terminal viven una nueva etapa que tiene poco que ver con recuperar software del pasado. Las **TUI (Text User Interfaces)** actuales permiten monitorizar servidores Linux, analizar redes, administrar Kubernetes, trabajar con contenedores, investigar logs, recorrer enormes archivos de correo o manejar repositorios sin depender de pesadas aplicaciones de escritorio. Para un administrador de sistemas tienen otra ventaja difícil de igualar: muchas funcionan perfectamente sobre SSH y mantienen el trabajo cerca de la máquina donde realmente está ocurriendo el problema. **Las claves de las TUI y herramientas open source en 20 segundos** - La selección comienza con **FlarePurge**, para gestionar la caché de Cloudflare, y **mboxShell**, para grandes archivos MBOX. - Las otras 20 herramientas aparecen por orden alfabético para facilitar su consulta. - btop, below, bottom, lnav y ncdu ayudan a diagnosticar Linux. - k9s, lazydocker y dive cubren Kubernetes y contenedores. - Redes, Git, bases de datos, APIs y edición completan una caja de herramientas especialmente útil mediante SSH. La frontera entre CLI y TUI no siempre es perfecta. Una interfaz de línea de comandos (CLI) suele recibir una instrucción, ejecutar una operación y devolver el control al shell. Una TUI permanece abierta, actualiza información y ofrece paneles, selección, navegación y acciones interactivas. Tampoco todas las herramientas incluidas aquí son TUI estrictas. FlarePurge es un buen ejemplo. Entra en la selección porque responde al mismo movimiento hacia **utilidades pequeñas, especializadas y abiertas**, frente a suites de administración cada vez más grandes. La lista está planteada, por tanto, como una caja de herramientas práctica para administradores Linux y desarrolladores. ## Dos proyectos que merece la pena conocer ### 1. FlarePurge: gestionar la caché de Cloudflare con una herramienta específica **FlarePurge** resuelve una operación muy concreta: purgar la caché de zonas de Cloudflare sin tener que entrar continuamente en su panel de administración. La aplicación se comunica directamente con la API de Cloudflare mediante tokens con permisos limitados y permite trabajar con varias cuentas, realizar purgas completas y eliminar selectivamente la caché correspondiente a determinadas URL o *hostnames*. Esto puede resultar especialmente cómodo para administradores web, desarrolladores, responsables de WordPress o sysadmins que gestionan numerosos dominios y necesitan invalidar contenido con frecuencia. También plantea una buena práctica de seguridad. Para vaciar una caché no es necesario utilizar una credencial con control completo sobre una cuenta. Un token limitado exclusivamente a las operaciones necesarias reduce las consecuencias de una eventual exposición. FlarePurge dispone de implementaciones nativas y su código se distribuye bajo licencia MIT. No es una TUI tradicional, pero comparte la filosofía de muchas herramientas de esta lista: **resolver bien una tarea concreta sin obligar al administrador a trabajar dentro de una gran plataforma**. [FlarePurge en GitHub](https://github.com/dcarrero/flarepurge) ### 2. mboxShell: recorrer archivos MBOX gigantes desde la terminal Los archivos de correo electrónico no suelen aparecer en recopilaciones para sysadmins, pero **mboxShell** cubre un problema bastante real: trabajar con grandes ficheros MBOX sin cargar todo el buzón en memoria. Es una aplicación open source desarrollada en Rust y orientada a abrir, buscar, recorrer y exportar archivos MBOX. Puede utilizarse con copias de Gmail generadas mediante Google Takeout, archivos de Thunderbird y buzones procedentes de sistemas Unix. Su TUI utiliza Ratatui e incorpora navegación de estilo vi, diferentes vistas, conversaciones agrupadas, etiquetas de Gmail y búsquedas avanzadas mediante campos como `from:`, `subject:`, `date:`, `body:` o `has:attachment`. También funciona como herramienta CLI. Esto permite indexar buzones, realizar búsquedas desde scripts, extraer adjuntos, exportar mensajes o combinar varios MBOX aplicando deduplicación. Uno de sus aspectos más interesantes está en cómo maneja archivos grandes. En lugar de cargar el buzón completo en RAM, utiliza lectura secuencial y construye un índice persistente. La documentación del proyecto recoge pruebas con archivos de Gmail Takeout superiores a 50 GB. [mboxShell en Gi](https://github.com/dcarrero/mboxshell?utm_source=chatgpt.com)[t](https://github.com/dcarrero/mboxshell)[Hub](https://github.com/dcarrero/mboxshell?utm_source=chatgpt.com) El proyecto sirve además como base abierta para **Mbox Viewer**, una aplicación nativa para macOS y Windows dirigida a quienes necesitan trabajar con este tipo de archivos mediante una interfaz gráfica. Procesa el correo localmente y permite consultar MBOX y EML, etiquetas de Gmail, conversaciones, búsquedas y exportaciones. [Mbox Viewer Pro](https://mboxviewerpro.com/) ## Otras 20 herramientas, ordenadas alfabéticamente ### 3. bandwhich: descubrir qué proceso está consumiendo la red bandwhich ayuda a responder una pregunta frecuente durante una incidencia: **qué aplicación está utilizando el ancho de banda**. Puede relacionar utilización de red con procesos, conexiones y direcciones remotas. Para investigar tráfico inesperado resulta más cómodo que correlacionar manualmente la información obtenida con varias herramientas del sistema. Conviene tener presente que necesita permisos suficientes para inspeccionar el tráfico de red. [bandwhich en GitHub](https://github.com/imsnif/bandwhich) ### 4. below: investigar qué ocurrió hace varias horas **below**, desarrollado originalmente por equipos de infraestructura de Meta, intenta solucionar una de las limitaciones de los monitores tradicionales. `top`, `htop` o btop explican muy bien qué sucede ahora. below puede además **registrar el estado del sistema y reproducirlo posteriormente**. Sus modos permiten recopilar información de procesos, recursos, cgroups y Pressure Stall Information (PSI) para investigarla después. Si una máquina tuvo problemas a las 03:00 pero funciona correctamente cuando el administrador entra cuatro horas después, esta capacidad cambia bastante el diagnóstico. [below en GitHub](https://github.com/facebookincubator/below) ### 5. bottom: otra alternativa moderna a top bottom, cuyo comando es `btm`, ofrece monitorización interactiva de procesador, memoria, red, almacenamiento, sensores y procesos. Está desarrollado en Rust y representa otra interpretación moderna de herramientas históricas como `top`. No es necesario tener instalados todos los monitores disponibles. Lo interesante es que `top` y `htop` ya no son las únicas opciones maduras para obtener una vista interactiva de Linux. [bottom en GitHub](https://github.com/ClementTsang/bottom) ### 6. Broot: navegar por árboles de directorios enormes Broot está diseñado para recorrer grandes estructuras de directorios sin imprimir miles de entradas en pantalla. Combina navegación, búsquedas difusas, previsualización de archivos, búsqueda dentro de su contenido y análisis del espacio utilizado. Puede ahorrar bastantes combinaciones repetitivas de `find`, `tree`, `grep` y `du`. [Broot en GitHub](https://github.com/Canop/broot) ### 7. btop: la salud del servidor en una pantalla btop es probablemente una de las TUI más fáciles de recomendar para empezar. CPU, memoria, discos, red y procesos aparecen en una única interfaz. También permite buscar procesos, inspeccionarlos y enviar señales sin cambiar continuamente entre `top`, `ps`, `free` y otras utilidades. Para una primera inspección después de conectarse mediante SSH a una máquina con problemas resulta especialmente práctico. [btop en GitHub](https://github.com/aristocratos/btop) ### 8. dive: averiguar qué hay realmente dentro de una imagen de contenedor dive aborda una cuestión diferente a lazydocker: **analizar las capas de una imagen Docker u OCI**. La aplicación permite observar cómo cambia la imagen capa a capa, qué archivos incorpora cada una y dónde se está desperdiciando espacio. Cuando una imagen aparentemente sencilla acaba ocupando varios gigabytes, dive ayuda a encontrar rápidamente el motivo. [dive en GitHub](https://github.com/wagoodman/dive) ### 9. Dolphie: monitorización de MySQL y MariaDB Dolphie está orientado a observar MySQL y MariaDB en tiempo real desde la terminal. Su objetivo principal no es convertirse en un editor SQL, sino ofrecer información operacional sobre consultas, sesiones, replicación y actividad del servidor. Para un DBA o sysadmin conectado mediante SSH puede proporcionar una fotografía mucho más manejable de lo que está ocurriendo en la base de datos. [Dolphie en G](https://github.com/charles-001/dolphie?utm_source=chatgpt.com)[i](https://github.com/charles-001/dolphie)[tHub](https://github.com/charles-001/dolphie?utm_source=chatgpt.com) ### 10. fzf: buscar prácticamente cualquier cosa fzf es una herramienta pequeña con un efecto sorprendentemente grande sobre el uso diario del shell. Convierte una lista en una búsqueda difusa interactiva. Archivos, historial de comandos, procesos, ramas Git, hosts SSH o la salida de otros programas pueden pasar por fzf. Su integración con `Ctrl+R` es especialmente útil: el historial deja de ser algo que se recorre para convertirse en algo que se busca. [fzf en GitHub](https://github.com/junegunn/fzf?) ### 11. gping: ping convertido en gráfico gping toma una utilidad extremadamente conocida y representa gráficamente la latencia dentro del terminal. Esto facilita detectar *jitter*, incrementos temporales de latencia y cambios de comportamiento durante una intervención. No sustituye a `mtr`, `traceroute` ni a una captura de paquetes. Simplemente permite interpretar visualmente una prueba muy habitual. [gping en GitHub](https://github.com/orf/gping) ### 12. Helix: un editor moderno con menos configuración Helix proporciona muchas de las funciones esperadas en un entorno moderno de desarrollo manteniéndose completamente dentro del terminal. Frente a instalaciones de Neovim fuertemente personalizadas, uno de sus atractivos es ofrecer bastantes capacidades desde el principio. Puede resultar interesante para administradores que ocasionalmente pasan de editar configuraciones a desarrollar directamente en una máquina remota. [Helix en GitHub](https://github.com/helix-editor/helix) ### 13. k9s: Kubernetes sin escribir kubectl continuamente `kubectl` sigue siendo imprescindible, pero k9s resulta especialmente cómodo para investigar un clúster en funcionamiento. Mantiene una vista actualizada de los recursos Kubernetes y permite navegar por pods, deployments y servicios, consultar logs y ejecutar diferentes operaciones. CLI y TUI se complementan bien: `kubectl` resulta excelente para automatización y procedimientos reproducibles; k9s permite recorrer visualmente el estado del clúster. [k9s en GitHub](https://github.com/derailed/k9s) ### 14. lazydocker: Docker desde una única interfaz Investigar contenedores suele implicar alternar entre `docker ps`, `docker logs`, `docker stats`, `docker inspect` y `docker exec`. lazydocker reúne buena parte de ese trabajo en una interfaz navegable. Contenedores, imágenes, volúmenes, estadísticas y logs quedan accesibles sin copiar continuamente nombres e identificadores. [lazydocker en GitHub](https://github.com/jesseduffield/lazydocker) ### 15. lazygit: Git resulta mucho más fácil de recorrer lazygit ofrece paneles dedicados a archivos, ramas, commits y *stashes*. Sus ventajas aparecen especialmente en operaciones como *staging* parcial, *rebase* interactivo, resolución de conflictos y *cherry-pick*. No evita tener que comprender Git. Hace bastante más rápidas determinadas operaciones una vez que el usuario sabe qué está haciendo. [lazygit en GitHub](https://github.com/jesseduffield/lazygit) ### 16. lazysql: bases de datos desde la terminal lazysql aplica una filosofía similar al trabajo con bases de datos relacionales. Proporciona una interfaz interactiva para recorrer objetos y trabajar con SQL sin necesidad de instalar un cliente gráfico completo. Es una opción especialmente interesante en máquinas de desarrollo remotas o entornos cuyo acceso habitual se realiza mediante SSH. [lazysql en GitHub](https://github.com/jorgerojas26/lazysql) ### 17. lnav: una interfaz para investigar logs Los logs siguen ocupando una parte considerable del trabajo de cualquier administrador Linux. lnav, **Logfile Navigator**, permite navegar, filtrar y analizar archivos de registro desde una interfaz interactiva. Puede reconocer diferentes formatos y ordenar conjuntamente información procedente de varios archivos. No sustituye una plataforma centralizada de logs, pero puede hacer mucho más rápida una investigación sobre una máquina concreta. [lnav en GitHub](https://github.com/tstack/lnav) ### 18. ncdu: encontrar dónde se ha ido el espacio Pocas frases generan tanta urgencia en Linux como: ``` No space left on device ``` ncdu analiza árboles de directorios y muestra interactivamente dónde se concentra el consumo de almacenamiento. Es una de esas herramientas que muchos administradores descubren durante una incidencia y terminan conservando permanentemente. [ncdu en GitHub](https://github.com/rofl0r/ncdu) ### 19. Neovim: convertir la terminal en un entorno de desarrollo Neovim puede combinar resaltado de sintaxis, Language Server Protocol (LSP), autocompletado, diagnósticos, búsqueda difusa, Git y un enorme catálogo de plugins. Con una configuración adecuada puede comportarse como un entorno completo de desarrollo. Esa flexibilidad explica también su inconveniente: configurar Neovim puede acabar convirtiéndose en un proyecto independiente. [Neovim en GitHub](https://github.com/neovim/neovim) ### 20. Posting: probar APIs sin un pesado cliente de escritorio Posting es un cliente HTTP para trabajar interactivamente con APIs desde la terminal. Permite construir peticiones, manejar colecciones y entornos y consultar respuestas manteniendo todo el flujo de trabajo dentro del terminal. Para equipos de desarrollo tiene además otra ventaja: las peticiones pueden mantenerse en archivos convencionales y versionarse junto al código. [Posting en GitHub](https://github.com/darrenburns/posting) ### 21. termshark: analizar paquetes sin abrir Wireshark termshark proporciona una interfaz de terminal sobre `tshark`. El planteamiento resulta especialmente útil cuando hay que analizar tráfico directamente sobre un servidor Linux remoto y abrir una sesión gráfica de Wireshark resulta incómodo o imposible. No elimina la necesidad de conocer protocolos, filtros de captura o filtros de visualización. Hace más cómoda la exploración de los paquetes capturados. [termshark en GitHub](https://github.com/gcla/termshark) ### 22. tmux: sesiones SSH que sobreviven a una desconexión tmux no es una herramienta de monitorización, pero resulta difícil hablar de administración Linux remota sin incluirlo. Permite crear ventanas y paneles y, sobre todo, **separarse de una sesión sin finalizar los procesos que se están ejecutando**. Una actualización, compilación o investigación puede continuar aunque desaparezca la conexión SSH. Al volver, el administrador simplemente recupera la sesión. [tmux en GitHub](https://github.com/tmux/tmux) ## Por qué estas herramientas encajan tan bien con Linux El denominador común de estos proyectos no es intentar recuperar la informática de los años ochenta. Es algo bastante más práctico: **el servidor donde está el problema muchas veces no tiene escritorio**. Puede ser una máquina virtual, un servidor físico en un centro de datos, una instancia cloud, un nodo Kubernetes o un sistema accesible únicamente mediante VPN y SSH. Añadir una interfaz web de administración puede significar desplegar otro servicio, abrir otro puerto, gestionar otra autenticación y mantener otra pieza de software. Una aplicación de terminal necesita mucho menos. También está la cuestión de los recursos. Si el administrador entra precisamente porque la memoria está agotándose o la CPU permanece al 100 %, utilizar una herramienta ligera para encontrar la causa tiene bastante sentido. Los lenguajes utilizados cuentan otra parte de la historia. **Rust, Go y C++ moderno** aparecen constantemente en esta generación de herramientas. mboxShell, Yazi, bottom y otros proyectos han sido creados recientemente por desarrolladores que podían construir interfaces gráficas, pero eligieron deliberadamente el terminal. La variedad alcanzada también resulta reveladora. Un administrador puede revisar recursos con btop, reconstruir una incidencia pasada con below, analizar logs con lnav, localizar consumo de almacenamiento con ncdu, inspeccionar paquetes con termshark, operar Kubernetes con k9s, investigar imágenes de contenedores con dive, recorrer un archivo de correo de decenas de gigabytes con mboxShell y mantener toda la sesión abierta dentro de tmux. No obstante, que una herramienta sea open source no significa que deba instalarse indiscriminadamente en producción. Hay que revisar procedencia, mantenimiento, dependencias, método de distribución y permisos requeridos. Un analizador de paquetes puede necesitar acceso al tráfico de red. k9s puede heredar credenciales capaces de modificar un clúster Kubernetes. Un cliente SQL puede tener permisos de escritura sobre producción. ncdu puede borrar archivos. **Una interfaz cómoda no reduce los privilegios del proceso que existe detrás.** Por eso una selección inicial razonable podría limitarse a btop para observar el sistema, ncdu para almacenamiento, tmux para mantener sesiones, fzf para buscar y lnav para analizar logs. Después tiene sentido añadir herramientas cuando existe una necesidad concreta: k9s para Kubernetes, lazydocker y dive para contenedores, Dolphie para MySQL, termshark para redes, below para análisis histórico o mboxShell cuando toca enfrentarse a grandes archivos de correo. Esa convivencia explica también por qué las TUI no están sustituyendo a los comandos tradicionales. La CLI continúa siendo mejor para **automatización, scripts y operaciones reproducibles**. Las TUI funcionan especialmente bien para **explorar, investigar y trabajar de forma interactiva**. El sysadmin de 2026 utiliza ambas. La terminal no ha sustituido al escritorio y las aplicaciones gráficas tampoco han conseguido sustituir al shell. Lo que sí ha cambiado es la calidad y variedad del software que ahora puede vivir entre esos dos mundos. ## Preguntas frecuentes ### ¿Qué diferencia hay entre una CLI y una TUI? Una CLI suele ejecutar una instrucción y devolver un resultado. Una TUI permanece activa y ofrece una interfaz interactiva dentro del terminal. Las primeras encajan mejor con automatización y scripts; las segundas resultan especialmente cómodas para navegación, monitorización e investigación. ### ¿Qué TUI son más útiles para un administrador Linux? btop, below, ncdu, lnav y tmux forman una buena base general. k9s resulta especialmente interesante para Kubernetes, lazydocker para Docker, Dolphie para MySQL y termshark para análisis de red. ### ¿Para qué sirve mboxShell? mboxShell es una aplicación open source desarrollada en Rust para abrir, indexar, buscar y exportar grandes archivos MBOX. Está especialmente orientada a Gmail Takeout, migraciones, auditorías y archivos históricos de correo que interesa procesar localmente. ### ¿Es seguro instalar estas herramientas en servidores de producción? Que un proyecto sea open source permite inspeccionar su código, pero no convierte automáticamente cualquier binario en adecuado para producción. Antes de instalarlo conviene revisar quién mantiene el proyecto, cómo se distribuyen sus versiones, qué dependencias utiliza y qué privilegios necesita. **Fuentes:** - Repositorios oficiales en GitHub de FlarePurge, mboxShell, bandwhich, below, bottom, Broot, btop, dive, Dolphie, fzf, gping, Helix, k9s, lazydocker, lazygit, lazysql, lnav, ncdu, Neovim, Posting, termshark y tmux. - FlarePurge, documentación oficial del proyecto. - mboxShell, documentación oficial y repositorio del proyecto. - Mbox Viewer Pro, documentación oficial. - Meta, documentación del proyecto below.