Connecting me to a distant machine takes three layers of thread.
A private network, a window, and a net. How to weave the three together.

The First Thread—Into the Same Room

NETWORK · 2026

To connect to a distant machine, first make it and your tablet behave as if they were in the same room. A private network fills this role; my tool is Tailscale. It quietly links only my own devices in different locations, making them seem to share one space.

Let us clear up one misunderstanding. This differs from the familiar VPN that hides your location by routing all communications through somebody else’s server. With this private network, only traffic between my devices follows that line. Everyday traffic such as Safari, messaging, and YouTube follows its usual route. Everyday apps therefore do not slow down or behave strangely. The thread is thin and links only what it needs to.

The only thing worth watching is a few financial apps that dislike the VPN indicator. Some apps block themselves merely upon detecting “VPN on,” whether traffic is actually being rerouted or not. Simply turn it off briefly while banking.

The Second Thread—A Window for Commands

ACCESS · 2026

Once the two machines are in the same room, you need a window through which to speak into it. A program that opens the distant machine’s command line on the tablet: that is the window, and I use Termius. The connection flowing through that window is called SSH, an encrypted passage others cannot peer into. Type a command through the window, and it runs on the machine across the room.

There are many windows; use whichever you like. But a window must satisfy one condition: it must be a safe passage. It must use an encrypted connection others cannot peer into. Opening and closing that connection with a key is safer and more convenient than typing a password every time. Plant the key on your machine and put the lock on the other side.

Each window has its own habits. Some display on-screen addresses with strange truncations; others fail to pass Korean input properly. These habits trip beginners most often. That is covered in the later troubleshooting installment.

The Third Thread—A Net That Survives Disconnection

PERSISTENCE · 2026

A window alone is not enough. Windows are fragile. Enter the subway and lose signal, let the tablet sleep, or change networks, and the window closes. What if the work running through it dies at the same instant? Start a long build and board the subway, and one stop later you must begin again.

That is why there is a third thread. Stretch a net between the window and the work. Its name is tmux. The work hangs from the net, not the window. Even when the window closes, the net remains inside the distant machine, holding the work and keeping it running. Connect again and simply “reattach” to the net; the place where you were working returns unchanged.

This is the reassurance device of remote development. Thanks to this tmux net, I have experienced many disconnections without losing my work once. Only the window disconnects; the net does not sleep inside the machine. Like the resident system, the net stays awake.

The Emergency Passage—One Is Not Enough

REDUNDANCY · 2026

The three threads above—Tailscale, Termius, and tmux—actually form one kind of route: the command line, exchanging instructions as text. I keep another route with a different character: a remote-access program that displays the distant machine’s entire screen on the tablet.

Honestly, this screen route is slow, and its touch controls are awkward. If the command line is a nimble bicycle, this is a lumbering truck. I install it anyway for one reason: work stopping because one channel breaks is itself an infrastructure failure.

The many developers who divide deployment into development, internal, and production stages, duplicate their databases, and ponder how many spare images to run in the cloud are not performing digital feats of strength out of boredom. They want the whole system to keep moving when one part dies. The same applies here. With only one passage, all work stops the instant it breaks.

My concern follows the same line. The day the command line is blocked will come; it simply has not happened today. If the screen route is alive that day, even as a lumbering truck, work continues. That is why I keep a backup passage. Those who understand remote work dig a second road while the first is still open.