Running OpenClaw: Turning a Proxmox Box Into a Private AI Agent
What OpenClaw actually is, why Proxmox VE 9.2 makes this a good time to try it, and how to size the hardware.
Every "AI agent" product you've seen advertised this year runs on someone else's server, reads your messages to do it, and bills you monthly for the privilege. OpenClaw is the self-hosted answer to that: an open-source AI assistant framework that runs on your own hardware, keeps its memory on your own disk, and talks to you over Telegram, Discord, or whatever messaging app you already use — instead of a web tab you have to remember to open. It's exactly the kind of project my Proxmox homelab is built for, and a Proxmox VE 9.2 upgrade removes a couple of the reasons I'd have hesitated to run it a few months ago.
What OpenClaw Actually Does
OpenClaw isn't a model — it's the orchestration layer around one. It routes tasks to Ollama for anything you want kept local and private, and can fall back to a cloud provider (OpenAI, Anthropic, Google, Groq) for the harder reasoning tasks a small local model isn't built for. That hybrid routing is the practical part: you're not stuck choosing between "fully private but dumb" and "smart but sends everything to the cloud."
On top of that, it gives the agent:
🧠 Persistent memory
Context carries across sessions instead of resetting every time you close the tab, the way a stateless cloud chat does.
💬 Messaging-native access
Telegram, Discord, WhatsApp, and iMessage integrations, so the agent lives where you already talk to people rather than a bookmarked dashboard.
🛠️ Real tool access
Email, calendar, code execution, and web search, gated behind whatever permissions you configure — not a sandboxed toy.
🧩 Multiple agents
Run specialized agents side by side instead of one generalist trying to do everything adequately.
It's open source, installs with a single command, and the project's own setup guides cover everything from a Mac Mini to an Intel NUC to a used enterprise server — which is really just a description of what's already sitting in most homelabs.
The Stack, and Sizing the Hardware
OpenClaw itself is lightweight enough to run on something as small as a Raspberry Pi. The part that actually needs real hardware is Ollama doing local inference underneath it — that's where your GPU budget goes, not the agent framework. As a starting point: 16GB of system RAM is the floor, 32GB is comfortable, and a GPU with 8GB or more of VRAM is what keeps a mid-sized local model fast enough to feel like talking to a person instead of waiting on a spinner.
That maps directly onto the hardware this site already tracks. An older datacenter or prosumer GPU like a Tesla P40 or RTX A4000 clears the 8GB VRAM bar for a fraction of new-GPU pricing, and it can live in a full-size box — a used rack server if you already have one spun up, or a small standalone box if you'd rather keep it isolated from the rest of the cluster. If you're starting from nothing, an SFF Proxmox node with enough RAM to hit that 32GB mark can run OpenClaw and a small model comfortably; you just won't get datacenter-GPU inference speed without a discrete card, which most SFF machines have no slot for.
Either way, give the agent its own VM or LXC container rather than bolting it onto something else. It has real tool access — email, code execution, calendar — and keeping it isolated means a misbehaving agent or a bad prompt injection stays contained to one guest instead of touching the rest of the cluster.
Why Proxmox VE 9.2 Specifically
Proxmox VE 9.2 shipped a couple of features that line up with running an AI agent well enough that it's worth upgrading before you start, if you haven't already:
- Dynamic Load Balancer — if the GPU-carrying node also happens to be running other VMs, the new balancer automatically migrates guests across your cluster based on real-time resource data instead of wherever you happened to create them, while still respecting your HA rules. An inference workload spiking a node's CPU no longer means manually shuffling everything else off it.
- WireGuard SDN — native WireGuard support in Proxmox's software-defined networking means you can reach the agent's messaging webhook or admin panel securely from outside your network without port-forwarding it directly to the internet, and without standing up a separate VPN box just for this one service.
- Kernel 7.0, QEMU 11.0, ZFS 2.4 — newer kernel and QEMU mean better GPU passthrough compatibility, which matters more here than in a typical VM since you're passing a physical card through to whichever guest runs Ollama.
How It Works, Roughly
▸ Stand up Ollama first, in its own VM or LXC, and pull a model sized to your VRAM — there's no point installing OpenClaw before the model underneath it actually runs.
▸ Install OpenClaw with its single install command and point it at that Ollama instance, plus a cloud API key if you want hybrid routing for harder requests.
▸ Connect a messaging channel (Telegram is the fastest to set up) so the agent is reachable from your phone, not just a terminal.
▸ Grant tool access deliberately, one integration at a time — calendar and web search first, code execution and email later once you trust how it behaves.
A Few Things I'd Get Right From the Start
1. Size the model to the GPU you have, not the one you wish you had
A smaller model that responds in two seconds beats a bigger one that makes you wait fifteen. Start small, and only go shopping on the GPU tracker once you've actually hit a capability wall, not before.
2. Never expose the agent directly to the internet
Reach it over WireGuard or Tailscale, the same rule as any other self-hosted service on this site. An agent with email and code-execution access is a much worse thing to have exposed than a media server.
3. Back up its config and memory, not just the VM
The persistent memory is the whole point of running this instead of a stateless cloud chat — losing it to an untested restore defeats the purpose. Back up the config/data volume on the same schedule as everything else in your backup routine.
4. Give it its own guest, not a shared one
Isolate the blast radius. A dedicated VM or LXC container means a bad prompt injection or a misconfigured tool integration can't reach anything outside it.
Related Resources
OpenClaw
Project site and setup guides for the AI agent framework this page covers.
Ollama
Runs the local models OpenClaw routes requests to.
Proxmox VE 9.2 Release Notes
Official details on the Dynamic Load Balancer and WireGuard SDN mentioned above.
AI GPU Price Tracker
Live $/GB VRAM pricing on the used GPUs that make local inference affordable.
SFF Proxmox Nodes
Where to start if you don't have a homelab node running yet.
My Media Lab
The rest of what runs on the same Proxmox cluster.
Frequently Asked Questions
Is OpenClaw free to use?
Yes — OpenClaw is open source and free to run on your own hardware. The only ongoing costs are whatever you already pay for electricity and hardware, plus optional cloud API fees if you enable hybrid routing to a provider like OpenAI or Anthropic for harder reasoning tasks.
Does OpenClaw send my data to the cloud?
Not by default. Requests routed to Ollama run entirely on your own hardware and never leave your network. OpenClaw only reaches out to a cloud provider if you've configured hybrid routing and a request is deliberately sent there — it's opt-in, not automatic.
Do I need a dedicated GPU to run OpenClaw?
OpenClaw itself will run on something as small as a Raspberry Pi. Ollama, the local inference engine underneath it, is what benefits from a GPU — without one, it'll fall back to CPU inference, which works but is noticeably slower for anything beyond a small model. An 8GB+ VRAM card, even an older Tesla P40, is enough to make it feel responsive.
Can I run OpenClaw without a Proxmox homelab?
Yes, OpenClaw doesn't require Proxmox at all — its own setup guides cover bare-metal installs on a Mac Mini, Intel NUC, or similar. Proxmox is just how I isolate it into its own VM or LXC container so it doesn't share a blast radius with anything else running on the same physical hardware.
Is it risky to give an AI agent access to email and code execution?
It carries more risk than a purely conversational chatbot, yes, which is why the setup here treats it that way: run it in its own dedicated VM or LXC, grant tool access one integration at a time instead of all at once, and never expose it directly to the internet — reach it over WireGuard or Tailscale like anything else self-hosted on this site.