Mosh SSH: close your laptop, keep your work running

Why it matters

A laptop is a convenient place to start a build or launch a coding agent. It becomes less convenient when leaving the desk means deciding which processes can be interrupted. Moving execution to another computer gives those tasks a home that can remain available while your laptop sleeps. That computer can be a spare machine in your house.

What interests me in the Syntax discussion is the ability to return to work without rebuilding the workspace every time I change devices. I would judge the setup by its recovery behavior: can I reconnect, see what happened, and continue confidently? A terminal that opens on a phone is useful, but it only answers part of that question.

The practical extension below is a small acceptance test for the workflow. Start with one project, give each tool a specific responsibility, and deliberately interrupt access before trusting the environment with a deadline.

Key points

• 02:19 Closing the laptop becomes practical because execution lives elsewhere. The remote computer still needs power, connectivity, and a configuration that keeps it available.
• 07:50 Scott describes a project layout built around folders, separate ports, and assigned domains. That mapping becomes operational documentation once several applications share the machine.
• 10:02 Mosh improves interactive terminal access across sleep and network changes. Its role is narrower than replacing every connection used by a development environment.
• 10:36 Caddy routes incoming web requests to the appropriate application. Recognizable addresses and centralized HTTPS make testing from several devices easier to organize.
• 12:18 Tailscale supplies private connectivity between enrolled devices. Short machine names make that network more pleasant to use, while the applications remain inside the private tailnet in Scott’s setup.
• 15:05 Alternatives such as Portless and Cloudflare enter the discussion. They address overlapping needs, so evaluating them requires deciding whether the immediate problem is naming, private access, or sharing an application externally.
• 19:28 Zed provides local editing of remote projects over SSH. The hosts explicitly separate that editor connection from the Mosh terminals used to run agents.
• 21:41 tmux and Herdr provide sessions that users can leave and revisit. Herdr’s agent status display addresses the additional problem of finding which task needs attention.
• 28:47 Termius brings those sessions to a phone. Touch handling and keyboard shortcuts remain friction points, making mobile access more suitable for some actions than others.
• 32:32 Browser automation exposes another boundary: the browser runs elsewhere, and authentication needs a deliberate workflow. The conversation raises these questions without establishing a complete login solution.
• 38:38 Worktrees offer separate working directories for parallel changes or competing implementations. The hosts still see ordinary branches as sufficient for much of their individual work.
• 44:19 Owned hardware and rented machines are both options. Connection quality and maintenance effort belong in the decision alongside the subscription price.

How to apply

Mosh SSH: assign one job to each layer

I would build this as a short chain of responsibilities. Tailscale provides private reachability. SSH handles ordinary remote login and the editor connection. Mosh improves terminal continuity when connectivity changes. tmux or Herdr keeps a workspace available after a client disconnects. Caddy handles access to the web applications.

Start with an available computer and one project that can tolerate an interrupted experiment. Write down its directory, port, start command, stop command, and browser address. That small runbook becomes increasingly valuable as the number of background processes grows. I would want a clear way to stop every task before adding several more.

Establish a recoverable terminal session

Install Tailscale on the host and laptop, enable name resolution, and verify an ordinary SSH login over the private address. This baseline can use the existing SSH service through Tailscale networking. Enabling the separate feature named Tailscale SSH is an additional choice.

With Mosh installed at both ends and tmux available on the host, replace the example account and hostname:

mosh dev@devbox
tmux new-session -A -s project

The second command creates project or attaches to the existing session. Start something whose progress you can inspect, such as a development server or a build that writes a log. Press Ctrl+b, then d, to detach. Running the tmux command again returns to the session. The options are documented in the tmux manual.

Mosh authenticates through SSH before using UDP for the terminal connection. A successful login followed by an unresponsive session is a reason to inspect host firewall rules and tailnet permissions for that traffic. The Mosh documentation covers installation at both ends and the default UDP port range.

Test interruptions before adding complexity

Use a simple checklist and record what actually happened:

| Interruption | Acceptance check | | --- | --- | | Sleep and wake the laptop | The task continued and terminal access returned. | | Change networks | Work resumed without restarting the task. | | Quit the terminal application | A fresh connection could reattach to tmux. | | Deliberately reboot the host | The runbook restored services and made interrupted work identifiable. |

The reboot check measures a different capability. A persistent terminal session does not preserve running processes through a host restart. Keep the commands needed to reconstruct the environment, and configure automatic startup for services that should return unattended. Long jobs benefit from checkpoints or intermediate output so recovery does not always mean starting over.

I would test with a real project before choosing a more elaborate session manager. Herdr’s status display becomes compelling when manually checking terminals starts consuming attention. That is a measurable reason to adopt another tool.

Make private HTTPS an explicit configuration

For the first web application, I would use the host’s full .ts.net name. Enable HTTPS certificates in the tailnet and follow the documented integration. Caddy can obtain the certificate from the local Tailscale daemon; its service account needs the appropriate permission. See the Caddy and Tailscale integration guide.

Configure the reverse proxy to the application’s port, then restrict reachability through network policy and the host firewall. A valid certificate establishes HTTPS identity. Access control still determines which devices can reach the service.

If you choose internal names backed by Caddy’s local certificate authority instead, each client must trust that authority. A phone will not automatically inherit the server’s trust configuration. The distinction is covered in Caddy’s automatic HTTPS documentation.

Give mobile access a narrow first purpose

My initial phone workflow would be checking logs, spotting a blocked task, and stopping a process. I would keep substantial code review on a screen where I can inspect the surrounding changes. For browser automation, begin with a separate profile and a test account, then document how to renew authentication when the session expires.

Run the setup for a week and track reconnect time, minutes spent rebuilding workspaces, and host outages. Compare those results with the cost of hardware, electricity, backups, and maintenance. Check software eligibility too: Tailscale’s Personal plan is free for non-commercial use, while a business team needs to evaluate the relevant plan.

Finally, budget model usage separately from the computer. Hosting an agent on your own machine does not automatically move its model inference there. I would expand this workflow once returning to an interrupted task becomes predictable and the state of the work is easy to understand.