$ ssh clawdbot.space --loading...
$ ssh clawdbot.space --loading...
A practical comparison to help you decide the best infrastructure for your OpenClaw node.
The most common question new OpenClaw users ask is: should I run this on a cloud VPS or on dedicated local hardware? There's no universal answer β it depends on your use case, budget, and privacy requirements. This guide breaks it down.
| Factor | VPS (Cloud) | Local Hardware (Mac Mini / Raspberry Pi) |
|---|---|---|
| Uptime | β 99.9% SLA guaranteed | β οΈ Dependent on your home power & internet |
| Privacy | β οΈ Provider can inspect your server | β Data never leaves your home |
| Startup Cost | β ~$5-10/month, no upfront cost | β οΈ $300-$600+ one-time purchase |
| 3-Year Total | β οΈ $180-$360+ | β $300-$600 (then ~$10/yr electricity) |
| Local LLM Speed | β Slow on cheaper VPS CPUs | β Fast (especially Apple Silicon UMA) |
| Local File Access | β Only your VPS filesystem | β Your entire home NAS, external drives |
| Power Consumption | β Not your electricity bill | β οΈ Mac Mini ~7-30W, Pi ~5-8W |
| Setup Complexity | β Simpler (no network config) | β οΈ Requires port forwarding or Tailscale |
Many advanced users run both: a cheap VPS ($5/mo) as the public-facing endpoint and Telegram bot receiver, with a Tailscale tunnel to their local Mac Mini for actual task execution and LLM inference. The VPS handles uptime and public access; the Mac Mini handles privacy and compute.
If you're just starting out: start with a Hetzner CPX11 VPS ($5/mo). Once you're hooked and want local LLMs, buy a used M2 Mac Mini and migrate. Run both if budget allows.
Most of this comparison collapses into four questions. Answer them in order and the choice usually makes itself; where it does not, the answer is the hybrid arrangement rather than a compromise on either side.
| If this is trueβ¦ | β¦then choose | Why |
|---|---|---|
| You need an 8B+ model to feel interactive | Local (Apple Silicon or a GPU) | A CPU-only VPS is roughly an order of magnitude slower. No plan size fixes it. |
| Third parties must POST webhooks to you | VPS, or local plus a tunnel | A stable public address is the thing a VPS is genuinely good at. |
| The data must not leave hardware you control | Local | This is a constraint, not a preference. It ends the discussion. |
| Usage is occasional and bursty | VPS, destroyed after use | Paying by the hour beats owning hardware that idles. |
| It must be online while your home internet is not | VPS | A residential connection is a single point of failure you do not control. |
The hybrid is not a fence-sitting answer, it is usually the correct one: run the always-on gateway on a cheap VPS for the stable address and the uptime, and point it at a model running on hardware you own. You get the public endpoint without paying for CPU inference, and the model stays on your own machine.
Run these four checks rather than reasoning from someone else's benchmark table. The third one in particular takes an hour and a few cents and replaces the entire argument with a measurement.
# 1. What is the largest model you actually need? # 4-bit size in GB β billions of parameters Γ 0.6 # 3B β 2 GB 8B β 5 GB 14B β 9 GB 32B β 20 GB 70B β 40 GB # # If the answer is 8B or larger AND replies must feel interactive, # you need a GPU or Apple Silicon. A CPU-only VPS cannot deliver it.
This is the question that most often settles it outright. Interactive use of an 8B or larger model rules out CPU-only hosting regardless of how many vCPUs you buy.
# 2. Does anything need to reach the agent from the public internet? # (inbound webhooks from Stripe, GitHub, a calendar providerβ¦) # # Yes β a VPS gives you a stable public address for free. # No β local hardware plus Tailscale is simpler and cheaper.
Outbound-only workloads do not need a public address at all, which removes the main reason to pay for a VPS.
# 3. Measure before you migrate. On the machine you already own: ollama run llama3.1:8b --verbose "Write two paragraphs about tide pools." # read the `eval rate` line β that is generation tokens/second # Then compare against the same command on a rented VPS for an hour. # An hour of CX32 costs a few cents and settles the argument with data.
Rent the VPS for an hour and run the identical command on both machines. This costs less than a coffee and produces a number specific to your model and your context length.
# 4. Cost the whole thing, not the headline. # VPS: monthly fee Γ 12 # Local: hardware Γ· expected years + electricity # electricity/year β idle watts Γ· 1000 Γ 8760 Γ your $/kWh # # A 10 W always-on box at $0.12/kWh is about $10.50 a year.
Compare the monthly fee against hardware amortised over the years you will actually keep it, plus electricity. Note that a low-power box's electricity is usually a rounding error next to the VPS bill.