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

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

What is the core idea behind "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. 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).
2. Keep PRs scoped — one bug, one feature. If you found three bugs, send three PRs.
3. Claworc federation
4. Find one untrusted-content path the soul reads (email, web fetch, document) and …
Which term best describes a foundational idea in "Deploying OpenClaw: Local Box, Home Server, Or VPS"?
1. heartbeat
2. soul
3. persistent volume
4. restart-resilience
A learner studying Deploying OpenClaw: Local Box, Home Server, Or VPS would need to understand which concept?
1. soul
2. persistent volume
3. heartbeat
4. restart-resilience
Which of these is directly relevant to Deploying OpenClaw: Local Box, Home Server, Or VPS?
1. soul
2. heartbeat
3. restart-resilience
4. persistent volume
Which of the following is a key point about Deploying OpenClaw: Local Box, Home Server, Or VPS?
1. /var/openclaw/souls — durable: each soul's long-term memory, scheduled heartbeats, skill bindings.
2. /var/openclaw/audit — append-only: every heartbeat, every skill call, every approval gate decision.
3. /var/openclaw/cache — disposable: tool-call results, model responses, anything regeneratable.
4. /etc/openclaw — config: soul definitions, skill registry, secrets references (NOT secrets themselves…
Which of these does NOT belong in a discussion of Deploying OpenClaw: Local Box, Home Server, Or VPS?
1. /var/openclaw/souls — durable: each soul's long-term memory, scheduled heartbeats, skill bindings.
2. /var/openclaw/cache — disposable: tool-call results, model responses, anything regeneratable.
3. Keep PRs scoped — one bug, one feature. If you found three bugs, send three PRs.
4. /var/openclaw/audit — append-only: every heartbeat, every skill call, every approval gate decision.
Which statement is accurate regarding Deploying OpenClaw: Local Box, Home Server, Or VPS?
1. Set a heartbeat watchdog: if a soul hasn't ticked in 2x its interval, log a warning.
2. Test it deliberately — once a quarter, kill -9 the container and time how long until souls resume.
3. Use `restart: unless-stopped` (Docker) or `Restart=always` (systemd) so a crash auto-recovers.
4. Keep migrations idempotent: a soul on version N reading a checkpoint from version N-1 must not corru…
Which of these does NOT belong in a discussion of Deploying OpenClaw: Local Box, Home Server, Or VPS?
1. Test it deliberately — once a quarter, kill -9 the container and time how long until souls resume.
2. Keep PRs scoped — one bug, one feature. If you found three bugs, send three PRs.
3. Use `restart: unless-stopped` (Docker) or `Restart=always` (systemd) so a crash auto-recovers.
4. Set a heartbeat watchdog: if a soul hasn't ticked in 2x its interval, log a warning.
What is the key insight about "Pick the slowest acceptable host" in the context of Deploying OpenClaw: Local Box, Home Server, Or VPS?
1. OpenClaw runs comfortably on a 4GB Pi if your model is local-Ollama-small or cloud-API.
2. Keep PRs scoped — one bug, one feature. If you found three bugs, send three PRs.
3. Claworc federation
4. Find one untrusted-content path the soul reads (email, web fetch, document) and …
What is the key insight about "Souls in cache is the classic mistake" in the context of Deploying OpenClaw: Local Box, Home Server, Or VPS?
1. Keep PRs scoped — one bug, one feature. If you found three bugs, send three PRs.
2. If you let soul state land in a tmpfs or a container-internal path, every restart wipes them.
3. Claworc federation
4. Find one untrusted-content path the soul reads (email, web fetch, document) and …
What is the key insight about "Apply: pick a host this week" in the context of Deploying OpenClaw: Local Box, Home Server, Or VPS?
1. Keep PRs scoped — one bug, one feature. If you found three bugs, send three PRs.
2. Claworc federation
3. Don't theorize for a month. Pick the dumbest viable option (laptop + restart hook is fine for a first pass), get a soul …
4. Find one untrusted-content path the soul reads (email, web fetch, document) and …
Which statement accurately describes an aspect of Deploying OpenClaw: Local Box, Home Server, Or VPS?
1. Keep PRs scoped — one bug, one feature. If you found three bugs, send three PRs.
2. Claworc federation
3. Find one untrusted-content path the soul reads (email, web fetch, document) and …
4. OpenClaw is a long-running runtime, not a script you invoke and forget. It loads souls (long-lived agent personas), schedules heartbeats (pe…
What does working with Deploying OpenClaw: Local Box, Home Server, Or VPS typically involve?
1. OpenClaw ships a reference Dockerfile and a docker-compose.yml. Container-first deployment is the right default for any host that's not your…
2. Keep PRs scoped — one bug, one feature. If you found three bugs, send three PRs.
3. Claworc federation
4. Find one untrusted-content path the soul reads (email, web fetch, document) and …
Which of the following is true about Deploying OpenClaw: Local Box, Home Server, Or VPS?
1. Keep PRs scoped — one bug, one feature. If you found three bugs, send three PRs.
2. OpenClaw splits state into four directories. Mount them outside the container so an `image pull` and restart never erases anything important.
3. Claworc federation
4. Find one untrusted-content path the soul reads (email, web fetch, document) and …
Which best describes the scope of "Deploying OpenClaw: Local Box, Home Server, Or VPS"?
1. It is unrelated to tools workflows
2. It applies only to the opposite beginner tier
3. It focuses on OpenClaw can live on your laptop, on a Pi in your closet, or on a $5 VPS. The choice shapes uptime,
4. It was deprecated in 2024 and no longer relevant

← Back to interactive lesson

Tendril · Creators · Tools Literacy