Should Coding Agents Run on a Home Server or a Cloud VM?
Updated October 27, 2026 .md
Short answer: Keep agents on a home box when they need your local network, your devices or a GPU you own, and one always-on machine is enough. Use cloud VMs when you want agents kept off your home network, several copies at once, snapshots to roll back or fork, and HTTPS URLs without opening ports.
This page is for a developer who already has a spare machine (a mini PC, an old desktop, a GPU workstation) and wonders whether to point coding agents at it or rent VMs instead. It isn't a sales pitch for either: some jobs belong at home. Below are the questions that decide it, Sandboxer's cost per agent-hour with the arithmetic, and one run on Sandboxer's production service on 2026-10-27. How to set up an agent in a VM is covered in Run Claude Code in a cloud VM, and the step-by-step for a fleet in Run coding agents in parallel.
Decide with five questions#
| Question | If yes, lean | Why |
|---|---|---|
| Does the agent need something only on your LAN: a NAS, a printer, a dev board, a database on another machine, Home Assistant? | Home box | A sandbox can't reach your home network, and you shouldn't open your network to it |
| Does the agent need a GPU, for example a local model you serve yourself? | Home box | Sandboxer sandboxes are CPU only |
Would it be bad if a confused agent ran rm -rf, read your SSH keys, or scanned your LAN? |
Cloud VM | The agent's blast radius is one disposable VM, not the machine your photos and keys live on |
| Do you run more than one agent at a time, or retry the same task several ways? | Cloud VM | Each copy gets its own disk, ports and Docker, started from one prepared snapshot |
| Do you need to show someone a running app, or receive a webhook? | Cloud VM | sbx host gives each port an HTTPS URL, so you never forward a port on your router |
If you answered yes to questions from both halves, split the work: see the hybrid setup below.
What a home box is genuinely good at#
- Your local network. The agent can talk to anything your machine can: other computers, IoT devices, a self-hosted Git server. That is the reason to keep it home, and also the risk.
- Hardware you already own. A GPU, a large disk, a lot of RAM you already paid for. Sandboxer sizes top out at 16 vCPU and 32 GB (
xlarge), with no GPUs. - Always on with no meter. The box runs whether or not an agent is working, and nothing is billed per hour of use.
- Your files stay in your house. Nothing about the code or data leaves unless the agent sends it, which matters for some work.
What it costs you in effort: one shared environment for every agent unless you add containers or VMs yourself, OS updates, backups, and keeping the box reachable when you're away.
What a cloud VM is good at#
- Isolation from you. A Sandboxer sandbox is its own VM with its own kernel and disk. It can't reach other sandboxes, even your own, and it has no route to your home network. Inbound traffic only arrives through ports you host, SSH, or IPv6 ports you open yourself. Details, with tests, in What can reach a sandbox, and what it can reach.
- Parallel copies. Prepare a repo once, save it as a named snapshot, and start as many copies as your plan allows. In our run below (2026-10-27), two copies were ready in 3.2 seconds, side by side.
- Snapshots and forks. Every running sandbox is snapshotted every 10 minutes and at every stop.
sbx forkcopies a sandbox's disk into a new one, so you can try a risky change on a copy. A home box needs your own tooling (ZFS, Btrfs, a hypervisor) to do the same. - Hosted URLs.
sbx host <id> <port>serves a port onhttps://<subdomain>-<port>.box.sandboxer.com, private with a token by default. Your router stays closed. - Pay for the hours you use. Billing is per second while a sandbox runs. A stopped sandbox bills no compute.
What it costs you: no access to your LAN or GPU, a per-hour price, and work that lives on someone else's servers.
What Sandboxer costs per agent-hour#
Every number here comes from the pricing page; the rest is arithmetic.
- One
smallsandbox (2 vCPU, 4 GB) costs $0.018 an hour. Onedefaultsandbox (4 vCPU, 8 GB) costs $0.036 an hour. - One agent per sandbox, so one agent-hour on
smallis $0.018, and ondefaultis $0.036. - Three agents on
smallfor an 8-hour workday: 3 × 8 × $0.018 = $0.432. - The same three agents, 8 hours a day on 22 workdays: 3 × 176 × $0.018 = $9.504, about $9.50 a month. That fits inside the $20 plan's $20 of machine time.
- Three
smallsandboxes left on for a whole month (730 hours): 3 × 730 × $0.018 = $39.42. This is the pattern to avoid: stop sandboxes or set an idle pause when the agents are done.
A home box has its own costs: the machine, power, your internet connection, and your time keeping it patched and backed up. They depend on your hardware and where you live, so this page doesn't estimate them. Price both for your own case. More Sandboxer patterns are worked out in Sandbox cost tables.
Beyond price, the two differ in how they handle parallel work. A home box shares its CPU, RAM and disk between agents. Three sandboxes are three separate machines, measured below.
We ran it: three agent workspaces from one snapshot#
We ran this on prod on 2026-10-27 between 15:44 and 15:59 UTC, with three small sandboxes, from a computer outside Sandboxer's network. The "agent work" is a stand-in you can reproduce: a real Python repo (itsdangerous) and its 297-test suite run 20 times. No model was called. Output is trimmed with ….
1. Prepare one workspace and save it#
sbx new --name home-vs-cloud-1 --type small --ttl 3600
sbx exec sb_cvd183c4kl --timeout 300 "git clone -q --depth 1 https://github.com/pallets/itsdangerous repo && cd repo && python3 -m venv .venv && .venv/bin/pip install -q -e . pytest freezegun && .venv/bin/python -m pytest -q -p no:cacheprovider | tail -1"297 passed in 0.64ssbx snapshot sb_cvd183c4kl home-vs-cloud-ws{"ok":true,"type":"snapshot.named.info","snapshot":{…,"name":"home-vs-cloud-ws",…,"status":"ready","type":"small",…}}The save took 2.1 seconds.
2. Start two more copies at the same time#
for n in 2 3; do
sbx new --from home-vs-cloud-ws --name home-vs-cloud-$n --type small --ttl 3600 --json > new-$n.jsonl &
done
waitBoth returned ready 3,194 ms after the loop started, as sb_dzoymld20h and sb_ve1upxdpp0. Each had the repo and its virtualenv already in place, with no reinstall:
happy-fluffy-juniper
672971d Merge branch 'stable'
.venv/bin/pytestNow there are three workspaces with the same starting state: the original and two copies of its snapshot.
3. Give each agent its own branch, and check they don't share files#
In each sandbox we created a branch agent-N and committed a file AGENT_N.txt. Then, in workspace 2:
sbx exec sb_dzoymld20h "ls ~/repo/AGENT_*; git -C ~/repo branch"/home/user/repo/AGENT_2.txt
* agent-2
mainOnly its own file and branch. On one home box, three agents need three checkouts or worktrees and still share ports and Docker; Git worktrees or one VM per agent compares the two.
4. Run the work in all three at once#
The same job in each sandbox, started together: the test suite 20 times.
cd ~/repo
for i in $(seq 1 20); do .venv/bin/python -m pytest -q -p no:cacheprovider >/dev/null; done| Run | Time |
|---|---|
| Workspace 1 alone, before the copies existed | 17.3 s |
| Workspace 1, with all three running | 16.7 s |
| Workspace 2, with all three running | 16.7 s |
| Workspace 3, with all three running | 16.4 s |
| Wall clock for all three | 16.9 s |
Three times the work finished in the time of one, because each workspace has its own 2 vCPUs. On a home box the same three jobs share one CPU. This is one run; the numbers will vary.
5. One HTTPS URL per workspace, router untouched#
Each workspace served a page on 127.0.0.1:8000 and hosted it as a private URL:
sbx exec sb_ve1upxdpp0 "mkdir -p ~/www && echo \"workspace \$(hostname) on branch \$(git -C ~/repo branch --show-current)\" > ~/www/index.html && (setsid nohup python3 -m http.server 8000 --bind 127.0.0.1 --directory ~/www >/dev/null 2>&1 &)"
sbx host sb_ve1upxdpp0 8000 --localhost{"ok":true,"type":"port.hosted","sandboxId":"sb_ve1upxdpp0","port":8000,"url":"https://icy-cobalt-atlas-8000.box.sandboxer.com?_token=REDACTED","access":"private","isProtected":true,"localhost":true}Without the token the URL answered 401. With it, the first request answered 302 (it sets a cookie) and the follow-up 200:
workspace icy-cobalt-atlas on branch agent-3
200All three workspaces gave the same results, each on its own subdomain. Binding to 127.0.0.1 and using --localhost keeps the app off the sandbox's public IPv6 address.
6. Clean up#
sbx delete sb_cvd183c4kl --yes
sbx delete sb_dzoymld20h --yes
sbx delete sb_ve1upxdpp0 --yes
sbx snapshot rm home-vs-cloud-wssbx info then answered 404 not_found for all three. Machine time for the whole test: about 14.3 minutes for the first sandbox and 1.3 minutes for each copy, 16.9 minutes of small in total. 16.9 / 60 × $0.018 = $0.005, about half a cent.
A hybrid that keeps your home network closed#
You don't have to pick one. A common split:
- Keep at home the agents that need your LAN or your GPU, and anything you don't want to leave your house.
- Send to sandboxes the work that is risky (agents with permissions skipped, unknown dependencies), parallel (several tasks, or several attempts at one task) or needs a shareable URL.
- Drive the sandboxes from the home box. The
sbxCLI runs on Linux, so your home server can start, prompt and delete sandboxes on a schedule. All connections go out from your house; nothing has to come in.
Don't connect a sandbox back into your home network to reach a LAN service. That undoes the isolation you moved the agent for. If an agent needs a LAN service, it belongs on the home box.
FAQ#
Can a Sandboxer sandbox reach devices on my home network?#
No. A sandbox has outbound internet access and no route to your LAN. It also can't reach other sandboxes, including your own. To reach something at home you would have to expose it to the internet, which this page advises against.
Can I use the GPU in my home server from a sandbox?#
No. Sandboxer sandboxes are CPU only, and connecting a sandbox to a GPU server at home means opening your network to it. Run GPU-bound agents on the home box.
How do I compare the cost of the two?#
Sandboxer bills per second while a sandbox runs, at the rates above, and nothing for compute while it's stopped. For a home box, add up the machine, power, internet and upkeep for your own setup. Which comes out lower depends on how many hours your agents run.
Do my agents' sandboxes keep running when my home internet goes down?#
Yes. The agents run in the cloud VMs, not on your connection. Check on them later with sbx events or sbx ssh once you're back online.
How many agent workspaces can run at the same time?#
As many as your plan allows to be active together: 100 on the $20 plan, and 2 during the free trial. Starts are also rate-limited per minute, hour and day.
Related#
More guides
For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.
For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.
The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.
If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.