Deploying OpenClaw: Local Box, Home Server, Or VPS

OpenClaw can live on your laptop, on a Pi in your closet, or on a $5 VPS. The choice shapes uptime, latency, and how much you trust the host. Pick deliberately. It loads souls (long-lived agent personas), schedules heartbeats (periodic ticks where each soul wakes up and considers what to do), and exposes skills (capabilities it can call).

10 min · Reviewed 2026

Three places OpenClaw runs

OpenClaw is a long-running runtime, not a script you invoke and forget. It loads souls (long-lived agent personas), schedules heartbeats (periodic ticks where each soul wakes up and considers what to do), and exposes skills (capabilities it can call). All three need a home that stays on. The realistic options are your laptop, a home server, and a small VPS — each with different trade-offs.

Host	Best for	Trade-off
Laptop	Solo dev, dev loop, daily-only souls	Sleep / shut lid kills heartbeats
Home server (Mac mini, NUC, Pi)	24/7 souls, local-only data, low latency to your network	You become the sysadmin; power and network outages are your problem
Small VPS ($5-20/mo, e.g. Hetzner, DO)	Public-facing souls, cron-shaped work, you're not always at the keyboard	Provider can read disk; latency to home network; egress costs
Both: home + VPS (federated)	Sensitive data stays home, public skills run remote	Now you have two boxes to operate (covered in lesson 4)

The Docker option

OpenClaw ships a reference Dockerfile and a docker-compose.yml. Container-first deployment is the right default for any host that's not your dev laptop — it gives you reproducible installs, easy upgrades, and clean rollbacks when a release breaks something. The compose file declares the OpenClaw process, an Ollama sidecar (optional), and the volumes that hold the soul state.

# docker-compose.yml — minimal home-server deployment services: openclaw: image: ghcr.io/openclaw/openclaw:latest restart: unless-stopped ports: - "8081:8081" # mission-control web UI, bound to LAN only volumes: - ./data/souls:/var/openclaw/souls # soul state: long-term memory - ./data/audit:/var/openclaw/audit # audit log: every action, every tick - ./config:/etc/openclaw:ro # config: read-only mount environment: - OPENCLAW_BACKEND=ollama - OPENCLAW_OLLAMA_URL=http://ollama:11434 - OPENCLAW_LOG_LEVEL=info depends_on: - ollama ollama: image: ollama/ollama:latest restart: unless-stopped volumes: - ./data/ollama:/root/.ollama # downloaded models (big) # No ports exposed — only OpenClaw talks to it.A two-service compose file for a home box. `restart: unless-stopped` is what makes souls survive a power blip.

Persistent volume layout

OpenClaw splits state into four directories. Mount them outside the container so an `image pull` and restart never erases anything important. The split exists for a reason — different directories have different backup and rotation policies.

/var/openclaw/souls — durable: each soul's long-term memory, scheduled heartbeats, skill bindings. Back this up. Lose this and your souls forget who they are.
/var/openclaw/audit — append-only: every heartbeat, every skill call, every approval gate decision. Rotate monthly; do not delete the current month.
/var/openclaw/cache — disposable: tool-call results, model responses, anything regeneratable. Safe to wipe between releases.
/etc/openclaw — config: soul definitions, skill registry, secrets references (NOT secrets themselves). Version-control this directory.

Restart-resilience for souls

A soul is a long-running agent — and long-running things crash. OpenClaw's design assumes restarts are routine, not exceptional. Souls write checkpoint state after each heartbeat; on boot, the runtime replays from the last checkpoint and the next scheduled tick fires on time. Your job is to make sure the host actually restarts the OpenClaw process when it falls over.

Use `restart: unless-stopped` (Docker) or `Restart=always` (systemd) so a crash auto-recovers.
Set a heartbeat watchdog: if a soul hasn't ticked in 2x its interval, log a warning. Lesson 2 covers this.
Test it deliberately — once a quarter, kill -9 the container and time how long until souls resume.
Keep migrations idempotent: a soul on version N reading a checkpoint from version N-1 must not corrupt itself.
On VPS, set the host to auto-reboot on kernel update (e.g. `unattended-upgrades` on Debian) and confirm souls come back.

The host-trust question

OpenClaw can read whatever you let it read. If it lives on a VPS, the provider can technically read your soul memory and audit logs. For a hobby weather-summary soul that's fine. For a soul that has access to your email or your bank exports, it's not. Match the data sensitivity to the host trust level — a calendar-summary soul on a $5 VPS is reasonable; an inbox-triage soul there is reckless. Lesson 3 has the full security model.

The big idea: OpenClaw's home shapes everything that follows. Pick your host on data sensitivity and uptime needs, mount volumes outside the container, and prove restart-resilience before you trust a soul with anything that matters.

End-of-lesson check

8 questions · take it digitally for instant feedback at tendril.neural-forge.io/learn/quiz/end-openclaw-ops-deploying-creators

What is the main idea of "Deploying OpenClaw: Local Box, Home Server, Or VPS"?
1. OpenClaw can live on your laptop, on a Pi in your closet, or on a $5 VPS.
2. Use AI as the final authority for the whole decision
3. Avoid checking the answer once it sounds polished
4. Focus only on speed instead of judgment
Which concept is most central to "Deploying OpenClaw: Local Box, Home Server, Or VPS"?
1. Docker
2. deployment topology
3. persistent volumes
4. soul restart-resilience
Which use of AI fits this topic best?
1. Let the AI decide what matters without your review
2. Use the answer before checking whether it fits the situation
3. /var/openclaw/souls — durable: each soul's long-term memory, scheduled heartbeats, skill bindings.
4. Treat the AI output as automatically correct
What should a careful learner remember about "Pick the slowest acceptable host"?
1. Use AI to draft or organize ideas about deployment topology, then verify before acting.
2. Skip the context so the tool can guess faster
3. Treat the output as private even after sharing it online
4. Use the answer without checking the source
You want to use AI after this lesson. What is the safest next step?
1. Act immediately because the AI answer is written clearly
2. Use AI for drafting and comparison, but verify before publishing or relying on it.
3. Hide uncertainty so the final answer looks cleaner
4. Use private or sensitive details before checking permission
How should AI output about deployment topology be treated?
1. As proof that no other source is needed
2. As a replacement for context, consent, or expert review
3. As a draft or helper output that still needs human judgment and verification
4. As something that becomes correct when it sounds confident
Name one way to verify an AI answer about deployment topology.
Which action would help you apply "Deploying OpenClaw: Local Box, Home Server, Or VPS" responsibly?
1. Use the tool to avoid thinking through the tradeoff
2. Keep going even if the output conflicts with a trusted source
3. Treat the AI output as automatically correct
4. /var/openclaw/audit — append-only: every heartbeat, every skill call, every approval gate decision. Rotate monthly; do not delete the current month.

← Back to interactive lesson

Tendril · Creators · Tools Literacy