Want to skip the whole “my settings disappear on restart” category of problem? Use ZenClaw. MixerBox AI’s managed OpenClaw service gets you running in 9 seconds with persistence handled for you. You never touch a Docker volume. This post is for the people who need to self-host: how to spot the problem in 5 seconds, the three correct ways to mount, and how to rescue lost settings.
5-second check
Run one docker inspect command and check if Mounts is empty. Empty means no volume, and every restart is wiping your settings. The full command:
docker inspect openclaw | grep -A 5 Mounts
If you see:
"Mounts": [],
You’re affected. Every docker restart is resetting all your settings, WhatsApp sessions, conversation memory, and Telegram tokens.
If you see something like:
"Mounts": [
{
"Type": "volume",
"Source": "openclaw_data",
"Destination": "/root/.openclaw",
...
}
]
You’re fine. Carry on.
Why this happens
Because Docker containers use an ephemeral filesystem by default. Stop the container and it reverts. Anything you wrote gets thrown away. Files you write inside a container go into a writable layer stacked on top of the image. Stop the container and that layer is discarded. Delete it and even the layer is gone. The Docker Storage overview has the full explanation.
OpenClaw keeps all runtime state in the user’s home directory at ~/.openclaw/ (when running as root in Docker, that’s /root/.openclaw/ inside the container). Per the OpenClaw config docs and Simon Willison’s TIL: Running OpenClaw in Docker, the layout looks like:
~/.openclaw/
├── openclaw.json # Main config (JSON5): models, gateway, channel tokens, spend caps
├── sessions/ # Conversation session history
├── agents/ # Custom agent definitions
├── credentials/ # Channel auth (including WhatsApp's whatsapp-creds.json)
└── skills/ # Plugins and skills you've installed
Without a volume mount, these are all ephemeral. The most painful one is credentials/whatsapp-creds.json (the Baileys session). Lose it, and WhatsApp forces you to re-scan the QR code. Messages sent during that window get dropped. The community has reported this plenty of times. See Issue #9096 — WhatsApp session not persisted across gateway restarts and the official WhatsApp channel docs.
Three common wrong ways to do this
The three most common mistakes: no volume at all, wrong target path, or using docker exec to edit settings and thinking they’ll stick. First-time OpenClaw users hit at least one.
Mistake 1: no volume
# Wrong
docker run -d --name openclaw openclaw/openclaw:latest
Mistake 2: wrong path
# Wrong. OpenClaw uses /root/.openclaw, not /app/data
docker run -d -v openclaw_data:/app/data openclaw/openclaw:latest
Mistake 3: editing via docker exec and expecting it to persist
# Changes are gone when you exit
docker exec -it openclaw vi /root/.openclaw/openclaw.json
Three correct ways to mount
All three persist settings correctly. Named volume for production, bind mount for development, docker-compose for long-term ops. Here’s how each one looks.
Option 1: named volume (recommended for prod)
docker volume create openclaw_data
docker run -d \
--name openclaw \
-v openclaw_data:/root/.openclaw \
-p 18789:18789 \
openclaw/openclaw:latest
Pros: Docker manages the actual storage location. On a new host, docker volume inspect finds it. See the Docker volumes docs for details.
Cons: Backups take more steps: docker run --rm -v openclaw_data:/data -v $(pwd):/backup alpine tar czf /backup/openclaw.tar.gz /data.
Option 2: bind mount (recommended for dev)
mkdir -p ./openclaw_data
docker run -d \
--name openclaw \
-v $(pwd)/openclaw_data:/root/.openclaw \
-p 18789:18789 \
openclaw/openclaw:latest
Pros: Config sits in your current directory. Edit in VSCode, version control with git add (always add credentials/ to .gitignore since it holds WhatsApp sessions and other sensitive keys. If openclaw.json has embedded bot tokens, ignore that too).
Cons: Moving hosts means rsyncing the directory yourself.
Option 3: docker-compose (long-term ops)
docker-compose.yml:
services:
openclaw:
image: openclaw/openclaw:latest
restart: unless-stopped
ports:
- "18789:18789"
volumes:
- ./data:/root/.openclaw
environment:
- OPENCLAW_LOG_LEVEL=info
Then docker compose up -d. The key line is restart: unless-stopped. Without it, a host reboot doesn’t bring the bot back and you drop customer messages again. Full syntax in the Docker Compose reference.
All three, side by side
| Comparison | Option 1: named volume | Option 2: bind mount | Option 3: docker-compose |
|---|---|---|---|
| Best for | Production, live deployments | Dev, local testing | Long-term ops, locked-in launch params |
| Backup difficulty | Higher (needs alpine image tar) | Easy (just copy the host path) | Depends on which mount you use |
| Migration | docker volume inspect to find location | rsync the directory | Copy compose file + data directory |
| Auto-start on reboot | Write your own systemd | Write your own systemd | restart: unless-stopped built in |
| Learning curve | Medium | Low | Medium |
| Recovery on failure | Harder | Easiest | Medium |
| Best fit | Small prod, single-maintainer | Dev, PoC, personal use | Most complete, long-term choice |
| Least hassle | — | — | ✅ Use ZenClaw, skip all three |
Migrating a running container to a volume (5 steps)
Your container is still alive but never had a volume. 3–5 minutes to migrate: inspect, docker cp to back up, re-run with -v, verify. Here’s the sequence.
- Confirm you’re affected:
docker inspect <container> | grep -A 10 Mounts. EmptyMountsarray means no volume. - Stop (don’t delete) the running container:
docker stop openclaw. Leave it stopped so you can keep the container ID for copying in the next step. - Copy the config out:
docker cp openclaw:/root/.openclaw ./openclaw_backup. Back up first to avoid losing anything. - Restart with
-v:docker run -d --name openclaw -v $(pwd)/openclaw_backup:/root/.openclaw openclaw/openclaw:latest. - Verify: After
docker restart openclaw, rundocker exec openclaw cat /root/.openclaw/openclaw.jsonand confirm the config is there. You can also runopenclaw config fileto print the active config path.
3–5 minutes total. If you don’t want to do this a second time and don’t want to manage DevOps details going forward, the next section is the easier path.
Already lost settings? Here’s how to recover
What you can recover depends on what you lost. Some things are a reset. Some require re-pairing. The conversation memory in sessions/ is gone for good. Here’s the breakdown:
Lost openclaw.json (model, gateway, channel config, bot tokens)
Just refill it. Get a new Telegram token from @BotFather with /revoke and /token. Regenerate your LINE channel key in the developer console. For Slack, reinstall the app.
Lost sessions/ (conversation memory)
Gone. Mount the volume properly next time.
Lost credentials/whatsapp-creds.json (WhatsApp Baileys session)
Re-pair the QR code. This is a Meta-side limitation. Open the dashboard, launch WhatsApp, scan the QR. During this window, incoming messages get dropped.
Lost agents/ or skills/ (custom agents, installed plugins)
Reconfigure agents from scratch. Skills installed from a registry can be reinstalled. Custom skills have to be rewritten.
Don’t want to deal with this at all? Use ZenClaw
ZenClaw is MixerBox AI’s managed OpenClaw service (plans include the NemoClaw sandbox). Persistence is on us. You never touch a Docker volume again. No docker-compose, no backup cron jobs. You get a working OpenClaw instance in 9 seconds, connect Telegram / LINE / Microsoft Teams, and you’re live.
Moving to ZenClaw: head to zenclaw.ai, sign in, click “Hire AI Employees Now”, and in the dashboard click “Add New OpenClaw Installation”.
Wrap-up
The vast majority of “my settings disappeared” cases come down to missing volume mounts. Mount them and restarts become boring. If you don’t want to keep dealing with Baileys session drops, Docker upgrades wiping files, or host migrations losing data, a managed service like ZenClaw is exactly what you want.