## I woke up this morning with one goal: stop starting over.

Every time I have to break a connection to my remote servers—for any reason—I typically have to start whatever I was doing from the very beginning again. The newest machine making up my server farm is roughly 9 years old. The oldest machine is 23 years old. But they are not in a landfill somewhere. They have provided an excellent, hands-on training ground for me.

My philosophy is simple: **BUILD A LAB.** Invest in yourself before you ask someone else to make that investment in you. Years of experience is what employers are seeking, unfortunately they are also looking for pieces of paper that say you did something, no matter how you did it. Its not what you know, what you can prove, or what you can learn... its about the paper. Experience is not easy to come by because they all want experience in this application or that application, but the average person has no idea how to go about getting it... build a lab, and learn independently... it is a genuine investment in yourself.

Part of that investment is optimizing the workflow. Managing multiple SSH connections to a farm of aging servers can get chaotic, if you forget which window you are in. To bring order to the chaos, I recently started configuring Zellij to manage my multi-host connections right on launch. But in doing so, I had to confront a hard truth about terminal multiplexers: **a beautiful local layout does not save you from a broken remote pipe.**

Here is how I use Zellij for local efficiency, and why I still rely on `screen` on my remote hosts to actually keep my work alive.

## The Local Solution: Zellij for Layout and Launch

Zellij is a phenomenal, modern terminal workspace. Written in Rust, it's fast, looks great out of the box, and doesn't require a PhD to configure.

For my use case, the killer feature is its layout system. My current setup splits my screen into six active panes: five dedicated to remote hosts across my farm, and one local shell. Instead of manually opening a terminal, splitting it, and typing `ssh user@host` six different times, Zellij allows you to define this entire workspace in a simple configuration file.

By creating a custom layout file (e.g., `farm.kdl`), you can tell Zellij exactly how to divide your screen and what commands to run in each pane on startup.

```kdl
layout {
pane split_direction="vertical" {
pane split_direction="horizontal" {
pane command="ssh" { args "admin@node-1" }
pane command="ssh" { args "admin@node-2" }
pane command="ssh" { args "admin@node-3" }
}
pane split_direction="horizontal" {
pane command="ssh" { args "admin@node-4" }
pane command="ssh" { args "admin@node-5" }
pane name="Local Workspace"
}
}
pane size=1 borderless=true {
plugin location="zellij:status-bar"
}
}
```

By launching this with `zellij --layout farm.kdl`, my local machine instantly drops me into a perfectly arranged dashboard connected to my entire lab. It is highly practical, visually clean, and eliminates manually splitting views, or multiple terminal/console sessions.

I haven't played around with every advanced feature yet—mostly sticking to what powers my day-to-day—but I genuinely love it. That said, it isn't perfect. So far, the only thing I am not impressed with is the scrolling. It doesn't scroll quite as smoothly or intuitively as a native terminal. If I need to `cat` a massive log file or scroll through heavy output, I usually just pop open a standard terminal emulator window outside of Zellij to read it. But for command-and-control of the whole farm? It's unbeatable.

## The Catch: Zellij Locally Does Not Equal Persistence Remotely

Here is where the trap lies: **Zellij is running locally.**

It is multiplexing your local terminal emulator. The SSH commands are just processes running inside those local panes. If your local machine goes to sleep, your Wi-Fi blips, or you accidentally close your terminal window, those SSH processes die.

When an SSH process dies, it sends a `SIGHUP` (hangup signal) to the remote server. Any long-running script, update, or network scan you were running on that 23-year-old box is immediately terminated. You are right back to the problem we started with: starting over.

## The Remote Reality: Why `screen` Is Still King

To actually stop starting over, the persistence needs to happen on the remote side. This is why Zellij is not a replacement for GNU `screen` (or `tmux`) on your remote hosts.

While Zellij handles the interface on my local machine, `screen` handles the state on the servers.

When I SSH into a node via my Zellij layout, the very first thing I do is attach to a running screen session (or start a new one):

```bash
screen -x || screen
```

### The Hybrid Workflow

This creates the ultimate bulletproof setup:

- **Zellij (Local):** Dictates the layout, manages the 6-pane view, and automates the initial SSH connections so I have eyes on the whole farm instantly.
- **Screen (Remote):** Wraps the actual work on the remote host.

If my local laptop dies, Zellij goes down, and the SSH pipes break. But on the remote servers, `screen` intercepts the hangup signal. My processes keep churning. When I reboot my laptop and fire up my Zellij layout again, I just type `screen -r` in the panes, and I am exactly where I left off.

## The Takeaway

Building a lab is about learning how systems actually interact. Tools like Zellij are incredible for local productivity and reducing cognitive load, but they don't rewrite the rules of networking.

If you want to stop starting over, use modern tools like Zellij to manage your glass, but rely on battle-tested utilities like `screen` to protect your state. Keep building, keep learning, and keep investing in yourself.