Terminal multiplexers: how I build this site from my phone

Most of this website was built on an iPhone and an iPad: on the sofa, on the train, wherever I happened to be. The MacBook only came out for UI work, when I wanted a big screen and a real desktop browser to check layouts and details, and for heavy manual edits in the code, where a touch screen gets too fiddly.

That only works because none of these devices does the actual work. Everything runs on a small server, and every device is just a window into the same terminal session. The piece that makes this possible is a terminal multiplexer.

1. What a multiplexer does

A terminal multiplexer keeps your terminals on the server instead of on the device in front of you. In one session you have tabs and panes side by side: the editor in one, the build in another, the tests in a third, the Git history in a fourth.

The key part: the session lives on as long as the server does. When you close the app, lose your connection or switch devices, nothing stops. You connect again and everything is exactly where you left it, including programs that kept running in the meantime and everything they printed.

2. Why it matters in my setup

My development environment is a server that’s only reachable over a private network. My devices don’t hold the projects; they only show them. That brings some very practical benefits:

• Switching devices mid-task. I start a build on the iPad, look at the result on the iPhone, and continue on the MacBook when it’s time for UI details. All three show the same session, not three copies.
• Connections can drop. On a phone, the connection goes away all the time: a tunnel, a lift, switching from Wi-Fi to mobile data, the phone locking. The work on the server doesn’t notice.
• Long-running jobs keep running. Builds, tests and installs run on the server, not on a phone that wants to save battery.
• One environment, not three. Tools, versions and settings exist once, on the server. Nothing has to be kept in sync between devices.
• Nothing to lose on the device. No code and no access tokens live on the phone or tablet. If a device is lost, the work isn’t.

This setup has also shaped how I live. For a long time I travelled a lot, and travelled light. Because the work lives on the server, an iPhone and an iPad were enough to keep working from wherever I was, with nothing to set up again on the road. The MacBook could stay at home, which saved a lot of weight: one normal-sized backpack as hand luggage was more than enough.

3. Before: herdr

Before Rex, I worked with herdr. It was my first multiplexer in this setup, and it’s where the way I work today took shape: panes side by side, sessions that keep running on the server, and coming back to them from wherever I am.

4. Now: Rex

Today I work with Rex. It comes with its own apps for the Mac and for iPhone and iPad, and they connect straight to the server over the private network, without a separate SSH app in between. For a setup that mostly happens on a phone and a tablet, that makes a difference:

• Built for touch. A key bar above the keyboard has the keys a phone keyboard is missing, like the arrows, Escape and Tab, and holding an arrow keeps it repeating.
• Reconnecting is part of the design. When I come back to a tab, it shows its last screen while it reconnects, instead of a blank page.
• The same sessions everywhere. The Mac app and the iPhone and iPad apps show the same sessions, tabs and panes on the same server.
• Who I am comes from the network. On the server, Rex runs as a login server: the private network tells it who is connecting, and it opens the session as my own Linux account. No SSH keys need to be copied onto the phone.
• Nothing open to the internet. Rex is reachable only through the private network, like everything else on the server.

5. When the MacBook comes out

The phone and tablet cover writing code, running builds, reading logs and committing. I switch to the MacBook in two cases:

• UI work. Layouts, spacing, animations and the details of the pixel covers need a big screen and a desktop browser.
• Heavy manual edits in the code. Reworking a long file by hand, moving blocks around or fine-tuning many lines at once gets too fiddly on a touch screen. A real keyboard, a trackpad and precise text selection are simply faster and more accurate there.

The switch itself is no break. The Mac app opens the same session I was just working in on the iPad, with the same tabs, the same history and the build still running. The device changes; the work doesn’t.

The short version

• A terminal multiplexer keeps your terminals, tabs and panes on the server, so they survive closed apps, dropped connections and device changes.
• With a server-based setup, every device becomes a window into one environment: phone, tablet or laptop.
• On a phone or tablet, how the multiplexer connects matters as much as what it can do. That’s why I work with Rex and its own apps.

If you’d like a development environment like this for yourself or your team, get in touch.