Real-World Workflows

The keys and commands are the same for everyone. What changes is how you arrange them. This page shows six setups that people use every day, each with the exact commands to build it. Copy the one closest to your work and adjust it.

Working toward a specific result? Follow a complete task guide:

• Copy and paste locally or over SSH — verify a tmux buffer and your system clipboard separately.
• Keep work running over SSH — detach, reconnect, and check that your remote process survived.
• Build a development workspace — organize editor, tests, and logs without duplicating windows on repeat runs.

The basic pattern

Almost every workflow follows the same three rules:

1. One session per project. Name it after the project, so tmux attach -t api always brings back the same work.
2. One window per job. For example editor, server, tests, and logs. Name windows with Ctrl+b , so the status line tells you what each one is for.
3. Split only when you need to see two things at once. A server next to its logs is a good split. Five tiny panes usually are not; use windows instead and jump with Ctrl+b and a number.

Web development: editor, server, and tests

The goal: your editor in one window, and a second window where the dev server runs on the left and the tests watch for changes on the right.

tmux new -d -s web -c ~/code/web -n editor
tmux send-keys -t web:editor 'nvim .' Enter
 
tmux new-window -t web: -n run -c ~/code/web
tmux send-keys -t web:run 'npm run dev' Enter
tmux split-window -h -t web:run -c ~/code/web
tmux send-keys -t web:run 'npm test -- --watch' Enter
 
tmux select-window -t web:editor
tmux attach -t web

Day to day, Ctrl+b 0 and Ctrl+b 1 flip between the editor and the running code, and Ctrl+b z zooms the test pane when a failure needs more room. Because the server lives inside tmux, closing your terminal by accident doesn't stop it.

Save these lines as a script, for example ~/bin/web, and the whole workspace comes back with one command. The development workspace guide shows a version that is safe to run again when the session already exists.

Running jobs on a remote server

The goal: start a long command on a server over SSH and be sure it keeps running if your connection drops or you close your laptop.

ssh you@server
tmux new -A -s work        # attach to "work", or create it
./deploy.sh                # or a migration, backup, build...
# Ctrl+b d to detach, then log out

Later, from anywhere:

ssh you@server
tmux attach -t work

tmux new -A -s work is worth turning into a habit, because it never creates a second session by mistake. Run tmux on the server, not on your own computer, so the session lives where the job runs. The SSH guide covers checking that the process really survived.

Managing several servers at once

The goal: run the same command on four servers and watch the results side by side.

tmux new -d -s fleet
tmux send-keys -t fleet 'ssh web1' Enter
tmux split-window -t fleet 'ssh web2'
tmux split-window -t fleet 'ssh web3'
tmux split-window -t fleet 'ssh web4'
tmux select-layout -t fleet tiled
tmux attach -t fleet

Once you are logged in everywhere, press Ctrl+b : and run setw synchronize-panes on. Now everything you type goes to all four panes, so one sudo apt update updates every server. Turn it off with setw synchronize-panes off before typing anything server-specific.

The first server is opened with send-keys, so its pane keeps a normal shell after you log out. The others are opened as the pane's command, so each of those panes closes when its SSH session ends. Both styles are useful; pick whichever suits you.

Long-running data jobs

The goal: train a model or run a big data job on a remote machine, check on it from time to time, and keep a record of its output.

tmux new -d -s train -n job 'python train.py 2>&1 | tee train.log'
tmux new-window -t train: -n gpu 'watch -n 5 nvidia-smi'
tmux attach -t train

The first window runs the job and also writes everything to train.log, so the output is safe even if the window closes. The second window shows GPU use every five seconds. Detach with Ctrl+b d and come back with tmux attach -t train.

A few habits help with long jobs:

• Raise history-limit in your config (the default is 2000 lines) so you can scroll back through more output, or rely on the log file.
• tmux capture-pane -p -S - -t train:job > snapshot.txt saves everything the pane still remembers.
• A reboot ends tmux sessions. For jobs that must survive restarts, use a job scheduler or a system service instead.

Watching logs

The goal: follow several log files at once while keeping a shell free for commands.

tmux new -d -s logs -n tail 'tail -F /var/log/app/api.log'
tmux split-window -v -t logs:tail 'tail -F /var/log/app/worker.log'
tmux split-window -h -t logs:tail
tmux attach -t logs

Press Ctrl+b [ in any log pane to stop scrolling and search with / (vi keys) or Ctrl+s (emacs keys); press q to follow the live output again. To keep a copy of everything the first log pane prints from now on, run tmux pipe-pane -o -t logs:tail.0 'cat >> ~/pane.log' from the free shell. Running the same command again stops the logging.

Pair programming

The goal: two people working in the same terminal, either seeing exactly the same thing or looking at different windows of the same project.

# Same view, same cursor: both people attach to one session
tmux new -s pair
tmux attach -t pair            # run by the second person
 
# Different views of the same windows: a session group
tmux new -s alice
tmux new -s bob -t alice       # run by the second person

For a demo or code review, the viewer can attach read-only with tmux attach -t pair -r. When the other person logs in as a different user on the machine, you also need a shared socket and server-access, covered in advanced features.

Saving and restoring your setup

tmux sessions don't survive a reboot, so it helps to be able to rebuild them quickly. There are three common approaches:

• A shell script, like the ones on this page. It is plain tmux commands, easy to read, and needs nothing extra installed.
• A session manager such as tmuxinator or tmuxp. You describe windows and panes in a YAML file, and one command builds the session.
• Plugins such as tmux-resurrect and tmux-continuum, which save your windows, panes, and working directories and can restore them after a restart. See the plugin directory.

More ideas

• IDE layout — Vim or Neovim on the left (about 80 percent) and a terminal or test runner on the right. tmux split-window -h -l 20% creates that right-hand pane.
• Context switching — one session for "Backend" and one for "Frontend"; switch instantly with Ctrl+b s.
• TDD loop — map a key in your editor that runs tmux send-keys -t tests 'npm test' Enter, so tests run in the next pane without leaving the editor.
• Production support — keep a persistent session on a jump host so you can reach production without logging in again each time.
• Remote visualization — run an SSH tunnel in one window while you watch TensorBoard or a dashboard in another.