My laptop is no longer where most of my coding work runs.
I use remote Linux servers to keep agents working when I close the lid, lose internet, or get on a plane. The laptop is an interface. The long-running process lives somewhere that stays online.
This is the setup I use to build Inbox Zero, the open source AI email assistant I founded. It has also made traveling much easier because the work does not depend on the device in my backpack.
You can see the complete setup in the 21-minute YouTube video. This article focuses on the developer workflow.
Why keeping the laptop awake is not enough
An app such as Amphetamine or Caffeine can stop a laptop from sleeping. That helps at home, but it does not solve the travel problem.
The laptop still needs power. It still needs a reliable hotspot. The process still dies when the machine loses its connection, runs out of battery, or goes into a bag at airport security.
The more useful boundary is simple:
- The laptop displays and controls the work.
- A remote server runs the work.
- The agent process survives when the client disconnects.
Once those roles are separate, changing devices becomes much less disruptive.
1. Put the development environment on a remote server
I use providers such as Hetzner and Netcup for Linux servers. The exact provider matters less than choosing enough capacity for the repositories and agents you expect to run.
Four gigabytes of RAM is enough for an experiment, but it becomes restrictive quickly. Dependencies, builds, multiple worktrees, and several agent sessions add up. For a serious environment, I prefer 8 or 16 gigabytes of RAM and enough SSD space that storage does not become the next failure.
The server contains the repository, dependencies, terminal sessions, and agent processes. I can start work from my laptop, disconnect, and return without moving that state between machines.
2. Keep access private with Tailscale
I do not want development services exposed to the public internet just because I need to reach them while traveling.
Tailscale puts my laptop, phone, remote servers, and Macs on the same private network. Each authorized device can connect over SSH without opening the development environment to everyone else.
This also gives the machines stable identities. I am connecting to the same server whether I am at home, in a hotel, or using mobile data.
3. Keep agent sessions persistent with Herdr
SSH access alone does not make a process durable. The terminal session needs to survive the client disconnecting.
Herdr gives me persistent agent sessions with split views, file browsing, reviews, and mirrors. It is similar in spirit to tmux, but designed around working with coding agents.
I can launch an agent, close the terminal, reconnect later, and see the same session. The remote environment feels close to a local terminal, but it is not tied to the local machine's uptime.
Tmux can handle the persistence layer too. Herdr is the interface I currently prefer because the agent-oriented tools are built into the same workflow.
4. Use the phone as a control surface
Trying to reproduce a full desktop coding environment on a phone is frustrating. Agents change what the phone needs to do.
I mainly need to:
- Check what the agent completed.
- Answer a question or clarify the task.
- Review a result.
- Give the next instruction.
The native ChatGPT, Claude, and Cursor apps can cover parts of that workflow. A mobile terminal provides direct access when I need it. The phone is not doing the build itself. It is controlling work on the server.
That is a much better fit for a small screen.
5. Connect a Mac only when the task needs one
Most of the environment can run on Linux, but iOS development eventually needs macOS, Xcode, and the simulator.
I keep the primary agent on Linux and let it connect to a Mac Mini, an older Mac, or a rented cloud Mac for the platform-specific step. The agent can run the app and inspect the simulator without moving the whole development workflow onto the Mac.
This pattern works beyond iOS. Keep the general process on dependable infrastructure, then connect a specialist machine only for the task that requires it.
Where Inbox Zero fits
I use this remote setup every day to build Inbox Zero. The product solves another problem that becomes worse while traveling: returning to an inbox full of messages and not knowing which ones need attention.
Inbox Zero organizes email, identifies messages that need a reply, drafts responses, and keeps lower-priority newsletters and marketing mail out of the way. It is open source.
The common principle is continuity. The coding agents keep working when the laptop closes. The email assistant keeps organizing work when I am not scanning the inbox.
Tradeoffs
A remote development environment adds infrastructure you need to secure and maintain. It is not automatically better for every task.
Use it when:
- agents or builds need to run for a long time;
- you regularly move between devices;
- losing a laptop connection currently stops useful work; or
- you want a consistent environment shared by several clients.
Keep the work local when latency matters, the repository cannot leave the device, or the setup cost is larger than the interruption it removes.
The goal is not to put everything in the cloud. It is to stop the wrong device from becoming a single point of failure.
My complete software and physical travel setup is in the full YouTube video. It also covers the connected luggage, laptop power bank, chargers, and camera glasses I use with my family.
Top comments (0)