Self-Hosting OpenClaw 24/7 on a VPS vs a Managed Runtime

How to Self Host OpenClaw on VPS 24/7

OpenClaw is a gateway assistant: one always-on assistant you reach across chat channels like WhatsApp, Telegram, Slack, and Discord, backed by a persistent workspace on disk, a library of community skills, and tool-use that calls an LLM to get real work done. To self host OpenClaw on VPS 24/7 you rent a small Linux server, run the agent inside Docker, and wire up systemd so the process restarts after a crash or a reboot. The other option is a managed runtime that keeps the same agent alive without you ever touching a server. This article walks both paths with real commands, honest uptime numbers, and a monthly cost table, so you can pick the one that matches your budget and your patience for ops work.

The short version: a VPS is cheap and fully under your control, but you own every outage, upgrade, and disk-full alert. A managed runtime costs more per month and hides the machine, but it hands you restarts, secrets, and logs on day one. Which one wins depends on how much your time is worth and how bad a silent 3 a.m. failure would be.

The four moving parts

Any always-on agent deployment has four parts you must get right, whether you self-host or not:

Compute that stays on. A laptop or a spot instance that sleeps will kill a long-running agent mid-task.
A persistent workspace so the agent does not lose its files, git checkouts, and memory on restart.
Secrets (API keys, tokens) delivered without baking them into an image or a git repo.
Supervision so a crashed process comes back instead of staying dead until you happen to look.

Self-hosting means you assemble all four by hand. Let me show the assembly, then price it.

What VPS Size Does OpenClaw Actually Need?

OpenClaw itself is not heavy. The weight comes from what it does: running skills and tool calls, holding open connections to your chat channels, and keeping a large context in memory. The model inference runs on the provider's side (Anthropic, OpenAI), so you are not paying for a GPU on the box. That keeps the VPS small and cheap.

A practical floor is 2 vCPU and 4 GB of RAM with 40 GB of disk. That handles a single assistant doing normal work. If the agent runs heavy skills, processes large files, or fires several tool calls in parallel, move up to 4 vCPU and 8 GB.

Tier	Provider / example	vCPU / RAM	Disk	Monthly
Entry	Hetzner CX22	2 / 4 GB	40 GB	about $5
Small	DigitalOcean basic droplet	1 / 2 GB	50 GB	$12
Mid	Hetzner CPX31	4 / 8 GB	160 GB	about $16
Large	DigitalOcean general purpose	4 / 8 GB	100 GB	$48

Hetzner is the value pick if you are comfortable in Falkenstein or Ashburn; see current sizes on the Hetzner Cloud page. DigitalOcean costs more but is friendlier if you want managed backups and a polished dashboard. For a single OpenClaw instance doing real work, the Entry or Mid tier is plenty.

Running several agents on one box is possible, but each instance holds its own workspace and context in memory, so two or three OpenClaw processes on a 4 GB VPS will fight for RAM the moment they all pick up heavy tasks at once. Give each busy agent its own 4 GB of headroom, or move to an 8 GB tier and set a per-container memory limit so one runaway task cannot starve the others. That headroom is cheaper than the debugging session you will otherwise run when a shared box thrashes.

How Do You Keep the Agent Alive Across Reboots and Crashes?

This is the part people skip, then wonder why their agent vanished after a kernel update. Running docker run in an SSH session is not 24/7. The moment your terminal closes or the box reboots, the agent is gone. You need two things: Docker's restart policy for crashes, and systemd for reboots and boot ordering.

Start with a container that owns a named volume for the workspace and reads secrets from an env file:

docker run -d \
  --name openclaw \
  --restart unless-stopped \
  -v /srv/openclaw/workspace:/workspace \
  --env-file /etc/openclaw/openclaw.env \
  ghcr.io/openclaw/openclaw:latest

docker run -d \
  --name openclaw \
  --restart unless-stopped \
  -v /srv/openclaw/workspace:/workspace \
  --env-file /etc/openclaw/openclaw.env \
  ghcr.io/openclaw/openclaw:latest

The --restart unless-stopped flag tells the Docker daemon to bring the container back if it exits with an error or if the daemon itself restarts. This is the documented way to keep containers running; the details are in the Docker restart policy docs. It is necessary but not sufficient, because a full reboot can leave ordering and dependency gaps.

Wrap the container in a systemd unit so boot ordering is explicit and the service is under one supervisor you can query:

cat > /etc/systemd/system/openclaw.service <<'EOF'
[Unit]
Description=OpenClaw gateway assistant
After=docker.service network-online.target
Requires=docker.service

[Service]
Restart=always
RestartSec=5
ExecStart=/usr/bin/docker start -a openclaw
ExecStop=/usr/bin/docker stop openclaw

[Install]
WantedBy=multi-user.target
EOF

cat > /etc/systemd/system/openclaw.service <<'EOF'
[Unit]
Description=OpenClaw gateway assistant
After=docker.service network-online.target
Requires=docker.service

[Service]
Restart=always
RestartSec=5
ExecStart=/usr/bin/docker start -a openclaw
ExecStop=/usr/bin/docker stop openclaw

[Install]
WantedBy=multi-user.target
EOF

Then enable it so it survives reboots:

systemctl daemon-reload
systemctl enable --now openclaw
systemctl status openclaw

systemctl daemon-reload
systemctl enable --now openclaw
systemctl status openclaw

Now the flow is: box reboots, systemd waits for Docker and the network, then starts the container. If OpenClaw crashes, Restart=always brings it back after 5 seconds. This two-layer setup (Docker restart policy plus a systemd unit) is what actually earns the "24/7" label. Without it, you have an agent that runs until the first hiccup.

Where Do the Secrets and Persistent Workspace Live?

The env file referenced above holds the keys OpenClaw needs. Keep it at 0600 permissions, owned by root, and never commit it:

# /etc/openclaw/openclaw.env
ANTHROPIC_API_KEY=sk-ant-your-real-key
OPENCLAW_MODEL=claude-sonnet
WORKSPACE_DIR=/workspace
GIT_AUTHOR_NAME=openclaw-bot

# /etc/openclaw/openclaw.env
ANTHROPIC_API_KEY=sk-ant-your-real-key
OPENCLAW_MODEL=claude-sonnet
WORKSPACE_DIR=/workspace
GIT_AUTHOR_NAME=openclaw-bot

chmod 600 /etc/openclaw/openclaw.env
chown root:root /etc/openclaw/openclaw.env

chmod 600 /etc/openclaw/openclaw.env
chown root:root /etc/openclaw/openclaw.env

The workspace bind mount (/srv/openclaw/workspace) is where the agent keeps its skills, scratch files, and any local memory. Because it lives on the host, a container rebuild or image bump does not wipe the agent's state. Snapshot that directory nightly with a cron job or your provider's volume backup so a bad task or a disk failure does not erase weeks of context.

One more thing self-hosters forget: egress. An autonomous agent can run any command, including curl to anywhere. On a VPS the default is wide-open outbound access. If you care about blast radius, add nftables rules or a proxy that only allows traffic to the model API and the git host you actually use. This is manual on a raw VPS, and it is easy to get wrong. For the deployment mechanics end to end, our walkthrough on how to deploy an AI agent covers the same steps with more surrounding detail.

Self-Hosted vs Managed Runtime: The Honest Cost Table

Here is the tradeoff without spin. The VPS is cheaper in dollars and more expensive in hours. A managed runtime flips that.

Factor	Self-host on a VPS	Managed runtime
Setup time	2 to 4 hours first time	10 to 20 minutes
Monthly compute	about $5 to $48	$20 to $120+
Restart after crash	You configure systemd	Built in
Survives reboot	You configure systemd	Built in
Secrets management	Manual env file, chmod	Managed vault or UI
Egress control	Manual nftables/proxy	Allow-rules in the platform
Logs and metrics	You install it	Included dashboard
Upgrades and patching	You own the OS	Handled for you
Who wakes up at 3 a.m.	You	The platform

The compute line is the one people fixate on, and it is genuinely low for a VPS. But compute is rarely the largest cost of running an agent. Token spend usually dwarfs the server bill, and your own time has a price too. We break the full monthly math down line by line in the cost to run an AI agent 24/7 piece, and it is worth reading before you assume the $5 VPS is the whole story.

What Breaks at 3 A.M. When You Self-Host?

Self-hosting is fine until something fails while you are asleep. Here are the failures that actually happen when you self host OpenClaw on VPS 24/7, ranked by how often people hit them:

Disk fills up. The workspace grows, Docker layers pile up, logs never rotate. The agent stops mid-task with no obvious error. Fix: docker system prune, log rotation, disk alerts.
OOM kills. A big task or a runaway context blows past 4 GB of RAM and the kernel kills the container. Restart=always brings it back, but the task is lost. Fix: right-size RAM, set memory limits.
Expired credentials. An API key rotates, or a git token lapses, and the agent silently fails every task. Fix: monitoring on task success, not just process uptime.
Kernel or Docker upgrade. Unattended upgrades reboot the box; if your systemd unit is not enabled, the agent never comes back. Fix: the enable step above, and test a reboot.

None of these are hard individually. The problem is that they are your job now, and a process being "up" tells you nothing about whether the agent is actually completing work. Real monitoring means checking task outcomes, token burn, and error rates, not just systemctl status.

When Does a Managed Runtime Win?

If you enjoy running Linux boxes and the agent is a hobby or a single low-stakes workload, self-hosting on a $5 Hetzner box is a great answer and you should do it. The math changes when the agent matters, when you run several of them, or when your time is worth more than the money you save.

A managed runtime is the honest answer when you do not want to become the on-call engineer for your own automation. This is where Sokko fits: it runs OpenClaw and agents like Hermes, Paperclip, and OpenSRE on secure, always-on cloud infrastructure we manage, with a persistent workspace, secure secrets, team roles, per-agent network controls, and logs already wired in. You get the restart-after-crash and survive-reboot behavior without writing a systemd unit, plus per-agent egress rules instead of hand-rolled nftables. You do not need infrastructure expertise; we own the servers so you can own the work the agent does. It costs more than a bare VPS per month, and that is the trade: dollars for hours and for someone else holding the pager.

If you want to compare hosting shapes more broadly before deciding, our overview of how to run an AI agent in the cloud lays out VPS, managed runtime, and serverless side by side.

FAQ

Can I run OpenClaw on a $5 VPS forever? Yes, for a single agent doing modest work. Watch RAM and disk. If tasks get bigger, move to a 4 GB or 8 GB tier before you hit OOM kills.

Do I still pay for tokens if I self-host? Always. Self-hosting saves the runtime fee, not the LLM bill. The model calls go to Anthropic or OpenAI either way, and that is usually the biggest line item.

Is systemd overkill if Docker already restarts the container? No. Docker's restart policy handles crashes; systemd handles reboots, boot ordering, and gives you one supervisor to query. Use both.

What is the fastest path to 24/7? Rent a 4 GB VPS, run the docker run command above, add the systemd unit, enable it, and test a reboot. Budget two to four hours the first time. A managed runtime does the same in under twenty minutes and keeps doing it.