"Going to the cloud" sounds like progression. It is really about three problems local genuinely cannot solve. If none apply, the machine you buy is just a new maintenance burden.
In this pagethree tests, four false reasons, cheaper alternatives. Not in this pagehow many machines I have, where, running what.
| # | Test | Why local cannot |
|---|---|---|
| 1 | Must stay up around the clock | Laptops close, sleep, reboot, and leave the building with you |
| 2 | Needs a fixed network egress | Home addresses change; some services want an allow-listed, stable source |
| 3 | Must fire on time while you sleep | Machine asleep, scheduler silent — the most common one |
What they share: all three are faces of "you are not there". If everything you need happens while you are sitting at the computer, you do not need a remote machine.
| False reason | Actually | Cheaper answer |
|---|---|---|
| "I do not want it wrecking my computer" | That is an isolation need, not an uptime need | The Docker backend (page 17), free |
| "Local is too slow / too heavy" | The bottleneck is usually on the model's side, not your CPU | Measure where it is slow first; the machine probably will not help |
| "It looks professional" | — | — |
| "I might need it later" | "Later" often does not arrive. The monthly charge does | Buy when one of the three tests actually applies |
"I want the agent free to make a mess without breaking my things" is a completely legitimate wish — but its answer is isolation, not remoteness.
A local Docker backend gives filesystem and process isolation with no money, no machine to maintain, no firewall and no keys to worry about. Try that first; escalate only if it is not enough.
A cheap VPS costs about what lunch costs. The real cost sits elsewhere:
| Cost | What it is |
|---|---|
| A machine to maintain | Updates, certificates, disks filling up |
| An attack surface | A public machine is being scanned from its first minute. Not hyperbole, just the default state of the internet |
| It will hold keys | And it is easier for other people to reach than your laptop |
| Attention | Page 12's lesson: a long-running box occupies a slot in your head indefinitely |
So keep the tests strict. If you can avoid running a machine, avoid it.
| Ask | Yes → | No → |
|---|---|---|
| Do I need it working while I am not there? | Continue | Stop. Local is fine |
| Do I only want isolation? | Stop. Use Docker | Continue |
| Do I need "available whenever" or "running always"? | Available whenever → look at hibernating sandboxes | Running always → buy a machine, go to the next page |
They get conflated constantly and their costs differ a lot. If the work is "occasionally needs to run, but the environment has to be there when it does", then an idle-hibernating sandbox is far cheaper than a permanently running box (page 17).
Only work that requires a process alive at all times — waiting for a message, waiting for a clock — genuinely needs a machine that never stops.