tmux on Prod After Screen

Why We Switched from Screen to tmux

Screen was our primary tool for about five years. After migrating the cluster to new servers it became obvious: screen drops sessions on SSH disconnect when hardstatus isn’t configured, and screen -r recovery sometimes hits a race condition when multiple admins connect simultaneously. tmux solves both problems out of the box — sessions live in server memory, are bound to a socket, and reconnection doesn’t depend on the TCP connection state.

The migration took half a day: we set up a shared config, distributed keybindings, and validated on staging. We went to production a week later — after tmux survived two incidents where screen would have lost context.

Key Differences from GNU Screen

The main difference is architectural. tmux uses a client-server model with a separate server process per session. Screen is also client-server, but its session is bound to the terminal less reliably and is lost more often on disconnect.

Another thing — tmux has a proper copy-mode. In Screen you had to fight with text selection through escape sequences. In tmux, Ctrl+B [ drops you into scrollback with search.

When to Use tmux, When Not To

tmux makes sense when:

• multiple admins work on the same server simultaneously;
• sessions are long-running (monitoring, deploys, debugging);
• you need reliable copy-mode and scrollback;
• automation through the tmux CLI (CI/CD scripts that send commands into a session).

tmux is not needed when:

• one admin per server, short sessions;
• memory-constrained systems — a tmux server consumes more RAM than screen (though on modern machines this is negligible);
• you’re in a containerized environment with an ephemeral filesystem — the tmux config won’t survive container recreation without a volume.

Production Commands

The default prefix is Ctrl+B. All commands follow it.

Creating and attaching:

tmux new -s prod-db
tmux attach -t prod-db
tmux list-sessions

Managing windows and panes:

Ctrl+B c          # new window
Ctrl+B &          # kill window
Ctrl+B %          # split vertically
Ctrl+B "          # split horizontally
Ctrl+B o          # switch between panes
Ctrl+B z          # toggle fullscreen for current pane

Working with copy:

Ctrl+B [          # enter copy-mode
Space             # start selection
Enter             # copy
Ctrl+B ]          # paste clipboard buffer

Scripted invocation (for automation):

tmux send-keys -t prod-db "systemctl restart api" C-m
tmux split-window -t prod-db -h "tail -f /var/log/api.log"

Session persistence across reboot:

Minimal ~/.tmux.conf for production:

set -g default-terminal "screen-256color"
set -g base-index 1
set -g pane-base-index 1
set -g allow-rename off
set -g set-titles on
set -g set-titles-string "#S:#I.#P #W"
set -g status-keys vi
set -g mouse on
bind -n M-1 select-pane -t 0
bind -n M-2 select-pane -t 1
bind -n M-3 select-pane -t 2

After editing the config: tmux source-file ~/.tmux.conf.

Bottom Line

tmux replaced Screen on production not because it’s “newer,” but because its sessions don’t get lost on disconnect, copy works without workarounds, and CLI scripting gives predictability for automation. The trade-off is slightly higher memory usage and the need to maintain a single config across all servers. For our stack of 12 production servers with three admins each, it paid off in the first week. The task is to write an English IT blog post for “Lead DevOps” blog, parallel to the Russian draft provided. The English version should be the original article (not a word-for-word translation), same structure and facts, practical tone, same commands and tables.

Key constraints: