tmux can keep your terminal sessions alive even if your SSH connection drops.
Here’s a quick demo of what that looks like. Imagine you’re editing a file in vim over SSH, and your laptop battery dies. Normally, vim would crash, and you’d lose your work. But if you were using tmux, when you reconnect and SSH back into the server, you’ll find your vim session exactly as you left it, with all your unsaved changes.
# On your local machine:
ssh user@your_server_ip
# Once logged into the server:
tmux new-session -s my_editing_session
# Now, inside tmux, start vim:
vim my_important_file.txt
# To detach from the tmux session (leaving it running):
# Press Ctrl+b, then press d
# Now, simulate a disconnect. You can close your SSH terminal.
# After some time, reconnect to the server:
ssh user@your_server_ip
# Once logged back in, reattach to your running tmux session:
tmux attach-session -t my_editing_session
You’ll see your vim session, with my_important_file.txt open and ready to go.
The core problem tmux solves here is session management. When you SSH into a server, you’re essentially renting a terminal process on that server. If your connection breaks, that process usually gets terminated. tmux acts as a meta-session manager on the server. It creates its own persistent sessions, and your individual terminal programs (like vim, htop, or even another SSH client) run inside these tmux sessions. When your SSH connection drops, the tmux session and everything running within it keeps going on the server. When you reconnect, you simply attach to that still-running tmux session.
The key commands are tmux new-session to start a new session, tmux attach-session to reconnect to a running one, and tmux ls to see what sessions are currently active. You can name your sessions for easier management, like tmux new-session -s dev_work. Detaching is crucial; it’s usually Ctrl+b followed by d. Reattaching is tmux attach-session -t <session_name>.
The tmux server process itself runs on the remote machine, independent of your SSH connection. Your SSH connection is just the client that allows you to interact with either the tmux server directly (to manage sessions) or with a tmux session itself. Each tmux session can host multiple "windows" (like tabs) and "panes" (split views within a window), all of which are preserved across disconnects.
A common misconception is that tmux makes your SSH connection persistent. It doesn’t. It makes the processes running within tmux persistent. You still need a reliable way to re-establish your SSH connection to the server. Tools like autossh can help with keeping the underlying SSH tunnel alive, but tmux is the component that ensures your applications within that tunnel don’t die when the tunnel momentarily breaks.
The tmux server itself is a single process on the server. If that tmux server process crashes or is killed, all sessions managed by it will be terminated. This is rare but can happen during server reboots or if the tmux process itself encounters a fatal error.
When you’re inside a tmux session, commands like Ctrl+b are your tmux prefix. You press the prefix, release it, and then press another key to issue a tmux command. For example, Ctrl+b c creates a new window, and Ctrl+b n moves to the next window. To kill a window, you’d typically exit the program running in it (like typing :q! in vim) and then use Ctrl+b x to confirm killing the window.
The ultimate goal is to have your remote development environment feel as resilient as your local one, where closing your laptop lid doesn’t usually mean losing your work. tmux gets you most of the way there for terminal-based applications.
The next hurdle is often managing multiple tmux sessions and windows efficiently, especially when you have many projects open simultaneously.