tmux: The Terminal Multiplexer That Runs Your Business While You Sleep

Most people describe tmux as a way to split your terminal into panes. That undersells it by about 90%. tmux is a session manager, a process supervisor, and a deployment tool disguised as a terminal multiplexer.

If you run anything in a terminal that needs to survive closing your laptop lid, tmux is how you do it.

What tmux Actually Is

tmux creates persistent terminal sessions that live independently of your connection to them. You start a session, run a process inside it, detach, close your laptop, fly across the country, open your laptop, reattach. The process never stopped.

That sounds simple. The implications are not.

A solo builder running services on a Mac Mini at home needs those services to keep running when the SSH connection drops. A long data migration can't die because your Wi-Fi flickered. A deployment script that takes 40 minutes shouldn't require you to babysit a terminal window for 40 minutes.

tmux solves all of these with the same primitive: a session that persists regardless of whether anyone is watching it.

The Commands That Matter

tmux has dozens of commands. You need about six of them.

Create a named session:

tmux new-session -d -s deploy

The -d flag starts it detached. The -s flag gives it a name. Named sessions are how you keep track of what's running — deploy, backup, ghost-blog, whatever makes sense for the process inside.

List running sessions:

tmux ls

This tells you what's alive. On a typical day, I have 8-15 sessions running. Some are services. Some are long-running scripts. Some are monitoring loops.

Attach to a session:

tmux attach -t deploy

You're back in that terminal, seeing everything the process has printed since you left. The scrollback is intact. The working directory is where you left it.

Detach from inside a session: Ctrl-b d. The session keeps running. You go back to your main terminal.

Send a command to a session without attaching:

tmux send-keys -t deploy "cd /opt/app && git pull && npm run build" Enter

This is where tmux stops being a terminal tool and starts being an automation framework. send-keys lets you inject keystrokes into any running session from the outside. You can script deployments, restart services, trigger builds — all without attaching to the session or writing a proper daemon.

Kill a session when you're done:

tmux kill-session -t deploy

That's it. Six commands cover 95% of daily use.

Named Sessions as Process Management

Here's the pattern that changed how I manage services: every long-running process gets its own named tmux session.

tmux new-session -d -s ghost "cd ~/sites/ghost && docker compose up"
tmux new-session -d -s tunnel "cloudflared tunnel run my-tunnel"
tmux new-session -d -s backup "~/scripts/backup-loop.sh"
tmux new-session -d -s monitor "htop"

Now tmux ls gives you a process table:

backup: 1 windows (created Mon Mar 16 08:30:12 2026)
ghost: 1 windows (created Mon Mar 16 08:30:10 2026)
monitor: 1 windows (created Mon Mar 16 08:30:15 2026)
tunnel: 1 windows (created Mon Mar 16 08:30:11 2026)

This is not systemd. It's not a proper process supervisor. It's better than both for a solo builder, because there's zero configuration overhead. No unit files. No YAML manifests. A process that runs in a terminal runs in tmux. The mental model is the same — you're typing the same commands you'd type interactively. The only difference is they keep running.

Compare this to the alternative. You could write a systemd unit file for each service, learn the unit file syntax, debug the environment variables that don't carry over from your shell profile, figure out why your Node app can't find its config file when started by systemd. Or you could type the same command you already know works, prefix it with tmux new-session -d -s, and move on with your day.

Want to check if your tunnel is healthy? tmux attach -t tunnel, look at the output, Ctrl-b d to leave it alone. The whole interaction takes three seconds.

send-keys: The Automation Nobody Talks About

tmux send-keys is the single most underrated command in the solo builder toolkit.

Consider a deployment workflow. You have a session running your application. You want to deploy a new version. Instead of attaching, manually stopping the process, pulling changes, rebuilding, and restarting, you script it:

#!/bin/bash
tmux send-keys -t app C-c
sleep 2
tmux send-keys -t app "git pull origin main" Enter
sleep 5
tmux send-keys -t app "npm run build && npm start" Enter

That's a deploy script. No CI/CD pipeline. No GitHub Actions YAML. No webhook server. A bash script that talks to a tmux session. It takes 30 seconds to write and handles deploys for a solo project that serves a few hundred users without any infrastructure beyond the Mac you already own.

This scales further than you'd expect. I run automation that dispatches work into tmux sessions, monitors their output, and collects results — all through send-keys and capture-pane. The sessions become execution slots, and the orchestrator is a shell script that doesn't care what's running inside them.

tmux capture-pane -t deploy -p | tail -5

That captures the visible output of a session without attaching to it. Pipe it through grep, check for error strings, trigger alerts. Monitoring built from two commands and a cron job.

The compound effect is that tmux becomes a control plane. You have named execution contexts that you can inspect, command, and monitor programmatically. Each session is an isolated environment with its own working directory, environment variables, and scrollback history. That's not a terminal splitter. That's lightweight infrastructure.

Surviving Disconnects

The original use case for tmux is SSH resilience, and it's still the most important one for anyone running a home server.

Without tmux, an SSH disconnect kills every process you started in that shell. Your database migration stops mid-transaction. Your Docker build loses progress. Your log tail vanishes.

With tmux, you SSH in, attach to the session you left yesterday, and everything is exactly where it was. This isn't a minor convenience. It's the difference between being able to leave your desk and being tethered to a terminal.

For solo builders running infrastructure on a Mac Mini or a VPS, tmux means you can start a process, close your laptop, go to bed, and check on it in the morning. The process doesn't know or care that you disconnected. It kept running inside its tmux session the entire time.

I've had tmux sessions survive network outages, ISP maintenance windows, and accidental router reboots. As long as the machine itself stays powered on, the sessions are there when the connection comes back.

The Gotcha

tmux sessions survive disconnects. They do not survive reboots.

When your machine restarts — whether intentionally or because of a power outage — every tmux session is gone. Every process that was running inside them is gone. There's no built-in persistence across reboots.

The solutions range from simple to elaborate:

• A startup script: A bash script in your login items or cron @reboot that recreates your standard sessions. Mine is ~20 lines and brings up the 5 sessions I always want running.
• tmux-resurrect: A plugin that saves and restores session layouts. It captures which sessions exist, what panes are open, and what directories they're in. It does not restore running processes — it restores the environment so you can restart them.
• systemd or launchd for critical services: If a process genuinely can't have any downtime, it shouldn't be in tmux. Use a proper service manager. tmux is for processes where "restart after reboot" is acceptable. For most solo builder workloads, it is.

The other gotcha: scrollback. tmux's default scrollback buffer is 2,000 lines. A verbose build process can blow through that in seconds. Set it higher in your tmux config:

set-option -g history-limit 50000

Put that in ~/.tmux.conf and you'll stop losing output.

tmux vs screen vs nohup

screen still works. It's been around since 1987 and it handles the basics — persistent sessions and reattachment. But it hasn't kept up with modern terminal workflows. Vertical-only pane splitting, a less scriptable interface, and no active development make it the legacy option.

nohup is the minimalist choice. nohup ./my-script.sh & detaches a process from your terminal. But you can't reattach. You can't see the output interactively. You can't send it input. For fire-and-forget tasks where you genuinely don't need to check on the process, nohup works. For everything else, tmux.

Installation and Setup

brew install tmux

That's the install. There's no daemon to start, no service to configure. Run tmux and you're in a session.

The minimal config worth adding to ~/.tmux.conf:

# Increase scrollback
set-option -g history-limit 50000

# Start window numbering at 1 instead of 0
set-option -g base-index 1

# Enable mouse support (scrolling, pane selection)
set-option -g mouse on

Reload the config without restarting:

tmux source-file ~/.tmux.conf

Skip the elaborate themes, status bars, and plugin managers that dominate most tmux tutorials. They're optimizing for aesthetics in a tool whose value is operational. Get the scrollback right, learn the six commands, and start using it.

The Bigger Picture

tmux fits a pattern that keeps showing up in the solo builder stack: tools that are infrastructure-grade but configuration-light. No monthly fee. No vendor dashboard. No 200-page docs you need to read before you're productive. One install command, six operations to memorize, and you have persistent process management that works on any Unix machine for the rest of your career.

The gap between "I run some scripts on my laptop" and "I run production services on hardware I own" is smaller than most people think. tmux is one of the things that closes it.