Chapter 8: Build a Real Tmux Workflow

So far, you have learned the individual building blocks of tmux.

You know how to create sessions, organize work with windows, split windows into panes, move between panes, resize them, and use copy mode to work with terminal output.

But knowing these features separately is different from actually using tmux. So in this chapter, we're going to put everything together. Instead of learning another set of commands, we're going to build a real tmux workspace from scratch.

Imagine you're working on an application running on a remote Linux server. You need to start the application, watch its logs, run commands, and keep an eye on the system.

By the end of this chapter, you'll have a workflow you can adapt to your own work.

The Workflow We're Going to Build

Let's start by deciding what we need. For this example, we'll use one session called:

my-api

Inside that session, we'll have three windows:

my-api
│
├── app
├── logs
└── system

The idea is simple:

• app: run application commands
• logs: watch application output
• system: monitor the server and run diagnostics

We can also split the app window into panes when we need multiple things visible at the same time.

Our final workspace will look roughly like this:

Session: my-api

Window 0: app
┌──────────────────────────┬────────────────────┐
│                          │                    │
│      application         │      commands      │
│                          │                    │
└──────────────────────────┴────────────────────┘

Window 1: logs
┌─────────────────────────────────────────────────┐
│                                                 │
│              application logs                   │
│                                                 │
└─────────────────────────────────────────────────┘

Window 2: system
┌──────────────────────────┬────────────────────┐
│                          │                    │
│       monitoring         │     diagnostics    │
│                          │                    │
└──────────────────────────┴────────────────────┘

Don't worry about building this perfectly on the first attempt. The goal is to understand how you decide what belongs in a session, window, or pane.

Step 1: Create the Session

Start from your normal terminal. Create a named session:

tmux new -s my-api

You're now inside the my-api session. This session represents the entire application context. If you're working remotely, you can think of it as:

Server
  │
  └── my-api session

Everything we create next will belong to this session.

Step 2: Create the Windows

Your first window already exists. Let's use it for the application.

Rename it:

Ctrl+b ,

Enter:

app

Now create another window:

Ctrl+b c

Rename it:

Ctrl+b ,

and call it:

logs

Create one more:

Ctrl+b c

Rename it:

Ctrl+b ,

and enter:

system

You should now have:

0:app
1:logs
2:system

in your tmux status bar.

Step 3: Set Up the Application Window

Move back to window 0:

Ctrl+b 1

Now let's create two panes. Split the window:

Ctrl+b %

You now have two panes side by side. Use one for the application and the other for commands. For example, you might run:

./start-app.sh

in one pane. And leave the other available for commands such as:

git status

or:

curl http://localhost:8080/health

The exact commands will depend on your project. The important part is the workflow.

app window

┌────────────────────────┬─────────────────────┐
│                        │                     │
│      Application       │      Commands       │
│                        │                     │
└────────────────────────┴─────────────────────┘

Now you don't need to keep switching between two terminals just to see your application and run a command.

Step 4: Set Up the Logs Window

Move to the logs window:

Ctrl+b 2

Now imagine your application writes to:

application.log

You might run:

tail -f application.log

The terminal will continuously display new log entries. This window now has one clear purpose: Watch what's happening inside the application.

If an error occurs, you can immediately see it without interrupting the application window. For a real project, you might instead use commands such as:

journalctl -f

or whatever logging tool your application uses. The exact command isn't the point here. The important idea is that the window has a dedicated responsibility.

Step 5: Set Up the System Window

Now move to:

Ctrl+b 3

This window can be used for system monitoring. Split it:

Ctrl+b %

In one pane, you could run:

top

and use the other pane for diagnostic commands:

df -h

or:

free -h

Now your workspace has three distinct areas:

my-api
│
├── app
│    ├── application
│    └── commands
│
├── logs
│    └── application logs
│
└── system
     ├── monitoring
     └── diagnostics

This is a much more useful setup than simply opening six unrelated terminal windows.

Step 6: Move Around the Workspace

Now practice navigating. Jump directly to your windows:

Ctrl+b 1
Ctrl+b 2
Ctrl+b 3

Move between panes:

Ctrl+b ←
Ctrl+b →
Ctrl+b ↑
Ctrl+b ↓

You can now move from:

application
   ↓
logs
   ↓
monitoring

without opening another terminal. This is where the session → window → pane model starts becoming natural.

Step 7: Deal With a Large Log Output

Now imagine something goes wrong. Your logs contain a large amount of output and you need to find an error. Move to the logs window:

Ctrl+b 1

Enter copy mode:

Ctrl+b [

Search for:

/

Then enter something like:

ERROR

You can now inspect the matching output. This is where the things you learned in Chapter 7 become part of the workflow rather than isolated commands.

You are using:

Window → Logs
      ↓
Copy Mode
      ↓
Search
      ↓
Inspect error

Step 8: What If You Need to Leave Without Disconnecting?

You don't always need to wait for your SSH connection to disappear. You can safely leave your tmux workspace whenever you want. Press:

Ctrl+b d

The session continues running. Later:

tmux attach -t my-api

You're back. This is the workflow you will eventually use almost automatically when working on remote servers:

SSH
 ↓
Attach/Create tmux
 ↓
Work
 ↓
Detach
 ↓
Leave server
 ↓
Return later
 ↓
Attach
 ↓
Continue

You know how to create the workspace, organize it, work inside it, leave it running, and come back later. That's already enough to make tmux useful in everyday work.

But there is one final step. Once you've used tmux for a while, you'll probably notice small things you'd like to change.

Maybe you want mouse support. Maybe you prefer a different prefix key. Maybe you want a custom shortcut. That's where configuration comes in.

In the final chapter, we'll create your first .tmux.conf and make a few practical customizations without turning tmux into a complicated configuration project.