Learn Tmux - Remote Development & SSH Workflow

#Introduction

In episode 17 we built the skills of writing your own scripts, lightweight status widgets, and modular configs with source-file. All of that prepared you for the most defining scenario: working on remote machines. This is where tmux proves its reason for existing.

Every engineer who has managed a production server knows the feeling: mid-database-migration, the office Wifi dies, and all the work dies with it. Without protection, a dropped SSH connection sends SIGHUP to the processes inside it, and those processes — dev server, migration, backup — die along with the connection. tmux breaks that chain: processes run inside a tmux server living on the remote machine, not inside your SSH connection.

In this episode we cover four pillars of mature remote work: attach/detach workflows, mosh for unstable networks, jump hosts via bastion, and nested tmux techniques when the server also runs tmux. All examples refer to tmux 3.7b as the latest stable version.

#The Problem tmux Solves on Remote Connections

A simple analogy: working directly over an SSH connection is like writing on a whiteboard — once the board is carried away, the writing is gone. Working inside tmux is like writing in a workshop: the whiteboard (tmux server) stays in place, and you only borrow a window to look at it. When the window (client) closes, the workshop doesn't disappear with it.

Technically, the tmux server is a daemon process running on the machine where the session lives. The client — the terminal you see — is only a window into that server. Because the work happens on the server, disconnecting the client doesn't affect the processes inside the panes. This is why experienced SysAdmins almost always make tmux the first tool installed on production servers.

#Attach/Detach Workflow on Remote Servers

The basic pattern of remote work with tmux is very simple: create a session on first entry, detach before closing the connection, and re-attach whenever needed. Here's the full flow in two different moments:

ssh deploy@prod-01
tmux attach -t web || tmux new -s web

ssh deploy@prod-01
tmux attach -t web

The line tmux attach -t web || tmux new -s web is the attach-or-create idiom: if the web session already exists, you attach to it; if not, a new session is created. With this idiom, you don't need to memorize the session state before entering — the same command is always safe to run.

When you're done or the connection starts getting unstable, press prefix + d to detach. The panes, windows, and processes inside them keep running on the server. You can close the terminal, sleep overnight, then come back and run tmux attach -t web — everything is exactly where you left it. To see the list of still-alive sessions without attaching, use tmux ls.

#mosh for Slow Connections

SSH works with full latency: every keystroke waits for a reply from the server, so on slow networks it feels like typing in mud. mosh (mobile shell) solves this with a different concept: mosh runs its own client and server, provides local echo so typing feels instant, and keeps the connection alive when the IP changes — e.g. when moving from office Wifi to phone tethering.

Install mosh di Ubuntu/DebianInstall mosh di macOS

sudo apt install mosh

brew install mosh

Using it is nearly identical to SSH:

mosh deploy@prod-01
tmux attach -t web || tmux new -s web

It's important to understand: mosh and tmux are not competitors, they're partners. mosh keeps the connection responsive and resilient to network changes, while tmux keeps the work alive even when the connection is lost entirely. Inside stable mosh, tmux still functions as the last layer of safety.

#Jump Hosts and Bastion with Tmux

In real infrastructure, application servers usually can't be accessed directly from the internet — you must go through a bastion first. Modern OpenSSH simplifies this with ProxyJump, without needing to install any extra tool on the local machine:

Host bastion
  HostName bastion.example.com
  User admin
 
Host app-01
  HostName 10.0.0.11
  User deploy
  ProxyJump bastion

With the config above, ssh app-01 automatically hops through bastion with no manual step. Now notice tmux's role at this layer: many teams choose to run tmux on the bastion itself, so every work session that moves between target servers stays in one consistent context. A session on the bastion becomes a sort of shared, persistent workspace, no matter how many times connections come and go.

#Remote Development Patterns

#Dev server in a detached session

When a dev server must keep running remotely — e.g. on a shared development machine — create a detached session then attach when you need to see output:

ssh deploy@prod-01
tmux new -d -s api 'npm run dev'
tmux attach -t api

The -d flag means the session is created without attaching a client. The dev server runs in the background right away, and you can attach anytime to see logs without disturbing the process.

#Tailing logs with a dedicated window

Monitoring error logs live is a SysAdmin's daily work. Instead of opening files repeatedly, bind the tail process inside a session:

Tail log di window khusus

tmux new -s log 'tail -f /var/log/app/error.log'

Because the tail command runs inside a pane, tmux's scrollback stores the entire log history — you can scroll back, search for patterns, even copy error lines straight to the clipboard, far beyond the limits of tail -f in a plain shell.

#Long-running jobs that aren't afraid of dropped connections

Database migrations, large backups, or rsync of huge amounts of data are examples of jobs most vulnerable to dying when the connection drops. With tmux, these jobs become safe:

tmux new -d -s backup 'pg_dump app > backup.sql'
tmux attach -t backup

If the connection drops mid-job, tmux attach -t backup upon return will show the still-running output at its last position — not a single byte lost.

#Nested Tmux: Tmux Inside Tmux

The most challenging scenario arises when you're already running tmux on the local machine, then SSH into a server that also runs tmux. Now there are two layers claiming the same prefix. Pressing C-b gets swallowed by the outermost layer, making it hard to control the inner tmux.

The solution is giving each layer a different prefix. The most common approach: let the local machine keep C-b, and remap tmux on the server to C-a.

set -g prefix C-a
unbind C-b
bind C-a send-prefix

set -g prefix C-b
bind C-b send-prefix

In the server config, set -g prefix C-a changes the prefix, unbind C-b frees C-b so it doesn't compete, and bind C-a send-prefix makes pressing C-a twice send the prefix to the deeper layer. Meanwhile, the local machine keeps C-b and bind C-b send-prefix — this is actually already tmux's default, but writing it explicitly makes the config easier to read.

Here's the complete map:

#Common Pitfalls

1. Running long jobs without tmux. Migrations or backups run directly in the shell die with the connection because of SIGHUP. Make it a rule: any job longer than a few minutes always goes into a tmux session.
2. Thinking detach means killing processes. Detach doesn't stop anything — quite the opposite, processes keep running. Get used to checking tmux ls and cleaning up unused sessions so the server doesn't accumulate resources.
3. Nested tmux without a prefix remap. Controlling tmux inside tmux without a prefix difference leads to commands hitting the wrong layer, including accidental detaches. Remap C-a on the server or master the send-prefix trick.
4. Expecting mosh to work on infrastructure that only opens TCP 22. mosh needs UDP ports 60000-61000. If the firewall doesn't allow it, mosh fails to connect — fall back to SSH and let tmux protect the session.
5. Attaching without checking who's already connected. Shared sessions are read-write by default; attaching without -r means you're also typing on someone else's screen. Check with tmux list-clients — we'll go deeper on this in episode 19.
6. Forgetting that windows close when their process finishes. If you want a pane to stay open after a command completes — e.g. to read output — enable set -g remain-on-exit on so the window doesn't vanish immediately.

#Conclusion

This episode placed tmux in the most important position in an engineering career: protector of remote work. You understand why a dropped SSH connection no longer means dead work, master the attach-or-create idiom, know when and why to use mosh for slow networks, can traverse a bastion with ProxyJump while keeping your work context inside tmux, and can handle nested tmux with a clean prefix remap.

Key points to take away:

• tmux attach -t web || tmux new -s web is a safe pattern you can run anytime.
• mosh keeps the connection, tmux keeps the work — they complement each other, not compete.
• A bastion deserves tmux for a consistent work context, but never store secrets there.
• Nested tmux is conquered with a different prefix at each layer.

Now you can manage one server with peace of mind. In episode 19 we'll cover multi-server and shared sessions — broadcasting commands to many servers at once, pair programming with shared sessions, and managing permissions including read-only attach. See you in episode 19!