Glossary term

tmux

tmux organises several text-based programs into sessions, windows, and panes, decoupling their lifetime from any one attached terminal. It is useful for interactive work and diagnostics, but it is not a production service manager.

In brief

A terminal multiplexer between the user and running programs

tmux runs on the same machine as the shells and other programs inside its panes. A client displays the selected session in an outer terminal and forwards input to it. tmux is not a shell: a shell interprets commands, whereas tmux manages pseudo-terminals, layouts, and attached clients.

On a remote Linux server, tmux is often paired with SSH. Disconnecting or losing the SSH connection terminates the outer client, but the tmux server and session can continue on the remote machine. That resilience lasts only while the machine and tmux server remain running; it does not preserve processes through an operating-system restart.

What problem it solves

Several programs in one terminal, with a way back to ongoing work

Without a multiplexer, each interactive program is closely tied to a particular terminal connection. tmux inserts its own server between them so that a client can detach and reconnect later, or display several programs at once.

watching an application log alongside service status and message-queue activity
keeping an editor, tests, and a development server in separate windows
returning to a long-running interactive command after a brief SSH interruption
splitting one screen into panes without opening additional terminal windows
deliberately attaching several clients to the same session during a shared investigation

Practical example

Three views of a remote application

A developer connects over SSH and runs new-session with -A to create the support session or attach to it if it already exists. The first pane follows the PHP-FPM log. The default Ctrl-b prefix followed by % splits the window for the worker status; Ctrl-b c creates another window for the queue.

The service names and available Symfony commands are examples and must match the actual project. Ctrl-b d detaches the client without ending the session. Later, tmux attach -t support reconnects to it. The worker itself should still be managed by a service manager or container platform, not by a manually opened pane.

Shell

ssh deploy@app.example.cz
tmux new -As support

# pane 1: follow the log
journalctl -u php8.4-fpm -f

# another pane: watch the worker status
watch -n 5 'systemctl --no-pager --full status app-worker.service'

# another window: check the application queue
cd /srv/app
php bin/console messenger:stats

How it works

A client displays state maintained by the tmux server

Text diagram: terminal or SSH client → tmux client → tmux server → session → windows → panes → shell or another program. Detaching the client breaks the first link, not necessarily the programs managed by the server.

Outer terminal and client The tmux command starts a client that takes over the current terminal, connects to the tmux server through a local socket, and displays one session.
tmux server A process on the machine maintains sessions, windows, and panes, manages pseudo-terminals, and preserves their output independently of any one client. Multiple named sockets can represent separate tmux servers.
Session A named session contains a list of windows and may be attached to one, several, or no clients. Detaching does not turn it into a system service; it merely leaves the session undisplayed.
Window A window is a virtual screen within a session. Users switch between windows, and each window can have its own name, layout, and running programs.
Pane and program A pane is a rectangular area of a window with its own pseudo-terminal. It commonly runs a shell, but it can start an editor, a log command, or another text-based program directly.

Core concepts and controls

Sessions, windows, and panes describe three distinct levels

Using the terms precisely makes it easier to target commands and understand what actually stops when something is closed or detached.

Server and socket

The tmux server normally starts automatically with the first session, and clients communicate with it through a local Unix socket. The default socket directory is protected for a particular user; access to the socket grants control of the corresponding sessions.

Session

A session has a unique name and its own current window. tmux new -As support attaches to the existing support session or creates it. tmux ls lists available sessions.

Window

A window contains one or more panes and usually occupies the entire client area. By default, Ctrl-b c creates a window, while Ctrl-b n and Ctrl-b p move to the next and previous windows.

Pane

Each pane has its own pseudo-terminal and program. By default, Ctrl-b % splits the area left and right, while Ctrl-b " splits it top and bottom. Splitting does not change the nature of the processes inside.

Prefix

The default Ctrl-b tells tmux that the next key is intended for the multiplexer rather than the program in the active pane. Configuration can change the prefix, so team documentation should not assume custom shortcuts without saying so.

Attach and detach

Ctrl-b d detaches the current client. tmux attach -t support reconnects to the session. Detaching does not stop programs unless their pane, window, session, or the entire tmux server ends.

tmux, shell, and terminal

A terminal displays text input and output, a shell interprets commands, and tmux multiplexes several pseudo-terminals into one client. They are nested in ordinary use, but they are not three names for the same thing.

Benefits and limitations

A convenient interactive session is no substitute for operational supervision

Benefits

multiple shells and text-based programs can be organised without additional graphical windows
ongoing work normally continues when the SSH client disconnects or loses its connection
windows and panes make several parts of an investigation visible at once
a named session can be found again and attached from another terminal
controls and layouts can be customised in version-controlled configuration

Limitations and common mistakes

a machine restart, termination of the tmux server, or host policy may end every session and process
tmux provides no restart policy, health check, managed service permissions, or centralised logging
too many long-lived sessions become difficult to navigate and may retain stale environment variables
anyone with access to a session may see its output and control programs, including sensitive commands
a custom prefix and many shortcuts can make unfamiliar hosts or nested tmux sessions harder to use

Practical use

Interactive development and diagnostics—not service lifecycle management

tmux is well suited to work over SSH, local terminal-based development, and short investigations where a log, process status, and diagnostic command are useful side by side. Sessions should have clear names, and completed work should not leave an ownerless session containing sensitive output or unnecessary running programs.

A long-running PHP worker, queue consumer, or web process should run as a managed service or container. Docker can give the process an isolated environment and a platform restart policy, while systemd manages a system service; tmux only supplies interactive terminals. None of these tools alone replaces monitoring and sound application design.

Security and operations

A session is a live workspace with the privileges of its user

Sensitive data may remain in scrollback, shell history, and process environments. Attaching another client is therefore not merely screen sharing—it also grants access to control running programs.

do not share a tmux socket or user account with people who should not have the same privileges
do not expose secrets on the command line, in logs, or in long-lived pane history
confirm the purpose of a shared session before attaching and account for simultaneous input into the active pane
run production services through a service manager or container platform, not a manually detached session
do not expect processes to resume automatically after a restart; tools that restore layouts do not restore application state
end unneeded sessions deliberately and check which programs and windows will be terminated first

Frequently asked questions

tmux for development and server work

Is tmux a shell?

No. tmux manages pseudo-terminals, sessions, windows, and panes. A shell is one program it can run, just like an editor, monitoring tool, or other command.

Does tmux survive an SSH disconnect?

Usually. The SSH connection and tmux client disconnect, while the server and session continue running on the remote machine. This also depends on host policy and on nobody terminating the tmux server or session.

Does tmux survive a complete server restart?

Not by itself. A restart terminates the tmux server and programs in its panes. Plugins can restore parts of the layout or commands, but they do not automatically preserve the actual state of running processes.

When should I use systemd instead of tmux?

Use systemd for long-running production services that need automatic startup, a restart policy, restricted privileges, logging, and supervision. tmux is primarily for interactive work and temporary diagnostics.

Can one tmux session be shared?

Yes. Multiple clients can attach to one session. This should be deliberate because connected users can see its output and, depending on access mode, control the same programs.

How I work in the terminal

I keep interactive diagnostics separate from the persistent application runtime.

I use tmux as an organised workspace on servers while leaving services, workers, and recovery to the operational layer.

Explore my technical expertise Discuss your project

Official tmux Getting Started guide