I went down a very familiar rabbit hole this week.
It started with the classic Reddit take: why pay for hosting when you can run OpenClaw on an old laptop or a mini PC you already own?
At first, that sounds efficient.
If you already have the hardware, why not turn it into a 24/7 agent box and save money?
Then I kept reading threads from people who had actually done it.
And the more I looked at the setup, the less this felt like "cheap infrastructure" and the more it felt like "converting cloud spend into weekend ops work."
If you're running AI agents, browser automations, or OpenClaw workflows, here's the practical version.
The hardware is not the expensive part
Yes, you can self-host OpenClaw.
That's not in question.
OpenClaw is designed for it. The gateway runs on your own machine or server. The setup is straightforward enough if you're comfortable with Node, Docker, browser automation, and provider credentials.
At minimum, you're dealing with:
- a machine that stays online
- Node 24 recommended, or Node 22.16+
- an OpenClaw gateway process
- API keys for GPT-5, Claude, Qwen, Llama, or whatever model backend you're using
- browser sessions that don't randomly die
- ongoing updates and troubleshooting
The docs say setup is fast.
That's probably true for first install.
But developers know this already: install time is not ownership cost.
What the install actually looks like
The happy-path setup is not hard.
# example only
node -v
# should be 24.x or 22.16+
openclaw onboard --install-daemon
openclaw gateway status
openclaw dashboard
And when things break, your runbook starts looking like this:
openclaw status
openclaw gateway status
openclaw logs --follow
openclaw doctor
openclaw channels status --probe
None of that is unusual.
It is also real work.
If you're the kind of person who enjoys debugging service state, browser dependencies, auth weirdness, and startup issues, that's fine.
If you just want your agent to keep running while you do actual product work, it's a different story.
Headful browsers are not a nice-to-have
One of the most useful things I found in the Reddit discussions was people being weirdly insistent about running a real visible browser.
They're right.
If your agents touch real websites, headless-only setups are often where the pain starts.
Agents don't just call APIs. They:
- log into brittle admin panels
- click through React apps with timing issues
- deal with stale sessions
- hit CAPTCHAs and popups
- break on sites that behave differently in headless mode
A visible browser session is often easier to debug and, in practice, more reliable for messy workflows.
That changes the infrastructure decision.
Suddenly the cheapest VPS isn't always the best fit, because now you care about GUI support, browser stability, and being able to inspect what Chromium is doing when a workflow gets stuck.
That's why so many people end up recommending Ubuntu or Xubuntu with a GUI on a mini PC.
Not because terminals are bad.
Because browser automation is messy and visual.
Old laptop vs mini PC vs VPS
This is the comparison that matters.
| Option | What you're really buying |
|---|---|
| Old laptop | Lowest upfront cost if you already own it, but you're accepting battery wear, heat, fan noise, sleep issues, and hardware that was not really meant to be your forever 24/7 agent appliance |
| Mini PC | Better fit for always-on browser automation, lower power draw than a desktop, cleaner than a spare laptop, but you still own OS updates, Node or Docker issues, browser uptime, and maintenance |
| Managed VPS + flat-rate model backend | Low monthly cost, better uptime than random spare hardware, easier remote management, and less cost anxiety if your model usage is billed flat instead of per token |
This is where the old-laptop argument starts to fall apart.
A cheap VPS is often inexpensive enough that "free hardware" stops being meaningfully free once you price in your time.
If your spare laptop costs you a few evenings a month in maintenance, that is not zero-cost infrastructure. That's just unbilled labor.
The old-laptop trick has a hardware tax
People skip this part because it makes the hack less fun.
A laptop left plugged in 24/7, running warm, with browser automation active all day, is not living its best life.
You're dealing with:
- battery aging
- thermal stress
- occasional sleep or power-management weirdness
- fans and dust
- random hardware instability on old machines
Can it work? Sure.
Would I use an old ThinkPad as a temporary OpenClaw box? Absolutely.
Would I build anything important on the assumption that this is my long-term reliable agent infrastructure? Not unless I actually wanted the homelab project.
A mini PC is just better for this.
But then you still have the software problem.
Linux or Windows?
My practical answer: Linux wins unless you have a very specific reason to stay on Windows.
Not because Linux is morally superior.
Because fewer compatibility layers usually means fewer debugging sessions.
If the recommended Windows path eventually turns into "use WSL2 for the full experience," that is already your answer.
For most people:
- Ubuntu with GUI is the safest default
- Xubuntu is a good lightweight option
- Windows + WSL2 is acceptable if you're already committed to Windows
If your goal is 24/7 OpenClaw uptime with a headful browser, I'd rather run Ubuntu with a desktop environment than fight native Windows edge cases.
Self-hosting gets expensive after the first successful run
The first time the workflow works, you feel smart.
The fifth time something breaks after an update, you feel like you accidentally adopted a pet.
This is the part people underprice:
- Node version drift
- Docker weirdness
- browser dependency changes
- auth/session breakage
- upstream website UI changes
- daemon startup issues
- remote access and security
- backups and monitoring
If you're also running n8n, Make, Zapier handoffs, custom webhooks, or internal tools around the agent, the maintenance surface gets bigger fast.
This is why a lot of self-hosted AI setups are technically cheaper on paper and more expensive in reality.
The cost moved from invoice to attention.
The one time local hardware is obviously the right answer
There are cases where I would stop arguing and just say yes, self-host it.
When the workflow genuinely needs local control.
Examples:
- iMessage automation on a signed-in Mac
- USB device access
- local network services
- on-prem enterprise systems
- browser sessions that must live on hardware you control
That's a real requirement.
That's not the same as "I had a mini PC in a drawer, so this is cheaper now."
If the workload must be local, then local hardware makes sense.
If the workload does not need to be local, then self-hosting is often just optional complexity.
The setup I think makes the most sense
The middle ground is better than either extreme.
Use local hardware only for the parts that actually need to be local:
- browser sessions
- file access
- local integrations
- device-specific channels
Then stop paying per-token rates for the model side if your agents are noisy and always-on.
That's the part I think a lot of teams miss.
The expensive part of agent workloads usually isn't one giant prompt.
It's all the background traffic:
- retries
- summarization
- extraction
- classification
- planning steps
- browser action loops
- glue logic between tools
If you're running OpenClaw, n8n, Make, Zapier, or custom agents, per-token pricing gets annoying fast.
You end up watching usage instead of building workflows.
This is where a flat-rate OpenAI-compatible backend makes way more sense.
For example, Standard Compute gives you an OpenAI-compatible API with flat monthly pricing instead of per-token billing. That means you can keep your existing SDKs and workflows, but stop treating every agent loop like it's running up a taxi meter.
That's a much better match for automations that run all day.
Especially when the real win is predictability, not squeezing another 3 dollars out of a spare laptop.
A practical architecture
If I were setting this up today for real work, not for fun, I'd do something like this:
# local or VPS box
- OpenClaw gateway
- Ubuntu with GUI if browser workflows matter
- Tailscale for remote access
- system service / daemon for process management
# model backend
- OpenAI-compatible endpoint
- flat monthly pricing if usage is continuous
# automation layer
- n8n / Make / Zapier / custom workers
And if I wanted to sketch that in pseudo-config:
agent_stack:
gateway:
runtime: openclaw
host: ubuntu-mini-pc
browser_mode: headful
remote_access: tailscale
llm_backend:
provider: standard-compute
api_compatibility: openai
billing: flat_monthly
automation:
orchestrator: n8n
workflows:
- lead_enrichment
- inbox_triage
- site_monitoring
- browser_research
That setup keeps local complexity where it matters and removes cost anxiety from the model layer.
My actual takeaway
Self-hosting is not a bad idea.
It's a good idea for people who:
- enjoy tinkering
- want full control
- need local integrations
- are comfortable owning the stack
But if the pitch is "I'm self-hosting to save money," I think most people are kidding themselves.
They're not eliminating cost.
They're changing the form of the cost.
They're paying in:
- maintenance
- attention
- troubleshooting
- weekends
If that's fun for you, great.
If you're trying to run reliable AI agents for actual work, the better move is usually:
- self-host only the parts that must be local
- avoid per-token billing for the model side
- keep the stack boring wherever possible
That's not as romantic as turning an old laptop into an agent server.
But it is a lot closer to something you'll still be happy with a month later.