# reachpad vs tmux on your own VPS

> A VPS with tmux is the honest baseline, it costs a few dollars a month, and it is the right answer more often than a vendor will tell you. Here is precisely where it stops.

Part of the reachpad comparisons: https://reachpad.dev/compare. Rendered page: https://reachpad.dev/compare/tmux-on-a-vps. Last checked 2026-08-12.

## Side by side

|  | tmux on a VPS | reachpad |
| --- | --- | --- |
| Survives your laptop closing | Yes, the process runs on the VPS | Yes, the run is on the fleet |
| Survives the machine restarting | No. A reboot, an out-of-memory kill or a host migration ends the session and its scrollback | Yes. Disk and memory are sealed, and the next attach resumes from the seal |
| Who patches the machine | You | The fleet |
| Who updates the agents | You | The pad keeps them current between sessions |
| Knowing an agent is stuck | You attach and look | [Agent status](https://reachpad.dev/docs/agent-status): waiting or working, without attaching |
| Rolling back a bad hour | Whatever you committed | Fork or rewind from retained checkpoints |
| Cost | A few dollars a month, plus your time | 1,000 one-time trial credits, 16 hours 40 minutes of active workspace time across up to 10 workspaces; a pad is priced on [pricing](https://reachpad.dev/pricing) |

## What tmux actually solves

tmux detaches a process from the terminal that started it. That is a real problem and tmux solves it completely: ssh drops, the wifi changes, you close the lid, and the process does not notice, because it was never attached to your session in the first place.

The two things people expect from it that it does not do: it does not protect a process from the machine going away, and it does not tell you anything about what the process is doing. Both matter more with agents than they did with builds, because an agent stops and waits for an answer, and a waiting agent looks exactly like a working one until you attach and read.

> Note: tmux on your laptop is not a remote session. It survives a closed terminal, not a suspended machine. The process has to live somewhere that does not sleep, which is the whole of the argument for putting it anywhere else.

## When your own VPS is the right answer

When you already run one, you like running it, and the work is one long-lived agent you check on yourself. It is cheaper, nobody can deprecate it, and root on a machine that is yours has no equal. Everything above is a list of chores, and if you do not mind the chores there is nothing here worth paying for.

The trade shows up at the second machine, at the reboot that eats a session you cannot reconstruct, and on the morning you find an agent that has been waiting eleven hours for a yes.