Terminal interfaces are going through a new phase that has little to do with reviving software from the past. Today’s TUIs (Text User Interfaces) let you monitor Linux servers, analyze networks, manage Kubernetes, work with containers, dig through logs, browse huge mail archives, or handle repositories without relying on heavy desktop applications. For a systems administrator, they have another hard-to-match advantage: many of them work perfectly over SSH and keep the work close to the machine where the problem is actually happening.
TUIs and open source tools: the key points in 20 seconds
- The list opens with FlarePurge, for managing Cloudflare cache, and mboxShell, for large MBOX files.
- The other 20 tools are listed alphabetically for easy reference.
- btop, below, bottom, lnav, and ncdu help diagnose Linux.
- k9s, lazydocker, and dive cover Kubernetes and containers.
- Networking, Git, databases, APIs, and editing round out a toolbox that’s especially useful over SSH.
The line between CLI and TUI isn’t always clean. A command-line interface (CLI) typically receives one instruction, runs one operation, and returns control to the shell. A TUI stays open, keeps updating information, and offers panels, selection, navigation, and interactive actions.
Not every tool on this list is a strict TUI, either. FlarePurge is a good example. It made the cut because it reflects the same shift toward small, specialized, open utilities, as opposed to ever-larger administration suites.
The list is meant, then, as a practical toolbox for Linux administrators and developers.
Two projects worth knowing about
1. FlarePurge: managing Cloudflare cache with a dedicated tool
FlarePurge solves one very specific task: purging the cache for Cloudflare zones without constantly having to log into its admin panel.
The application talks directly to the Cloudflare API using tokens with limited permissions, and it lets you work with multiple accounts, run full purges, and selectively clear the cache for specific URLs or hostnames.
This can be especially handy for web administrators, developers, WordPress managers, or sysadmins who manage numerous domains and need to invalidate content frequently.
It also encourages a good security practice. Clearing a cache doesn’t require a credential with full control over an account. A token limited strictly to the operations needed reduces the impact of any potential exposure.
FlarePurge has native implementations and its code is distributed under the MIT license. It’s not a traditional TUI, but it shares the philosophy of many tools on this list: doing one specific job well without forcing the administrator to work inside a large platform.
2. mboxShell: browsing huge MBOX files from the terminal
Email files don’t usually show up in sysadmin toolkit roundups, but mboxShell addresses a fairly real problem: working with large MBOX files without loading the entire mailbox into memory.
It’s an open source application built in Rust for opening, searching, browsing, and exporting MBOX files. It can be used with Gmail copies generated via Google Takeout, Thunderbird files, and mailboxes from Unix systems.
Its TUI is built with Ratatui and includes vi-style navigation, different views, grouped conversations, Gmail labels, and advanced searches using fields such as from:, subject:, date:, body:, or has:attachment.
It also works as a CLI tool. This makes it possible to index mailboxes, run searches from scripts, extract attachments, export messages, or merge several MBOX files with deduplication.
One of its most interesting aspects is how it handles large files. Instead of loading the entire mailbox into RAM, it uses sequential reads and builds a persistent index. The project’s documentation reports tests with Gmail Takeout files larger than 50 GB.
The project also serves as the open foundation for Mbox Viewer, a native macOS and Windows application aimed at people who need to work with this type of file through a graphical interface. It processes mail locally and lets you browse MBOX and EML files, Gmail labels, conversations, searches, and exports.
20 more tools, listed alphabetically
3. bandwhich: finding out which process is eating your bandwidth
bandwhich helps answer a common question during an incident: which application is using the bandwidth.
It can map network usage to processes, connections, and remote addresses. For investigating unexpected traffic, it’s more convenient than manually correlating information gathered from several system tools.
It’s worth keeping in mind that it needs sufficient permissions to inspect network traffic.
4. below: investigating what happened hours ago
below, originally developed by Meta’s infrastructure teams, tries to solve one of the limitations of traditional monitors.
top, htop, or btop do a great job of showing what’s happening right now. below can also record the system’s state and play it back later.
Its modes let you collect information on processes, resources, cgroups, and Pressure Stall Information (PSI) to investigate afterward.
If a machine had problems at 3:00 a.m. but is running fine when the administrator logs in four hours later, this capability changes the diagnosis quite a bit.
5. bottom: another modern alternative to top
bottom, whose command is btm, offers interactive monitoring of CPU, memory, network, storage, sensors, and processes.
It’s built in Rust and represents another modern take on longstanding tools like top.
You don’t need to have every available monitor installed. What’s interesting is that top and htop are no longer the only mature options for getting an interactive view of Linux.
6. Broot: navigating huge directory trees
Broot is designed to browse large directory structures without printing thousands of entries to the screen.
It combines navigation, fuzzy search, file previews, content search, and disk usage analysis.
It can save you quite a few repetitive combinations of find, tree, grep, and du.
7. btop: server health on a single screen
btop is probably one of the easiest TUIs to recommend for getting started.
CPU, memory, disks, network, and processes all show up in a single interface. It also lets you search for processes, inspect them, and send signals without constantly switching between top, ps, free, and other utilities.
It’s especially practical for a first look right after SSHing into a machine that’s having problems.
8. dive: finding out what’s really inside a container image
dive tackles a different question than lazydocker: analyzing the layers of a Docker or OCI image.
The application lets you see how the image changes layer by layer, which files each one adds, and where space is being wasted.
When a seemingly simple image ends up taking up several gigabytes, dive helps quickly track down the reason.
9. Dolphie: monitoring MySQL and MariaDB
Dolphie is built for watching MySQL and MariaDB in real time from the terminal.
Its main goal isn’t to be a SQL editor, but to provide operational insight into queries, sessions, replication, and server activity.
For a DBA or sysadmin connected over SSH, it can provide a much more manageable snapshot of what’s happening in the database.
10. fzf: searching almost anything
fzf is a small tool with a surprisingly big effect on day-to-day shell use.
It turns any list into an interactive fuzzy search. Files, command history, processes, Git branches, SSH hosts, or the output of other programs can all be piped through fzf.
Its Ctrl+R integration is especially useful: history stops being something you scroll through and becomes something you search.
11. gping: turning ping into a graph
gping takes an extremely well-known utility and plots latency graphically right inside the terminal.
This makes it easier to spot jitter, temporary latency spikes, and behavior changes during a troubleshooting session.
It doesn’t replace mtr, traceroute, or a packet capture. It simply lets you interpret a very common test visually.
12. Helix: a modern editor with less configuration
Helix provides many of the features expected in a modern development environment while staying entirely inside the terminal.
Compared to heavily customized Neovim setups, one of its selling points is offering plenty of capability right out of the box.
It can be worth a look for administrators who occasionally go from editing configuration files to developing directly on a remote machine.
13. k9s: Kubernetes without typing kubectl over and over
kubectl is still essential, but k9s is especially convenient for investigating a running cluster.
It keeps an updated view of Kubernetes resources and lets you navigate pods, deployments, and services, check logs, and run various operations.
CLI and TUI complement each other well: kubectl is excellent for automation and reproducible procedures; k9s lets you visually browse the cluster’s state.
14. lazydocker: Docker from a single interface
Investigating containers usually means switching between docker ps, docker logs, docker stats, docker inspect, and docker exec.
lazydocker brings much of that work together into a navigable interface.
Containers, images, volumes, stats, and logs all become accessible without constantly copying names and IDs.
15. lazygit: making Git much easier to navigate
lazygit offers dedicated panels for files, branches, commits, and stashes.
Its advantages show up especially in operations like partial staging, interactive rebase, conflict resolution, and cherry-picking.
It doesn’t spare you from having to understand Git. It just makes certain operations quite a bit faster once you know what you’re doing.
16. lazysql: databases from the terminal
lazysql applies a similar philosophy to working with relational databases.
It provides an interactive interface for browsing objects and working with SQL without needing to install a full graphical client.
It’s a particularly appealing option on remote development machines or environments that are normally accessed over SSH.
17. lnav: an interface for investigating logs
Logs still take up a considerable share of any Linux administrator’s work.
lnav, the Logfile Navigator, lets you navigate, filter, and analyze log files from an interactive interface. It can recognize different formats and merge information from several files together.
It doesn’t replace a centralized logging platform, but it can make investigating a specific machine much faster.
18. ncdu: finding out where your space went
Few phrases create as much urgency on Linux as:
No space left on devicencdu analyzes directory trees and interactively shows where storage usage is concentrated.
It’s one of those tools many administrators discover during an incident and end up keeping around for good.
19. Neovim: turning the terminal into a development environment
Neovim can combine syntax highlighting, Language Server Protocol (LSP) support, autocompletion, diagnostics, fuzzy search, Git, and a huge catalog of plugins.
With the right configuration, it can behave like a full development environment.
That flexibility also explains its downside: configuring Neovim can end up becoming a project in its own right — as many advanced Linux desktop setups built around dotfiles and terminal-first workflows show.
20. Posting: testing APIs without a heavy desktop client
Posting is an HTTP client for working interactively with APIs from the terminal.
It lets you build requests, manage collections and environments, and inspect responses while keeping the whole workflow inside the terminal.
For development teams, it has another advantage: requests can be kept in plain files and versioned alongside the code.
21. termshark: analyzing packets without opening Wireshark
termshark provides a terminal interface on top of tshark.
This approach is especially useful when you need to analyze traffic directly on a remote Linux server and opening a graphical Wireshark session is awkward or simply not possible.
It doesn’t eliminate the need to know protocols, capture filters, or display filters. It just makes exploring captured packets more comfortable.
22. tmux: SSH sessions that survive a disconnect
tmux isn’t a monitoring tool, but it’s hard to talk about remote Linux administration without including it.
It lets you create windows and panes and, above all, detach from a session without ending the processes running inside it.
An update, a build, or an investigation can keep running even if the SSH connection drops. When you come back, you simply reattach to the session.
Why these tools fit Linux so well
The common thread among these projects isn’t trying to bring back 1980s computing.
It’s something much more practical: the server where the problem lives often has no desktop at all.
It could be a virtual machine, a physical server in a data center, a cloud instance, a Kubernetes node, or a system reachable only via VPN and SSH.
Adding a web-based admin interface can mean deploying another service, opening another port, managing another authentication layer, and maintaining another piece of software — something the maintainers of lightweight panels like 1Panel have also had to weigh. A terminal application needs a lot less.
There’s also the resource question. If the administrator is logging in precisely because memory is running out or the CPU is pegged at 100%, using a lightweight tool to find the cause makes a lot of sense.
The languages used tell another part of the story. Rust, Go, and modern C++ show up constantly in this generation of tools. mboxShell, Yazi, bottom, and other projects were recently built by developers who could have built graphical interfaces but deliberately chose the terminal instead.
The range these tools cover is also telling.
An administrator can check resources with btop, reconstruct a past incident with below, analyze logs with lnav, track down storage usage with ncdu, inspect packets with termshark, operate Kubernetes with k9s, investigate container images with dive, browse a mail archive of dozens of gigabytes with mboxShell, and keep the whole session open inside tmux.
That said, a tool being open source doesn’t mean it should be installed indiscriminately in production.
You need to check provenance, maintenance, dependencies, distribution method, and required permissions. A packet analyzer may need access to network traffic. k9s can inherit credentials capable of modifying a Kubernetes cluster. A SQL client may have write permissions on production. ncdu can delete files.
A convenient interface doesn’t reduce the privileges of the process running behind it.
That’s why a reasonable starting selection could be limited to btop for watching the system, ncdu for storage, tmux for keeping sessions alive, fzf for searching, and lnav for analyzing logs.
After that, it makes sense to add tools as specific needs come up: k9s for Kubernetes, lazydocker and dive for containers, Dolphie for MySQL, termshark for networking, below for historical analysis, or mboxShell when it’s time to deal with large mail archives.
This coexistence also explains why TUIs aren’t replacing traditional commands.
The CLI is still better for automation, scripts, and reproducible operations. TUIs work especially well for exploring, investigating, and working interactively.
The 2026 sysadmin uses both.
The terminal hasn’t replaced the desktop, and graphical applications haven’t managed to replace the shell either. What has changed is the quality and variety of the software that can now live between those two worlds.
Frequently asked questions
What’s the difference between a CLI and a TUI?
A CLI usually runs one instruction and returns a result. A TUI stays active and offers an interactive interface inside the terminal. The former fits better with automation and scripts; the latter is especially convenient for navigation, monitoring, and investigation.
Which TUIs are most useful for a Linux administrator?
btop, below, ncdu, lnav, and tmux form a solid general base. k9s is especially useful for Kubernetes, lazydocker for Docker, Dolphie for MySQL, and termshark for network analysis.
What is mboxShell for?
mboxShell is an open source application built in Rust for opening, indexing, searching, and exporting large MBOX files. It’s especially geared toward Gmail Takeout, migrations, audits, and historical mail archives that need to be processed locally.
Is it safe to install these tools on production servers?
A project being open source lets you inspect its code, but that doesn’t automatically make every binary suitable for production. Before installing it, it’s worth checking who maintains the project, how its releases are distributed, what dependencies it uses, and what privileges it needs.
Sources:
- Official GitHub repositories for FlarePurge, mboxShell, bandwhich, below, bottom, Broot, btop, dive, Dolphie, fzf, gping, Helix, k9s, lazydocker, lazygit, lazysql, lnav, ncdu, Neovim, Posting, termshark, and tmux.
- FlarePurge, official project documentation.
- mboxShell, official documentation and project repository.
- Mbox Viewer Pro, official documentation.
- Meta, below project documentation.
