An AI agent is not a chatbot with extra features. A chatbot answers when spoken to; an agent runs a loop, holds state between runs, and does things on a schedule whether or not anyone is watching. That difference is the whole of the infrastructure question, and it is why "just run it on my laptop" stops working in about a week.
OpenClaw is the clearest current example — a self-hosted agent that browses, runs commands, manages files and keeps long-term memory, connected to whatever messaging platform you already use. Its own documentation is explicit that scheduled work only fires while the gateway process is up. A laptop that sleeps is not a host. This post is about what a real host looks like.
What the official docs actually require
From the OpenClaw documentation, retrieved September 2026:
| Requirement | Documented |
|---|---|
| Node.js | Node 26 recommended; Node 22.22.3+, 24.15+ or 25.9+ supported |
| Operating system | macOS, Linux or Windows (native Hub, PowerShell CLI, or WSL2 gateway) |
| Containers | Docker supported, with Podman and Kubernetes as alternatives |
| Docker build RAM | At least 6 GB to build the image from source; pre-built images avoid this |
| Persistent state | Config, workspace and auth-secret directories must be bind-mounted or on volumes |
Note what is not in the documentation: a CPU or RAM figure for running the thing. That is not an oversight — the requirement depends entirely on what you let the agent do, which is the part you control.
The four things that actually drive the spec
Whether a browser is in the loop. This dominates everything else. An agent calling a hosted model over an API is a modest Node process. An agent driving a headless Chromium is running a full browser, and browsers are measured in gigabytes per session, not megabytes. If your workflows include "log into a site and read the dashboard," size for the browser, not for Node.
Whether inference is local or remote. Calling a hosted model means your machine handles orchestration only. Running a model on the box means GPU and RAM requirements in an entirely different bracket. Most self-hosted agents in practice use hosted models, and should — a VPS is the wrong shape for local inference.
How many agents, and how concurrent. One agent handling messages sequentially is very different from a scheduler firing six overlapping jobs at 09:00.
Disk growth over months. The docs name the hotspots directly: media folders, SQLite databases, transcripts, plugin packages, and rolling logs. Every one grows monotonically. An agent that transcribes and remembers is a machine whose disk usage only goes up, and "remembers everything indefinitely" is a storage plan whether you wrote one or not.
Sizing, in three honest brackets
| Workload | Sensible shape |
|---|---|
| One agent, hosted model API, messaging integrations, no browser | 2 cores / 4 GB / modest SSD |
| Browser automation, several integrations, growing transcript history | 4 cores / 8 GB |
| Multiple agents, concurrent scheduled jobs, heavy browser use, long retention | 8 cores / 16 GB |
NexonHost's AI agent hosting tiers map onto those brackets deliberately: NEX2 at 2 cores, 4 GB RAM and 60 GB SSD; NEX3 at 4 cores, 8 GB and 80 GB; NEX4 at 8 cores, 16 GB and 100 GB — from €16.20/month on an annual term, each on a 10 Gbps port with 8 to 32 TB of bandwidth and DDoS protection included, and Docker-ready with persistent NVMe storage for the memory and state directories.
Start at the middle tier if a browser is anywhere in your workflows. The failure mode of undersizing here is not slowness, it is the kernel's OOM killer terminating the gateway at an arbitrary moment — and an agent whose process dies silently is worse than no agent, because the scheduled work simply stops happening and nothing tells you.
Why "always-on" is a hosting requirement, not a preference
The single most useful thing about an agent is the work you did not ask for at the moment it happens: the morning briefing, the scheduled check, the reaction to an inbound message. All of it is a daemon on a timer. The documentation says it plainly — cron jobs and scheduled automations fire only when the gateway is running.
Consequences worth planning for:
- Uptime is the product. A machine that reboots for updates at 04:00 skips whatever was scheduled at 04:00.
- The process needs supervision. systemd, Docker's restart policy, or an equivalent. Not
nohup. - State must outlive the container. Bind-mount the config, workspace and secrets directories, or a routine image update erases the agent's memory. This is the mistake that hurts most and is easiest to avoid.
- Restarts must be boring. Test one deliberately, before you need one.
Security, because this agent has hands
Standard VPS hygiene is not sufficient for a process whose entire purpose is running commands and holding credentials for a dozen services.
- Do not expose the gateway to the open internet. Reach it over a VPN or an SSH tunnel. If it must be public, put authentication in front of it and restrict source addresses — see our VPS VPN gateway setup guide for the pattern.
- Give it its own machine. An agent that can run shell commands should not share a host with your production database. Isolation is cheap; a blast radius is not.
- Scope every credential you hand it. The agent will hold API keys for everything it integrates with. Each one should be the narrowest token that works, and each should be revocable independently.
- Treat the workspace as untrusted input. An agent that reads web pages and messages is an agent that reads text written by strangers. Prompt injection is a real category, and the mitigation is limiting what the agent is able to do, not hoping it decides well.
- Back up the state directory offsite. The memory and config directories are the agent. Push them to offsite backup storage on a schedule.
- Keep DDoS filtering in front of it. An always-on host with a public endpoint is a target like any other.
What this does not solve
An agent host is not a machine-learning platform. If the plan involves training or serving models locally, the requirement is GPU capacity, and a general-purpose VPS is the wrong instrument — that is a dedicated server conversation with specific hardware, not a plan tier.
It is also not a replacement for a scheduler you trust for business-critical work. An agent is excellent at judgement-shaped tasks and mediocre at guaranteed execution. Anything that must run, and must be known to have run, belongs in a plain cron job with alerting, with the agent doing the interpretive part.
And it will not fix a vague brief. The agents that repay their hosting cost have a small number of well-specified jobs. The ones that get switched off after a month were asked to "help with things."
Getting from laptop to server
The path most people take, in order: run it locally to learn what you want it to do; write the workflows down; move to a small always-on host once you notice you are leaving the laptop open for it; add the browser workloads; discover you need the next tier up. Migration between providers is a matter of moving the state directories, which is exactly why the bind-mount discipline matters from day one.
NexonHost's plans include migration from an existing OpenClaw VPS elsewhere, plus Docker or direct installation, with Moltbot and ClawDBot environments configured — the older names for the same project, which had two forced rebrands before landing on OpenClaw.
Related reading: VPS vs dedicated server, setting up a VPS as a VPN gateway, and offsite backup storage sizing.
Sources
- Install and Docker install, OpenClaw Documentation, retrieved 7 September 2026 — Node.js versions, supported operating systems, the 6 GB source-build requirement, persistent directory bind-mounts and the disk growth hotspots.
- Plan specifications and pricing as published on nexonhost.com on 7 September 2026; check the product page for current figures.
