A coding agent that runs for three hours doesn't fail because the plan was wrong — it fails because the machine underneath it went to sleep, changed networks, or ran out of battery. This page explains what a VPS actually is, why "always on" matters more than "fast," and how to size, choose, and lock one down without guesswork. Two simulations below let you break a task on purpose and watch the difference.
A laptop is built to survive being carried, closed, and run on a battery — every one of those design goals works against a process you want to keep running unattended for hours. None of the failure modes below are bugs. They're the laptop doing exactly what it was designed to do.
None of this matters much for a chat session, where the "task" is a burst of typing followed by idle time. It matters enormously for an agent that reads a spec, edits files, runs a build, reads the output, and repeats that loop unattended — a workload that is long-running and stateful by nature. If you've moved from a personal assistant like OpenClaw or Hermes Agent into an actual coding agent, this is usually the first wall you hit: the assistant tolerated your laptop's habits because its tasks were short; the jump from assistant to agent changes the shape of the workload, and the laptop's habits stop being harmless.
Think of each hour of a laptop-hosted task as carrying some chance of an interruption event — the lid closes, the network roams, the battery runs out, an update fires. None of those probabilities need to be high for the effect to compound: a task's odds of finishing intact fall with every additional hour it has to survive uninterrupted. A ten-minute task rarely meets any of these events. A three-hour task meets several, almost by default, because your laptop keeps being a laptop the entire time you're not looking at it.
An always-on machine removes the variables that scale badly with duration, not by being more powerful, but by not sleeping, not roaming between networks, not running on a battery, and not being tied to your physical location. It sits in a data center with wired power and a stable network path, indifferent to whether you're holding a laptop or not. The task takes exactly as long as the task takes — nothing external to the work interrupts it.
The point isn't that laptops are bad machines — they're excellent at the job they were designed for. It's that "stay unattended for hours, on one machine, without interruption" was never that job. A VPS is a different tool for a different requirement.
Your agent has been running for 90 minutes on your laptop. You close the lid to grab coffee. What happens to the run?
VPS stands for virtual private server: a rented slice of a real, physical server sitting in a data center, carved out by software called a hypervisor. The hypervisor partitions one physical machine's CPU, memory, and disk into several isolated virtual machines, and you get one of them — with its own complete operating system, its own root account, and a public IP address, even though the underlying hardware is shared with other tenants you never see or interact with.
That's a meaningfully different thing from cheaper "shared hosting," where you get a folder on someone else's already-running server and no control over the OS. It's also different from a dedicated or bare-metal server, where you rent an entire physical machine and nobody shares it with you. A VPS sits in between: real isolation, a real OS, root access — at a fraction of a dedicated machine's cost, because the physical hardware is shared at the virtualization layer, not at yours.
Root is the part that matters for an agent. It means there's no permission ceiling: you can install any package, open any port, run any process. On a laptop you might be blocked by a device-management profile, a "please enter your password," or a corporate lockdown. On your own VPS, none of that exists — which also means the security responsibility is entirely yours (more on that in the sections ahead).
The other property worth naming is reachability: a VPS holds a stable IP address or hostname and stays listening on the network whether or not anyone is connected to it. That's what lets you close your laptop, walk away, and reconnect an hour later to a machine — and a running task — that never noticed you were gone. Getting into that machine safely in the first place is a separate topic worth its own read: SSH, plainly covers exactly how the connection and the key-based login work.
"Cloud" is mostly VPS at scale. Major cloud providers' basic compute offerings are the same virtual-machine-on-shared-hardware model, wrapped in more automation: API-driven provisioning, elastic autoscaling, managed load balancers. For a single operator running agents, a plain VPS from a smaller provider and a cloud VM from a hyperscaler are conceptually the same thing wearing different amounts of tooling.
Isolation is strong but not physical. Modern hypervisors (KVM, Xen, and similar) enforce hard boundaries between tenants at the CPU and memory level — you cannot see or touch another customer's VM. It is still shared physical hardware, which is why noisy-neighbor performance variance and provider-level outages are real, if uncommon, considerations.
The instinct is to assume an "AI agent" needs a powerful, possibly GPU-equipped machine. It doesn't. The model itself runs in a data center operated by Anthropic, OpenAI, or whoever's API you're calling — your box never touches the model weights. What runs locally is the agent's command-line client: a process that reads and writes files, runs shell commands, and makes network calls to the model API while it waits for the next response. That client is lightweight — comparable to running a code editor and a terminal, not a machine-learning workload.
What actually consumes CPU, memory, and disk on a coding-agent box is everything the agent's work triggers: compiling code, running a dev server, executing a test suite, installing dependencies, building a container image. Those are ordinary software-engineering workloads, and they were resource-hungry long before agents existed — the agent just triggers them more often and, if you let it, in parallel.
A reasonable, honest baseline for a single operator running one coding agent through normal edit-test-commit cycles: 2 vCPU, 4–8 GB of RAM, and 50+ GB of disk. That covers the agent client, an editor or two, a language runtime, and the occasional build without surprises. It is not a ceiling — see the picker below for what changes as your workload grows.
Notice what moves the numbers in the picker: it's never "more agents" in the abstract, it's more concurrent builds, more file watchers, more compilers running at once. If you're running several agents against the same repository in parallel, the sizing question and the collision question are related — isolating each agent's working files (rather than sharing one checkout) is the same discipline covered in how git works with AI agents, and it's worth reading before you scale past one agent.
Providers differ on price and polish, not on the underlying technology — a VPS is a VPS. Rather than a specific recommendation, four criteria actually predict whether you'll be happy with your choice:
On cost: for the workloads in the sizing picker, a realistic range runs from a few dollars a month at the low end up to roughly $20/month for most single-operator setups. Heavier, multi-agent-plus-build workloads can push past that, but they're the exception, not the default.
A freshly provisioned VPS arrives with a default configuration meant to get you logged in, not to stay secure long-term. A handful of steps, done once at the start, close most of the gap:
apt update && apt upgrade -y # patch the system first adduser you && usermod -aG sudo you # a non-root user with admin rights ssh-copy-id you@your-box # install your public key for that user # then edit sshd_config: PasswordAuthentication no
A VPS gets a public IP address, which means every port you open on it is reachable from the entire internet unless you deliberately close it. The recurring, well-documented mistake in this space is a development server, an admin dashboard, or an agent's own control interface bound to all network interfaces and left open — discoverable by the same automated scanners that probe the whole internet's address space continuously. Public exposure isn't a hypothetical; it's the default outcome of doing nothing.
The fix is a default-deny firewall: block every inbound port except the one you actually need (typically just SSH), and reach anything else — a dev server, an internal dashboard — through a private network instead of a public one. A VPN or a mesh overlay network ("tailnet") puts your laptop and your VPS on the same private network regardless of where either one physically is, so services can bind to that private address and never touch the public internet at all.
Being reachable and being unattended for hours also raises a second, more mundane problem: reconnecting to the exact terminal and process you left running, not a fresh one. That's what a persistent terminal session layer is for — it decouples the running process from any single network connection, so closing your laptop or losing wifi disconnects you, not the task. Why your agent dies when you close the laptop covers that mechanism in depth; a VPS solves "the machine doesn't sleep," and persistent sessions solve "reconnecting doesn't cost you the work in progress" — you generally want both.
TermRoam is a dedicated always-on server for your AI agents, provisioned with the hardening in this page already done: a non-root user, key-only access, a default-deny firewall, and a private network path in from your devices — so the first ten minutes above ship built in rather than left to you. Sessions persist across disconnects by construction, so a dropped connection is a reconnect, not a restart, and the coding agent CLIs you'd install by hand arrive preconfigured. It's the same idea as this page, running as a product instead of a checklist.