Hi everyone, welcome back. Today, I will be going over TUIs — what they are, why they've made an unexpected comeback, and which ones are genuinely worth installing.

I'll write this for someone who isn't already living in a terminal. If your mental image of a command line is green text on a black screen from a 1980s movie, that picture is about thirty years out of date and this article should fix it.

What Is a TUI

TUI stands for Text User Interface. It's an application that runs inside your terminal but behaves like a real program — panels, menus, live-updating graphs, mouse support, colors — all drawn with text characters.

The clearest way to understand it is against the two things it sits between.

CLI (Command Line Interface) — you type a command, it prints a result, it exits. git log shows you a list and you're done. One question, one answer.

GUI (Graphical User Interface) — a window with buttons and menus you click. Photoshop, your browser, Slack.

TUI — takes over your terminal window and keeps running. It has navigable panels you move between with arrow keys, it updates live, and you interact with it continuously.

The distinction that matters: CLI is for asking one question or running one job. TUI is for working with something over time.

git log is CLI. lazygit is TUI. docker ps is CLI. lazydocker is TUI. top is CLI-ish. btop is TUI.

Why it matters: CLI is better for scripting and automation, because it composes with other commands. TUI is better for browsing, monitoring, and exploring — jobs where you need to look around and react rather than issue one instruction.

Why This Came Back

TUIs aren't new. They're what software looked like before graphical interfaces existed. So why is a forty-year-old idea suddenly worth writing about?

They work over SSH. When you're connected to a server three time zones away, you cannot open a graphical application. A TUI works identically on a remote machine as on your laptop, over a slow connection, with no display forwarding.

They're fast. No Electron, no browser engine, no 400MB of RAM to show a list of commits. Most of these launch instantly and use a few megabytes.

Keyboard-driven means genuinely faster. Once the shortcuts are muscle memory, you're not moving a hand to a mouse or hunting for a menu.

They stopped being ugly. This is the real change. Modern terminals support 24-bit color and Unicode block characters, so a TUI in 2026 can draw smooth graphs and clean layouts that look like a designed application rather than a text dump.

And developers already live in the terminal. If your editor, your shell, and your build tools are already there, leaving to click something in a separate window is a context switch you didn't need.

1. lazygit — Git

What it is: A full Git interface in your terminal.

What it gives you: Panels showing your files, branches, commits, and stashes. Stage individual lines rather than whole files. Interactive rebase by moving commits up and down. Side-by-side conflict resolution where you pick lines from either version. Cherry-picking by pressing C on a commit and V where you want it. Built-in undo with z.

Why you'd use it: Git's command line is famously verbose for anything beyond commit and push, and most people cope by memorizing four commands and googling the rest. lazygit puts the operations you avoid — interactive rebase, partial staging, cherry-picking — behind one or two keystrokes.

Why it works: the undo feature changes behavior more than the shortcuts do. Being able to reverse an operation means you experiment with Git instead of avoiding anything unfamiliar.

More information on lazygit including installation instructions can be found here.

2. btop — System Monitoring

What it is: A rebuild of the classic top process viewer, written in C++, with actual visual design.

What it gives you: CPU load and per-core utilization, memory, disk I/O, and network traffic on one screen, with graphs drawn using Unicode braille characters and 24-bit color. An interactive process list you can scroll, search with f, and terminate with t or kill with k. Configurable layout presets and themes.

Why you'd use it: On a server you've SSH'd into, it replaces four separate commands with a single view. And it's the one that converts people — it takes thirty seconds to install and it's immediately, visibly better than what it replaced.

Why it works: it's the best first TUI precisely because there's nothing to learn. Run it and the value is obvious.

3. k9s — Kubernetes

What it is: A live, navigable dashboard for Kubernetes clusters.

What it gives you: Type :pods to see pods, :svc for services, :deployments for deployments. Tail logs, exec into a container, port-forward, describe, and delete resources without leaving the interface. It continuously watches the cluster and updates as things change.

Why you'd use it: Kubernetes is powerful and genuinely unfriendly from the command line. Typing kubectl get pods -n my-namespace -o wide twenty times a day gets old, and k9s turns that stream of typed queries into something you browse.

Why it works: it's the proof that terminal interfaces scale beyond local developer chores to real infrastructure work. It's under active development — version 0.51.0 shipped in June 2026 — and it stands in for the web dashboard and desktop tools like Lens.

4. lazydocker — Containers

What it is: lazygit's sibling, for Docker.

What it gives you: Containers, images, volumes, and networks in navigable panels. Live logs, resource usage graphs per container, shell access, and restart or remove with a keystroke.

Why you'd use it: Debugging containers normally means juggling docker ps, docker logs, docker exec, and docker stats in separate commands while copying container IDs between them. This puts all of it in one place.

Alternative worth knowing: oxker does a similar job with a lighter footprint.

5. yazi — File Management

What it is: A fast terminal file manager written in Rust.

What it gives you: Multi-column navigation showing your current directory and a preview of whatever is selected — including image previews in terminals that support them. Fuzzy search, batch renaming, background file operations, and Vim-style keybindings.

Why you'd use it: Navigating directories with cd and ls works, but it's slow when you're exploring rather than going somewhere specific. A file manager lets you look around.

Alternatives: ranger is the long-established Python option; nnn is the minimal one.

6. fzf — Fuzzy Finding

What it is: A general-purpose fuzzy finder, and arguably the highest-value tool on this list.

What it gives you: Pipe any list into it — files, command history, Git branches, running processes — and get an interactive search that filters as you type.

Why you'd use it: It's less an application than a component you wire into everything else. Bound to Ctrl+R, it turns shell history from something you scroll through into something you search. Combined with other commands, it makes almost anything selectable.

Why it works: it does one thing and composes with everything, which is why it shows up inside so many other tools. If you install one item from this list and build a habit around it, make it this one.

7. posting — API Testing

What it is: A terminal HTTP client for testing APIs.

What it gives you: Build and send requests, manage collections and environments, inspect responses with syntax highlighting, and store everything as plain files you can commit to version control.

Why you'd use it: The dominant graphical API clients have grown into heavy applications with accounts, cloud sync, and subscription tiers. If you just want to send a request and read the response, this does that without any of it — and because collections are plain text, they version and diff properly.

8. ncdu — Disk Usage

What it is: An interactive disk usage analyzer.

What it gives you: Scans a directory tree and shows what's consuming space, sorted largest first, and lets you navigate into folders to find the culprit. You can delete from inside it.

Why you'd use it: "The server's disk is full" is a recurring emergency, and du -sh * repeated at each level is a tedious way to hunt. ncdu finds it in about twenty seconds.

Why it works: it's the tool you install during an incident and then keep forever.

9. Neovim or Helix — Editing

What it is: Modern terminal text editors.

What they give you: Syntax highlighting, language server support for autocomplete and error checking, fuzzy file finding, integrated Git, and plugin ecosystems. Effectively a full development environment in a terminal.

Why you'd use them: Editing files on a remote server is the unavoidable case — you can't open VS Code on a machine with no display. Beyond that, some people simply prefer keyboard-driven editing.

The honest note: Neovim has a real learning curve and a configuration culture that can consume weekends. Helix is worth knowing as the alternative — it ships with sensible defaults and language support built in, requiring almost no configuration.

10. below — The Interesting One

What it is: A system monitor from Meta's infrastructure team, and the least known tool here.

What it gives you: Everything a normal monitor does, plus its headline feature — it records system state continuously and lets you replay the past.

Why you'd use it: Every other monitor shows you the present. When a server had a problem at 3am, that's useless — the spike is over, the process is gone, and all you have is a graph with no detail. below lets you scroll back to 3am and inspect exactly what was running.

Why it works: it solves the actual problem with system monitoring, which was never "what's happening now" but "what happened when I wasn't looking."

Also Worth Knowing

tmux — not a TUI exactly, but a terminal multiplexer that lets you split your terminal into panes and keep sessions alive after you disconnect. Essential if you work on remote servers, because your work survives a dropped connection.

tig — a lighter, focused Git log browser if lazygit is more than you want.

gum — for building your own interactive prompts in shell scripts.

A Note If You're on Windows

Most of these were built for Linux and macOS first, but the situation is better than it used to be.

lazygit and fzf install cleanly via Scoop, and k9s is available through Chocolatey. For the rest, WSL (Windows Subsystem for Linux) is the practical answer — you get a real Linux environment where everything on this list works normally, and Windows Terminal renders the colors and Unicode graphics properly.

Worth knowing: btop in particular is Linux and macOS oriented, so WSL is the route there.

Where to Start

Don't install ten things. That's how you end up using none of them.

Start with btop. Thirty seconds, immediately useful, nothing to learn.

Then add lazygit if you use Git daily. Set an alias — lg — because typing the full name is enough friction to stop you.

Then fzf, bound to your shell history. It's the one that quietly changes how you use the terminal.

After that, add tools only when you have the specific problem they solve. k9s when you're managing clusters. lazydocker when you're debugging containers. ncdu the next time a disk fills up.

Two directories worth bookmarking if you want to explore further: terminaltrove.com and the community-maintained awesome-tuis list on GitHub, both organized by category.

Conclusion

This concludes my article on TUIs. The short version: a TUI is a full application running inside your terminal, better than a CLI for anything you interact with over time, and better than a GUI when you're working remotely or want to stay on the keyboard. btop for system monitoring, lazygit for Git, k9s for Kubernetes, fzf for finding things, and the rest as specific needs arise.

What I find genuinely interesting about this category is that it isn't nostalgia. These tools didn't survive from the 1980s — they were built recently, in Go and Rust and modern C++, by people who had graphical alternatives available and chose to build something else.

They did it because the graphical version had gotten heavy, or required an account, or couldn't run where the work actually happens. A terminal interface has none of those problems. It starts instantly, runs anywhere you have a shell, weighs a few megabytes, and works the same over a slow SSH connection as it does locally.

That's not a retreat to the past. It's a set of constraints that turned out to still be worth having.

I hope this helps. If you have any questions or comments, please let me know. Thanks for reading!