Terminal on Backend Engineering Strategy Tools

Terminal Multiplexers

Tue, 12 May 2026 00:00:00 +0000

This note explores the choice between Zellij and tmux for terminal multiplexing.

Why use a terminal multiplexer?

Terminal multiplexers allow you to run multiple terminal sessions within a single window, detach from them, and reattach later. This is incredibly useful for:

Persistent sessions (e.g., long-running processes continue even if your SSH connection drops).
Organizing multiple tasks (tabs, panes).
Remote development.

Tmux

https://github.com/tmux/tmux

Introduction: tmux is a long-standing and extremely powerful terminal multiplexer. It’s highly configurable and has a vast user base.

Pros:

Mature and stable.
Very flexible and customizable.
Widely adopted, lots of resources and plugins.

Cons:

Configuration can be complex and requires significant effort to set up to personal taste.
Default keybindings can be arcane.
Can feel a bit dated in terms of user experience compared to newer alternatives.

Zellij

https://zellij.dev/

Introduction: Zellij is a newer, more modern terminal workspace and multiplexer, designed with a focus on good defaults and a more intuitive user experience.

Pros:

Modern design and user interface.
Sensible defaults that often require less configuration out of the box.
Built-in layout management.
Rust-based, often praised for performance and safety.

Cons:

Newer, so the ecosystem of plugins and community support is smaller than tmux.
May not have the sheer depth of customization options available in tmux (though this is also a pro for simplicity).

Initial Thoughts / Direction

Given the preference for good defaults and minimal tinkering, Zellij is the stronger contender — modern take on multiplexing without the configuration overhead of tmux.

Current status

Not using either. The setup cost hasn’t been worth it yet — plain terminal, one thing per tab works fine for now.

The main argument for multiplexers is session persistence: if your connection drops or terminal closes, the session keeps running server-side. That matters most when SSHing into remote servers and running things interactively. That pattern is largely avoided here in favour of CI/CD pipelines — if something needs to run remotely, it runs in a pipeline, not in a terminal session.

Working locally with a modern terminal (iTerm2, Wezterm, etc.) that has native tabs and split panes, the marginal gain is genuinely small day-to-day. Rational laziness — the cost-benefit only flips when remote work or session persistence becomes a real part of the workflow.

Will revisit if that assumption changes.

Terminal Setup Notes (macOS): Kitty → Ghostty Exploration

Wed, 06 May 2026 00:00:00 +0000

I’ve been using kitty as my main terminal for a while. It’s fast, stable, and very capable — but I’ve realized I don’t actually enjoy tweaking terminal configs or maintaining a highly customized setup.

So I’m exploring simpler alternatives with good defaults.

Current direction: Ghostty

Trying out: Ghostty
https://ghostty.org/

Why:

Clean macOS-native feel
GPU-accelerated and fast
Tabs + splits built in
Designed for sane defaults (low configuration overhead)
Keyboard-first workflow works well out of the box
My only config change: Remapped tab switching shortcut (default ][ to alt-[/] for easier access on a Swedish keyboard layout).

Goal:
Less time configuring terminal → more time working.

Why the switch

Simplified setup: I found myself spending less time tweaking and more time working.
Perceived responsiveness: Both are fast, but Ghostty felt marginally snappier in heavy-usage scenarios.
Clean design: The aesthetic and functional minimalism resonated more with my current preferences.

What I’m moving away from (for now)

kitty

https://sw.kovidgoyal.net/kitty/

What I liked:

Very fast, GPU-accelerated rendering
Highly configurable via a single kitty.conf
Excellent font rendering — ligatures, custom fonts
Extensible with Kitten modules (tabs, scrollback, multiplexing)
Stable and mature

Why I’m moving on:

Too much customization surface area
I don’t actually enjoy tuning it

Other tools I’ve looked at

Warp

https://warp.dev/

Warp feels like a “terminal reinvented” (more IDE-like, block-based UI, AI features). It’s interesting, but feels a bit too opinionated and visually heavy for my taste.

Other Terminal Emulators (briefly noted)

While Kitty and Ghostty are modern GPU-accelerated terminals, it’s worth acknowledging other terminal emulators that have been foundational or offer different philosophies.

https://www.x.org/releases/X11R7.6/doc/man/man1/xterm.1.xhtml

The classic X Window System terminal emulator. While not as feature-rich or graphically advanced as modern options, xterm (and its derivatives like urxvt, st, etc.) represent the minimalist, highly customizable end of the spectrum. They often prioritize resource efficiency and adherence to traditional Unix principles. Good for when you need something simple and rock-solid, but usually requires more effort to get a pleasant default experience.

Current philosophy

I’m optimizing for:

minimal clutter
fast keyboard workflow
good defaults (not deep config systems)
fewer moving parts

Current setup direction

Terminal: Ghostty
Tabs: built-in (no extra tooling yet)
Multiplexing: not using tmux/Zellij for now
Keeping things intentionally simple

Open question

If Ghostty tabs feel too minimal in real use, I may revisit:

Zellij (for structured sessions)
tmux (unlikely unless necessary)

For now, keeping it simple on purpose.

K9s & Lens

Mon, 01 Jan 2024 00:00:00 +0000

You run everything with kubectl. Get pods, describe, logs, exec, delete, apply — fifty times a day across five namespaces. It works, but every command is a context switch: type, wait, read, type again. -n namespace on every single invocation.

So you use K9s. A terminal UI that shows your entire cluster in one view. Switch namespaces and clusters in a keystroke, tail logs in real time, exec into a pod without constructing the command — everything you reach for in kubectl, but without the friction.

K9s

K9s is a TUI (terminal UI) for Kubernetes. It stays in your terminal, updates live, and is keyboard-driven throughout.

brew install derailed/k9s/k9s
k9s # connect to current context
k9s --context prod # specific context
k9s -n monitoring # start in a specific namespace

Key	Action
`:pod`	Jump to pods view
`:deploy`	Deployments
`:svc`	Services
`:ns`	Switch namespace
`/`	Filter/search
`l`	Logs
`e`	Edit resource YAML
`d`	Describe
`s`	Shell into pod
`ctrl-d`	Delete
`?`	Help / full keybinding list

Most resource types are reachable by typing : followed by the resource name — :configmap, :secret, :ingress, :pvc, and so on.

Why TUI over GUI

K9s lives in the terminal alongside your other tools. No window switching, works over SSH, starts instantly, and the keyboard-driven workflow is faster once it is in muscle memory. For day-to-day cluster work it is the right default.

Lens

Lens is a desktop GUI for Kubernetes — a full IDE-style interface with a visual cluster overview, resource browsing, metrics charts, log streaming, and terminal access built in.

It is the better choice when you need to onboard someone who is not yet comfortable with the terminal, or when you want a visual overview to share with a non-technical stakeholder. For engineers doing operational work all day, K9s is faster.

Worth noting: Lens has moved toward a commercial model (Lens Desktop Pro). OpenLens is the open-source build of the same codebase, without the account requirement.

kubectx / kubens

If K9s is more than you need and you just want to stop typing --context and -n on every command, kubectx and kubens solve exactly that:

kubectx # list contexts
kubectx prod # switch to prod context
kubectx - # switch back to previous context

kubens # list namespaces
kubens monitoring # switch default namespace

No TUI, no GUI — just fast context and namespace switching that persists for the rest of your terminal session. Install alongside K9s; they complement each other.

brew install kubectx

Resources

K9s documentation
K9s GitHub
Lens
OpenLens — open-source Lens build
kubectx/kubens — fast context and namespace switching